Re: ISSUE-318 (HRM glyph copy assumes no sub-pixel positioning): Hypothetical Render Model glyph copy assumes no sub-pixel positioning [TTML IMSC 1.0]

We need to make the distinction between units of expression used within TTML documents and their resolution to physical implementations, both spatially and temporally. Implementations may find that the resolved expression does not match precisely to the display's capability.

We should be careful about this both ways, i.e. what implementations should do when faced with a non-exact match, and what document authors should do to reduce the impact of non-exact matches. The wording in [XSL 1.1]<http://www.w3.org/TR/2013/REC-ttml1-20130924/#xsl11>, § 5.9.13 makes good points about the mapping of pixels to devices and the care that should be taken, for example.

I agree that the TTML spec should (continue to) not reference display addressing, but it's clear from what folk are trying to do with specs that are more constrained with respect to display conditions that we may need to say more about rounding, quantisation etc.

Nigel


On 24/05/2014 01:16, "Glenn Adams" <glenn@skynav.com<mailto:glenn@skynav.com>> wrote:


On Fri, May 23, 2014 at 1:45 AM, Michael Dolan <mdolan@newtbt.com<mailto:mdolan@newtbt.com>> wrote:
This and the other comments covering sub-frame and sub-resolution time-space addressing expose a disconnect in the system model for TTML, especially where it is being sync'd to a related (video) media object. Complicating matters is that TTML1 constantly refers directly or indirectly to display addressing (not coded video addressing). This is a very serious disconnect.

Actually, TTML1 is based on the XSL-FO pixel and coordinate system, which in turn is based on the corresponding CSS pixel and coordinate system. Neither CSS pixel or coordinate system corresponds (except by accident) with a display pixel or coordinate system. See 8.3.9 [1]:

The semantics of the unit of measure px (pixel) are as defined by [XSL 1.1]<http://www.w3.org/TR/2013/REC-ttml1-20130924/#xsl11>, § 5.9.13.

[1] http://www.w3.org/TR/2013/REC-ttml1-20130924/#style-value-length

If folks have been interpreting pixels in TTML1 as denoting display pixels, then there is a disconnect in understanding.




It's my understanding that this WG has evolved to not continuing to reference the display addressing, since that is impossible for a document author to know.

Either way, I think before we continue to explore these addressing issues, we need a reference model (picture).  Else, we'll not reach closure on any of the addressing issues.

        Mike

-----Original Message-----
From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk<mailto:nigel.megitt@bbc.co.uk>]
Sent: Thursday, May 22, 2014 9:00 AM
To: Michael Dolan; 'Timed Text Working Group'
Subject: Re: ISSUE-318 (HRM glyph copy assumes no sub-pixel positioning): Hypothetical Render Model glyph copy assumes no sub-pixel positioning [TTML IMSC 1.0]

On 22/05/2014 15:44, "Michael Dolan" <mdolan@newtbt.com<mailto:mdolan@newtbt.com>> wrote:

>This and issue 317 call to light the difference between alignment with
>the related media (video) object versus display rendering.

Yes - I've been thinking the same thing.

> All that can really be contemplated by an author is alignment with the
>related coded video, not how the resulting  decoded video+text is mapped
>to an (entirely unknown to the author) display resolution, framerate, etc.

I disagree here - all that can be contemplated by an author is alignment
with the video available at the time of authoring. Intervening workflows
need to be taken into account. The related encoded video that is made
available may have a different display resolution, framerate etc, and the
decoded video and text will have yet another display resolution and
framerate.

>
>The HRD is ONLY about document conformance.

This brings to mind issue 315 too, which defines a maximal content
constraint that I suggest should be changed to a minimal processor
constraint. I'd do consider doing the same for the HRM, i.e. it can be
used to define test content that a minimally compliant processor must be
able to process successfully, or conversely, can be used to check content
that a processor under test fails to process correctly to see if the cause
is a fault in the processor fault or over-complex content.

In both cases by specifying minimal processor compliance it is then
possible to create a processor sub-profile with a higher minimal
compliance level that is also able to process documents conforming to the
base-level profile. This opens up the path to future enhancements, rather
than blocking it at source, or requiring a whole new, almost identical
content profile that differs only in maximum compliance thresholds.

Kind regards,

Nigel


>
>       Mike
>
>-----Original Message-----
>From: Timed Text Working Group Issue Tracker
>[mailto:sysbot+tracker@w3.org<mailto:sysbot%2Btracker@w3.org>]
>Sent: Thursday, May 22, 2014 4:13 AM
>To: public-tt@w3.org<mailto:public-tt@w3.org>
>Subject: ISSUE-318 (HRM glyph copy assumes no sub-pixel positioning):
>Hypothetical Render Model glyph copy assumes no sub-pixel positioning
>[TTML IMSC 1.0]
>
>ISSUE-318 (HRM glyph copy assumes no sub-pixel positioning): Hypothetical
>Render Model glyph copy assumes no sub-pixel positioning [TTML IMSC 1.0]
>
>http://www.w3.org/AudioVideo/TT/tracker/issues/318
>
>Raised by: Nigel Megitt
>On product: TTML IMSC 1.0
>
>IMSC 1 FPWD includes in the Hypothetical Render Model a test for how two
>glyphs can be considered identical for buffer copying purposes. This does
>not take into account sub-pixel positioning of anti-aliased text, which
>would result in different per-pixel buffer values for a glyph that would
>otherwise be considered identical using the current criteria.
>
>For presentation devices that layout text using sub-pixel accuracy and
>render glyphs with anti-aliasing this test of identity will fail
>resulting in wrongly painted glyphs.
>
>I propose that an extra criterion is added to the glyph identity test
>that the post-layout sub-pixel offset relative to the pixel grid,
>horizontally and vertically, is identical.
>
>[1]
>https://dvcs.w3.org/hg/ttml/raw-file/ea1a92310a27/ttml-ww-profiles/ttml-ww
>-profiles.html#paint-text
>
>
>
>



-----------------------------
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.
-----------------------------