W3C home > Mailing lists > Public > public-web-and-tv@w3.org > March 2013

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

From: Christophe de Dinechin <christophe@taodyne.com>
Date: Fri, 15 Mar 2013 14:38:15 +0100
Cc: "'Christophe de Dinechin'" <christophe@taodyne.com>, "'Dong-Young Lee'" <dongyoung.lee@lge.com>, dev@nano.taodyne.com, public-web-and-tv@w3.org
Message-Id: <F289D083-8086-4871-BB83-A04610D1BF26@nano.taodyne.com>
To: "Soonbo Han" <soonbo.han@lge.com>
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?

> 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/lYIkHAJ6cZY/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).

> 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?

> 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 ;-)

>> 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.

Thanks a lot for the discussion,
Received on Friday, 15 March 2013 13:38:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:57:15 UTC