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] 
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. <http://www.bbc.co.uk> 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.

---------------------