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

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

From: John Birch <John.Birch@screensystems.tv>
Date: Fri, 23 Jan 2015 09:57:40 +0000
To: Nigel Megitt <nigel.megitt@bbc.co.uk>, Glenn Adams <glenn@skynav.com>, TTWG <public-tt@w3.org>
Message-ID: <0981DC6F684DE44FBE8E2602C456E8AB016C14DA2F@SS-IP-EXMB-01.screensystems.tv>
Animated z-plane movement has already been demonstrated (and distributed) for 3D subtitles.
It is a technique used to compensate for when the underlying video pixels move in apparent depth over the duration of the subtitle presentation.

When reading a subtitle, eye tracking studies show a continuous jumping of the point of interest between the subtitle and the video.
It has been shown that it is more difficult for human vision to ‘accommodate’ objects at two significantly different apparent depths in 3D television (e.g. to read a subtitle) than it is to read subtitles on non-stereoscopic video.
Consequently it is ‘easier’ to read a subtitle that floats just above the underlying object and that tracks the apparent depth in the z-plane throughout the subtitle presentation duration.

Best regards,
John

John Birch | Strategic Partnerships Manager | Screen
Main Line : +44 1473 831700 | Ext : 2208 | Direct Dial : +44 1473 834532
Mobile : +44 7919 558380 | Fax : +44 1473 830078
John.Birch@screensystems.tv<mailto:John.Birch@screensystems.tv> | www.screensystems.tv<http://www.screensystems.tv> | https://twitter.com/screensystems


Visit us at
BVE, Excel London 24-26 February 2015 Stand No. N19
For our HbbTV Products visit our specialist site: http://www.hbbtv.co

P Before printing, think about the environment

From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: 23 January 2015 08:26
To: Glenn Adams; TTWG
Subject: Re: Issue-224 3D approach - disparity rather than (translation and condition)

From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Thursday, 22 January 2015 23:03


---------- Forwarded message ----------
From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>>
Date: Wednesday, January 21, 2015
Subject: Issue-224 3D approach - disparity rather than (translation and condition)
To: Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>>



On Wed, Jan 21, 2015 at 2:26 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<javascript:_e(%7B%7D,'cvml','nigel.megitt@bbc.co.uk');>> wrote:
I don't believe we have achieved consensus on this issue yet, so we can not consider it to be closed.

What other applications for the translate property do you have in mind?

I'm considering allowing it to be applied to span, to effect local position adjustments. Also animation effects. It may eventually be joined by rotate and scale, effectively mapping to a full transform property.

We don't have any requirements for such transform properties – in general we should limit what we implement to what we have an immediate need for, albeit in a way that's expandable later.

Even if we do one day have a requirement for full transforms, they should be relative to a baseline 3D position (or orthogonal if they're only 2D). You could think of the disparity as defining a third dimensional axis which one might also wish to transform within, so it should be considered a separate value.

Since there's no capability for conditionally adding a disparity as well as any other transforms, if you did want, say, an animated translation of a subtitle with a 3D depth value your proposal would result in the need to duplicate the animation conditionally on stereoLeft and stereoRight everywhere it occurs, with coordinates offset slightly. That would be unlikely to match the authorial intent and make it hard therefore to author, edit and even to review manually. It would also make the documents more verbose.

I expect it would be much more useful to define in a TTML document separate animatable coordinates in the x-y plane and the z plane, and allow the processor to do the maths to result in the correct display. The 'z' plane coordinates are a proxy since we don't have a genuine 3D model, just a stereoscopic disparity figure.






From: Glenn Adams <glenn@skynav.com<javascript:_e(%7B%7D,'cvml','glenn@skynav.com');>>
Date: Tuesday, 20 January 2015 21:47
To: Nigel Megitt <nigel.megitt@bbc.co.uk<javascript:_e(%7B%7D,'cvml','nigel.megitt@bbc.co.uk');>>
Cc: Pierre-Anthony Lemieux <pal@sandflow.com<javascript:_e(%7B%7D,'cvml','pal@sandflow.com');>>, TTWG <public-tt@w3.org<javascript:_e(%7B%7D,'cvml','public-tt@w3.org');>>
Subject: Re: Issue-224 3D approach - disparity rather than (translation and condition)

my position is that a translate property is more generally applicable than a diversity property, and the latter can be expressed using the former. pierre agrees with the latter, so i comsider this issue closed

On Tuesday, January 20, 2015, Nigel Megitt <nigel.megitt@bbc.co.uk<javascript:_e(%7B%7D,'cvml','nigel.megitt@bbc.co.uk');>> wrote:



> On 20 Jan 2015, at 18:15, Pierre-Anthony Lemieux <pal@sandflow.com<mailto:pal@sandflow.com>> wrote:
>
> Hi Nigel et al.,
>
>> are there pre-existing implementations that take
>> this approach of direct translation with conditional offset values?
>
> Issue-224 was motivated by a SMPTE liaison (SEPT 2012) and references
> D-Cinema subtitles (SMTPE ST 428-7). In the latter, rendering of
> subtitles to left- and right-eye stereoscopic images is controlled
> using an attribute ("ZPosition") that specifies the disparity (as a
> percentage of the root container) between left- and right-eye images.
>
> """When present, the Zposition attribute shall provide a value that
> specifies the horizontal distance between the “left eye” image center
> and the “right eye” image center - in order to generate a stereoscopic
> effect."""
>
> Minimally, I would think that the approach selected by TTWG should
> support the D-Cinema approach, which is implemented.

Thanks Pierre,

That sounds exactly coincident with my proposal for disparity.

Nigel

>
> Best,
>
> -- Pierre
>
>> On Tue, Jan 20, 2015 at 8:43 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>> wrote:
>> From: Glenn Adams <glenn@skynav.com<mailto:glenn@skynav.com>> Date: Tuesday, 20 January 2015 14:37
>>
>>
>>
>> On Tue, Jan 20, 2015 at 3:22 AM, Nigel Megitt <nigel.megitt@bbc.co.uk<mailto: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.
>>
>>
>> I discussed this thoroughly with Pierre before publishing this approach, and
>> we are both in agreement that it can handle the requirements. So that's what
>> I'm going with.
>>
>>
>> I don't disagree that an author can, with care, craft a document that will
>> display stereoscopically with the correct characteristics using this
>> technique, however "can handle" is not equal to "best way to express this
>> information".
>>
>> Pierre,  are there pre-existing implementations that take this approach of
>> direct translation with conditional offset values? 3D subtitles using a
>> single disparity value are in common usage as per the links I sent (now
>> below).
>>
>>
>>>
>>>
>>> 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
>>> [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
>>>
>>> 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
>>



This message may contain confidential and/or privileged information. If you are not the intended recipient you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. Screen Subtitling Systems Ltd. Registered in England No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, Claydon, Ipswich, Suffolk, IP6 0EQ
Received on Friday, 23 January 2015 09:58:17 UTC

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