- From: Christophe de Dinechin <christophe@taodyne.com>
- Date: Fri, 15 Mar 2013 14:38:15 +0100
- To: "Soonbo Han" <soonbo.han@lge.com>
- Cc: "'Christophe de Dinechin'" <christophe@taodyne.com>, "'Dong-Young Lee'" <dongyoung.lee@lge.com>, dev@nano.taodyne.com, public-web-and-tv@w3.org
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, Christophe
Received on Friday, 15 March 2013 13:38:46 UTC