Re: Action-201 and Issue-225

On Mon, Sep 9, 2013 at 4:28 AM, Nigel Megitt <nigel.megitt@bbc.co.uk> wrote:

>  To add to/summarise both Mike's and John's well articulated points, with
> which I agree, and try to take this back to Issue-225:
>
>    - TTML spatial coordinates may not have a 1:1 mapping with actual
>    display pixels
>    - There are potentially other mechanisms needed to arrange for TTML
>    content to appear in the desired position relative to video/picture areas
>    that are not the same shape as tt:tt.tt:extent some of which have been
>    defined as extensions within related specifications.
>    - The question of which is the minimum or maximum of horizontal width
>    and vertical width, which is the root of Issue-225, remains unresolved,
>    i.e. should it be a numerical calculation not taking into account aspect
>    ratio (of pixels or otherwise) or should it be based on greater knowledge
>    of the screen size and shape that the presentation renderer might have,
>    perhaps including pixel aspect ratio?
>
>
>  I don't want to pre-empt what Sean might say but I'd have thought it
> would be appropriate to raise separate issues for the first two of these
> points, and relate them to Issue-225, so that we can ensure all are
> resolved, if such issues have not already been raised.
>

Note that CSS3 has altered the definition of 'px' from what was defined in
CSS2 (as used by XSL-FO and TTML1).

In CSS2, it always meant a reference pixel based on the size of 1/90th of
an inch at a viewing distance of 28in, i.e., a viewing angle of 0.0227deg.

In CSS3 this reference pixel has been changed to 1/96th of an inch at 28in
distance, or a viewing angle of 0.0213deg.

In addition, CSS3 defines the 'px' unit to mean the same as 1/96th of an
inch, and then allows such absolute units {cm,mm,in,pt,pc,px} to be
interpreted according to one of two strategies: (1) as physical
measurements (presumably at the screen surface rather than the viewing
distance) or (2) as the nearest whole number of device pixels that
approximates the (new) reference pixel.

It is further recommended that high dpi devices use the first strategy, and
that low dpi devices or devices with "unusual viewing distances" use the
second strategy. See [1] for further info.

[1] http://dev.w3.org/csswg/css-values/#absolute-lengths

Neither of these strategies equate 'px' with device pixel.


>
>  Nigel
>
>
>   On 09/09/2013 10:21, "John Birch" <John.Birch@screensystems.tv> wrote:
>
>    Dear Mike, All,****
>
> ** **
>
> Just for your information J… within the EBU-TT group we have had lengthy
> discussions about pixels and aspect ratios.****
>
> ** **
>
> In EBU-TT, the root container is directly mapped to the full extent of the
> active video area of a presentation. There is an underlying assumption that
> the video used at authoring has a 1:1 correspondence with the presentation
> (in both temporal and visual terms).****
>
> Consequently, using pixels in an EBU-TT document has a restricted meaning.
> In effect pixels become simply a subdivision or unit of the root container.
> ****
>
> ** **
>
> Clearly you can define the extent of the root container using pixels, but
> the values chosen for extent may not equate to the actual video resolution…
> for example you could define extent as 1440 x 1152, but the matching
> presentation resolution might be 720 x 576 (D1).****
>
> *In this case there is an implicit 2:1 scaling between pixel dimensions
> used within the EBU-TT document and the actual presented pixels the viewer
> might see.*
>
> ** **
>
> Aspect ratio in EBU-TT is actually irrelevant, since we conceptually
> always draw on the video canvas and measure our content using units pinned
> to that context. Thus our content ‘stretches to fit’ the active video
> canvas. It is accepted that there is no mechanism within EBU-TT to ensure
> that a circle remains a circle upon presentation… this is considered to be
> ‘out of scope’ for EBU-TT. It is more important to retain a 1:1
> correspondence between a subtitle pixel and a picture pixel than to retain
> a ‘correct aspect ratio’.****
>
> ** **
>
> However, to support downstream manipulations of the video we also provide
> a mechanism within EBU-TT to *signal* various metadata about the assumed
> context. This metadata includes the aspect ratio of the underlying video
> and information about any black bars (letter box or pillar box) present in
> the video. The rationale for including this *information* is that
> downstream processes may alter the video context (for example removing
> black bars from the video, pan scan or centre crop etc.). By providing
> metadata about letter boxing and A/R, a downstream process can determine
> the *positions of subtitle content **with respect to the active picture
> presentation*. The downstream process is thus equipped to make informed
> decisions about re-positioning subtitle content to retain or modify this
> positioning. This last point might need clarification. In EBU-TT the extent
> is the *active video*, but the content position can (by using optional
> metadata) effectively be determined (by a downstream processor) with
> respect to the *active picture* (which may be smaller than the active
> video).****
>
> ** **
>
> I accept that in the wider sphere of TTML it may be necessary to support
> authoring in a context that is independent of the target context, and also
> to describe how the authoring context is transformed into the presentation
> context, but for subtitling applications I do not believe this is necessary.
> ****
>
> ** **
>
> Best regards,****
>
> John****
>
> ** **
>
> *John Birch | Strategic Partnerships Manager | Screen
> *Main Line : +44 1473 831700 | Ext : 270 | 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
> IBC, Hall 1 Stand C49, The RAI, Amsterdam, 13-17 September*
>
> *P** Before printing, think about the environment*
>
>  *From:* Michael Dolan [mailto:mdolan@newtbt.com <mdolan@newtbt.com>]
> *Sent:* 06 September 2013 20:01
> *To:* 'Timed Text Working Group'
> *Subject:* RE: Action-201 and Issue-225****
>
> ** **
>
> Sorry to miss the last half of the call yesterday, so maybe this was
> addressed.  But before we talk more about pixels, don’t we need to first
> extract ourselves from the normative definition of px being related only to
> the decoder physical display? I’m not opposed to adding pixel aspect ratio,
> but aspect ratio of what?  I think current applications actually ignore
> this today and define an authoring coordinate system.  In the case of DECE,
> it is 1 *coded* sample of the related video object. It is often
> non-square.****
>
> ** **
>
> See highlight below for TTML1SE.****
>
> ** **
>
>                 Mike****
>
> ** **
>
> ** **
>
> TTML1SE, 8.3.12 <length>****
>
> ** **
>
> The semantics of the unit of measure px (pixel) are as defined by [XSL
> 1.1]<https://dvcs.w3.org/hg/ttml/raw-file/tip/ttml2/spec/ttml2.html#xsl11>,
> § 5.9.13****
>
> ** **
> XSL 1.1, 5.9.13.1 Pixels****
>
> XSL interprets a 'px' unit to be a request for the formatter to choose a
> device-dependent measurement that approximates viewing one pixel on a
> typical computer monitor. This interpretation is follows: ****
>
> 1.    The preferred definition of one 'px' is:****
>
> o    The actual distance covered by the largest integer number of device
> dots (the size of a device dot is measured as the distance between dot
> centers) that spans a distance less-than-or-equal-to the distance specified
> by the arc-span rule in http://www.w3.org/TR/REC-CSS2//syndata.html#x39<http://www.w3.org/TR/REC-CSS2/syndata.html#x39>or superceding errata.
> ****
>
> o    A minimum of the size of 1 device dot should be used.****
>
> o    This calculation is done separately in each axis, and may have a
> different value in each axis.****
>
> 2.    However, implementors may instead simply pick a fixed conversion
> factor, treating 'px' as an absolute unit of measurement (such as 1/92" or
> 1/72").****
>
> *Note:*****
>
> Pixels should not be mixed with other absolute units in expressions as
> they may cause undesirable effects. Also, particular caution should be used
> with inherited property values that may have been specified using pixels.*
> ***
>
> If the User Agent chooses a measurement for a 'px' that does not match an
> integer number of device dots in each axis it may produce undesirable
> effects, such as:****
>
> ·         moiré patterns in scaled raster graphics****
>
> ·         unrenderable overlapping areas when the renderer rounds fonts
> or graphics sizes upward to its actual dot-size****
>
> ·         large spaces between areas when the renderer rounds fonts or
> graphics sizes downward to its actual dot-size****
>
> ·         unreadable results including unacceptably small text/layout
> (for example, a layout was calculated at 72 dpi [dots per inch], but the
> renderer assumed the result was already specified in device dots and
> rendered it at 600 dpi).****
>
> Stylesheet authors should understand a pixel's actual size may vary from
> device to device:****
>
> ·         stylesheets utilizing 'px' units may not produce consistent
> results across different implementations or different output devices from a
> single implementation****
>
> ·         even if stylesheets are expressed entirely in 'px' units the
> results may vary on different devices****
>
> ** **
>
> ** **
>
> Regards,****
>
> ** **
>
>                 Mike****
>
> ** **
>
> *From:* Nigel Megitt [mailto:nigel.megitt@bbc.co.uk<nigel.megitt@bbc.co.uk>]
>
> *Sent:* Friday, September 06, 2013 2:57 AM
> *To:* Timed Text Working Group
> *Subject:* Action-201 and Issue-225****
>
> ** **
>
> In the absence of automated change notifications from the action and issue
> tracker, here is a manual notification that I've updated Issue-225<http://www.w3.org/AudioVideo/TT/tracker/issues/225>as per my Action-201 from yesterday. The update to Issue-225 is:
> ****
>
> ** **
>
> As per action-201 <http://www.w3.org/AudioVideo/TT/tracker/actions/201>[1], I've looked to see if pixel aspect ratio would or should affect the
> meaning of vmin and vmax.
>
> [1] https://www.w3.org/AudioVideo/TT/tracker/actions/201
>
> It is possible to construct an example where taking pixel aspect ratio in
> to account to calculate actual dimensions would give a different result
> from omitting it. However the root definition of vmin and vmax, in [2], is
> unclear or at best non-specific about the intended behaviour. It appears to
> depend on how the viewport size itself was defined, i.e. if in physical
> units then vmin and vmax should relate to those physical sizes but if in
> pixels then vmin and vmax should relate to the pixel dimensions.
>
> [2] http://www.w3.org/TR/css3-values/#viewport-relative-lengths
>
> In TTML we only define a logical coordinate plane but we do allow
> ttp:pixelAspectRatio to be defined. I think there is very likely a use case
> for referring to the minimum or maximum size after pixelAspectRatio
> conversion to relate these terms to 'real' sizes. Certainly this should be
> considered and made explicit in the definition of the attributes.
>
> For reference, here's one contrived example in which vmin and vmax have
> different values depending on whether the extent is multiplied by the
> pixelAspectRatio before the min/max decision or after it. Take an extent of
> 400w x 300h and a pixel aspect ratio of "1 1.5". Before conversion
> vmin=300/100 and vmax=400/100. Taking pixelAspectRatio into account, the
> min/max choice is between 400x1=400 and 300x1.5=450, and the decision is
> made the other way, so, after returning to our extent coordinate system,
> vmin=400/100 whereas vmax=300/100.
>
> The question comes down to whether vmin and vmax apply numerically to our
> extent or is intended to compare actual sizes.****
> Nigel Megitt, 6 Sep 2013, 09:44:24****
>
> ** **
>
> ** **
>
> I've also updated Action-201 and set it to Pending Review.****
>
> ** **
>
> Kind regards,****
>
> ** **
>
> Nigel****
>
> ** **
>
> *--*****
>
> ** **
>
> *Nigel Megitt*****
>
> Lead Technologist, BBC Technology, Distribution & Archives****
>
> Telephone: +44 (0)208 0082360****
>
> BC4 A3 Broadcast Centre, Media Village, 201 Wood Lane, London W12 7TP****
>
> ** **
>
>  ****
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.****
>
> ---------------------****
>
> 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
>    ­­
>
>
>
> ----------------------------
>
> http://www.bbc.co.uk
> This e-mail (and any attachments) is confidential and may contain personal
> views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in
> reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
> ---------------------
>