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: Tue, 20 Jan 2015 11:15:20 +0000
To: Nigel Megitt <nigel.megitt@bbc.co.uk>, TTWG <public-tt@w3.org>, "Glenn Adams" <glenn@skynav.com>
Message-ID: <0981DC6F684DE44FBE8E2602C456E8AB016C146889@SS-IP-EXMB-01.screensystems.tv>
Agree.

+1 last point.

Although the problem described exists for all 3D objects, not just the subtitles!
A disparityOffset that is generally applied is interesting, but it might better be implemented as a disparityScaling factor. In fact I think that it might be a useful feature as a viewer preference in a display!

Best,
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 | www.screensystems.tv | https://twitter.com/screensystems


Visit us at
BVE, Excel London 24-26 February 2015 Stand No. N19

P Before printing, think about the environment-----Original Message-----
From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
Sent: 20 January 2015 11:11
To: John Birch; TTWG; Glenn Adams
Subject: Re: Issue-224 3D approach - disparity rather than (translation and condition)

On 20/01/2015 10:53, "John Birch" <John.Birch@screensystems.tv> wrote:

>Thanks Nigel,
>
>I have to admit that, although I can see how Glenn's proposal would
>work, I would have reservations about a double decode approach.
>For example, what happens in a double decode approach if the second
>document did not decode (e.g. the conditional resulted in an invalid
>document), or the second decode inadvertently had a side effect (e.g.
>the subtitle was clipped against a region boundary?).

Indeed. Or if strange authoring resulted in the two decodes being completely different, and not left eye/right eye views at all.


>The approach of a separate disparity value, that could be animatable,
>seem IMHO preferable. Decode once, then shift the resulting graphic as
>necessary (where each graphic gets shifted half the disparity in
>opposite directions).

Yes - actually the DVB way of doing it is to shift the whole disparity value, i.e. the total disparity is 2x the value. That's a minor detail though.


>In fact that's another issue for the conditional approach... Doc A
>would have to be left eye, Doc B would have to be right eye
>position.... but then neither document would work correctly as a non-stereoscopic document.
>With a disparity property, ignoring the property in a non-stereoscopic
>render would result in the correct intended positioning.

Agreed (both points).


A colleague has just pointed out to me that ideally, for comfort, 3D subtitles/captions need to be placed some fixed distance in front of whatever object they relate to, but the comfortable offset in disparity for that fixed distance is variable, and is dependent on screen size and viewer distance. For cinema screens, that's a problem because some of the audience is near the screen and some are far - the experience has been that only those about half way back get a good experience, given that there's only one screen. For environments with small numbers of audience members, for example televisions in living rooms, there's some hope of getting it right though. I would add to my proposal we should allow for a single per-document disparity offset value, to be added to the disparity value of the content. Then a condition could be used to set different offsets based on viewer preference, for example.

So the disparity to be used when rendering any single piece of content would be (tts:disparity + tts:disparityOffset).

Kind regards,

Nigel


>
>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 |
>www.screensystems.tv | https://twitter.com/screensystems

>
>Visit us at
>BVE, Excel London 24-26 February 2015 Stand No. N19
>
>P Before printing, think about the environment-----Original
>Message-----
>From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>Sent: 20 January 2015 10:46
>To: John Birch; TTWG; Glenn Adams
>Subject: Re: Issue-224 3D approach - disparity rather than (translation
>and condition)
>
>Thanks John, good point.
>
><length> is permitted to be a real number, either as a percentage or
>expressed in one of the length units. I agree that it is important that
>any implementation must use sub-pixel rendering to achieve a good
>audience experience.
>
>Kind regards,
>
>Nigel
>
>
>On 20/01/2015 10:43, "John Birch" <John.Birch@screensystems.tv> wrote:
>
>>Hi Nigel,
>>
>>Be advised that, as per the DVB specification, to achieve good
>>positioning in 3D space, sub pixel offsets are necessary.
>>This is particularly important if the disparity is animated (i.e. if
>>the subtitle is moved to follow an on screen object).
>>Quantisation of disparity to a single pixel level leads to perceivable
>>jumps in the subtitle depth which is extremely disconcerting to a viewer.
>>
>>It is dependent upon display (e.g. cinema or TV screen) and viewer!
>>but we have found that a 1/10 pixel difference is easily discernible.
>>
>>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 |
>>www.screensystems.tv | https://twitter.com/screensystems

>>
>>Visit us at
>>BVE, Excel London 24-26 February 2015 Stand No. N19
>>
>>P Before printing, think about the environment-----Original
>>Message-----
>>From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>>Sent: 20 January 2015 10:22
>>To: TTWG; Glenn Adams
>>Subject: Issue-224 3D approach - disparity rather than (translation
>>and
>>condition)
>>
>>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/t

>>s
>>_10
>>1
>>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/e

>>n
>>_30
>>0
>>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
>
>
>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


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 Tuesday, 20 January 2015 11:15:49 UTC

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