W3C home > Mailing lists > Public > public-tt@w3.org > January 2015

Re: Issue-224 3D approach - disparity rather than (translation and condition)

From: Glenn Adams <glenn@skynav.com>
Date: Mon, 26 Jan 2015 11:31:03 -0700
Message-ID: <CACQ=j+ckgCAjQSKe28aJcfUFCayqaWPp0eqC+SEfo5Ta7U04mg@mail.gmail.com>
To: Nigel Megitt <nigel.megitt@bbc.co.uk>
Cc: TTWG <public-tt@w3.org>
On Mon, Jan 26, 2015 at 8:05 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:

>  From: Glenn Adams <glenn@skynav.com> Date: Monday, 26 January 2015 14:59
>
>
>
> On Mon, Jan 26, 2015 at 7:45 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
> wrote:
>
>>  Thanks Glenn,
>>
>>  I like it (as you might have guessed!). A couple of follow-up points:
>>
>>  1. Do we still need "usesStereo" for anything?
>>
>
>  it is still useful metadata
>
>
>>
>>  2. We should define that, relative to a value of 'zero', positive
>> values should result in the image appearing further from the viewer than
>> the plane of the display, and negative values should result in the image
>> appearing closer to the viewer. This is ambiguous right now.
>>
>
>  actually, i need to disallow negative values; the value is the
> horizontal disparity value, not depth; so it is up to author to choose
> desired disparity
>
>
>  Why do you need to disallow negative values? The solution doesn't work
> without them, or at best only defines that half of the range of depths can
> be supported, with the display being at one extreme of depth.
>

If you can explain to me what a negative horizontal distance means, then
perhaps I could allow. My understanding of the disparity value is that it
is always a positive horizontal distance. [1] But perhaps I am wrong.

[1] http://en.wikipedia.org/wiki/Binocular_disparity


>
>
>
>>
>>
>>  Plus a note to ourselves:
>>
>>  The disparity approach fits matches the request from SMPTE as well as
>> what's specified by ETSI/DVB. Where those latter differ is that in the case
>> of the SMPTE Digital Cinema spec the value is halved, and the left and
>> right image each offset by that half-value; whereas in the case of DVB the
>> value is applied equally both to the left and right image, resulting in
>> double the apparent disparity compared to the same value in the SMPTE spec.
>> As long as we're clear, which I think we are right now ("… is evenly
>> divided along the horizontal axis between left and right stereoscopic
>> images."), there's no problem.
>>
>>  Kind regards,
>>
>>  Nigel
>>
>>
>>   From: Glenn Adams <glenn@skynav.com>
>> Date: Sunday, 25 January 2015 21:50
>> To: Nigel Megitt <nigel.megitt@bbc.co.uk>
>> Cc: TTWG <public-tt@w3.org>
>> Subject: Re: Issue-224 3D approach - disparity rather than (translation
>> and condition)
>>
>>   I have decided to submit to the apparent preference for specifying
>> disparity directly, and have consequently changed from tts:translate to
>> tts:disparity in [1].
>>
>>  [1] https://dvcs.w3.org/hg/ttml/rev/9b8dc79e4004
>>
>> On Tue, Jan 20, 2015 at 3:22 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
>> wrote:
>>
>>> Glenn,
>>>
>>> I see you have created update
>>> https://dvcs.w3.org/hg/ttml/rev/abebbd0a303b
>>> to address issue-224, for 3D disparity. It looks as though the approach
>>> you've taken is to allow the same document to be processed twice, once
>>> for
>>> the left image and once for the right image for a stereoscopic display,
>>> and to allow translation to be specified, being dependent on a parameter
>>> and using the condition attribute.
>>>
>>> Can I propose an alternate way to achieve stereoscopic object placement
>>> that may be more amenable to simple, i.e. single pass, processing? This
>>> would be to add a tts:disparity style attribute, whose value would be a
>>> <length>, positive or negative. This would be inherited and animatable,
>>> and apply to region, div or p (possibly a span too). Positive values
>>> imply
>>> that the image is behind the plane of display and negative values imply
>>> that the image is in front of the plane of display.
>>>
>>> For example see [1] §4.2.1. Following the references, this seems to be
>>> how
>>> it's done in DVB [2].
>>>
>>> [1] ETSI TS 101 600 C1.1.1 (2012-05)
>>>
>>> http://www.etsi.org/deliver/etsi_ts/101600_101699/101600/01.01.01_60/ts_101
>>> 600v010101p.pdf
>>> <http://www.etsi.org/deliver/etsi_ts/101600_101699/101600/01.01.01_60/ts_101600v010101p.pdf>
>>> [2] ETSI EN 300 743 V1.4.1 (2011-10)
>>>
>>> http://www.etsi.org/deliver/etsi_en/300700_300799/300743/01.04.01_60/en_300
>>> 743v010401p.pdf
>>> <http://www.etsi.org/deliver/etsi_en/300700_300799/300743/01.04.01_60/en_300743v010401p.pdf>
>>>
>>> A good description from [2] (p. 34) is:
>>>
>>> > Disparity is the difference between the horizontal positions of a pixel
>>> >representing the same point in space in the right and left views of a
>>> >plano-stereoscopic image. Positive disparity values move the subtitle
>>> >objects enclosed by a subregion away from the viewer whilst negative
>>> >values move them towards the viewer. A value of zero places the objects
>>> >enclosed by that subregion in the plane of the display screen.
>>>
>>>
>>> And from a little further down:
>>>
>>> > A positive disparity shift value for example of +7 will result in a
>>> >shift of 7 pixels to the left in the left subtitle subregion image and a
>>> >shift of 7 pixels to the right in the right subtitle subregion image. A
>>> >negative disparity shift value of -7 will result in a shift of 7 pixels
>>> >to the right in the left subtitle subregion image and a shift of 7
>>> pixels
>>> >to the left in the right subtitle subregion image. Note that the actual
>>> >disparity of the displayed subtitle is therefore double the value of the
>>> >disparity shift values signalled in the disparity integer and/or
>>> >fractional fields […]
>>>
>>> Kind regards,
>>>
>>> Nigel
>>>
>>>
>>
>
Received on Monday, 26 January 2015 18:31:51 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 5 October 2017 18:24:20 UTC