RE: [Dev] [3dweb] Multi-scopic displays

Hi Christophe, 

I really appreciate your interest.

> -----Original Message-----
> From: Christophe de Dinechin [mailto:christophe@taodyne.com]
> Sent: Friday, March 15, 2013 10:38 PM
> To: Soonbo Han
> Cc: 'Christophe de Dinechin'; 'Dong-Young Lee'; dev@nano.taodyne.com;
> public-web-and-tv@w3.org
> Subject: Re: [Dev] [3dweb] Multi-scopic displays
> 
> Hi Han,
> 
> 
> Thanks for your response.
> 
> On 15 mars 2013, at 09:18, "Soonbo Han" <soonbo.han@lge.com> wrote:
> 
> > As you know, there are two kinds of objects that can be rendered in
> > stereoscopic 3D on the web. One is transformable elements, such as
> > <div>, <img> etc., which use CSS 3D Transforms. The other is stereo 3D
> > content, such as stereo 3D images or videos, consisting of two views
> > for each eye of a user. The perspective-baseline property is only for
> > elements styled by CSS 3D Transforms. On the other hand, stereo-*
> > properties are to specify image (or video) formats of stereo 3D
> > content. So we don't need to say "I have a stereo-picture with a
> > baseline of X and I want to show it with a baseline of Y" at the moment.
> 
> So maybe a good way to reformulate my question is how the CSS 3D and
> stereo-* properties are expected to interact?
> 

In the current proposal, there is no interaction between CSS 3D Transforms
and stereo-* properties. That's because targets for the two are different.
(i.e., transformable elements vs. stereo 3D content) 

If your question is about how to render (CSS 3D) transformed elements that
include stereo 3D content, the answer would be more complicated. One
feasible solution is that we just choose to render the stereo 3D content in
2D, which helps reduce the possibility of visual uncomfortableness. I'm not
sure whether it is the best solution, though. 

By the way, regarding perspective-*, perspective inconsistency issues could
be raised between transformable elements and stereo 3D content. Ideally, we
should align their perspectives to be consistent, but it seems not easy,
especially to retrieve or change those of stereo 3D content. Besides,
whether we should allow multiple perspectives (e.g., per each element) on a
webpage can be an issue as well. 

> 
> > We have the same system model as [1] in mind. Let me know if you need
> > further clarification.
> >
> > [1]
> > http://4.bp.blogspot.com/-M8y-ms1yjEo/TekJCDvKOwI/AAAAAAAAAbc/lYIkHAJ6
> > cZY/s1
> > 600/stereo_perspective_new.jpg
> 
> This is helpful, and this explains why you have only one parameter. You
> don't allow convergence at infinity for example (i.e. parallel eyes).
> 

Basically, we have followed the system model of CSS 3D Transforms, which is
based on the perspective projection. With this approach, we would achieve
CSS 3D Transforms in stereoscopic without many changes. However, if we need
any other system model such as parallel projection, we are open to discuss
it.

> 
> > If a browser can detect content formats of a 3D image file correctly,
> > some
> > stereo-* properties might not be necessary.
> 
> OK, understood. This begs the same question as above: what happens if
> stereo-* conflicts with the container format?
> 

I think the container format should have priority. stereo-* properties
except stereo-rendering-option (which reflects an author's intention) could
be retrieved easily, if it follows a standardized format.

> 
> > Roughly speaking, it assumes that the perspective is in the middle of
> > the two perspectives of given two images. Although it's difficult to
> > implement with just two views, it would be meaningful with multiple
> images.
> 
> From my experience in other standard committees, I know that "hard to
> implement" in standards leads to fragmentation and confusion. I think this
> should be either clarified (i.e. we have a working, shareable
> implementation) or removed. But that's just a personal opinion ;-)
> 

I totally agree with you. We need to clarify it on the next draft after
thinking about it more. 

> 
> >> 4) stereo-format: additional output formats include frame-sequential,
> >> checkerboard and anaglyph. For input, there are also formats that
> >> specify multiple pictures themselves. We could probably call that
> >> frame-sequential as well.
> >
> > I agree that some additional output formats might be necessary. I
> > guess frame-sequential (for both input and output) is necessary for
> > multiscopic, right?
> 
> It's not more necessary than for stereoscopic. My point was just that I
> find the omission of frame-sequential curious. It's unclear to me if it's
> by design, or just an oversight.
> 

We have just overlooked frame-sequential so we would add it on the next
draft. By the way, MPO is an example of frame-sequential, isn't it?

> 
> Thanks a lot for the discussion,
> Christophe

Received on Monday, 18 March 2013 05:59:17 UTC