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]

I agree that TTML needs to be explicit about how to map logical pixels to
physical pixels. The point of my prior message was to make it clear that,
at present, TTML content pixels are logical, not physical, and are tied to
the XSL-FO/CSS definitions.

I have been investigating use of mechanisms used by SVG to manage the
logical/physical mapping.

P.S. To be more precise, when I say "logical" above I mean a "TTML pixel",
i.e., the meaning of the 'px' unit when used in TTML source documents. When
I say "physical" above, I mean something closer to (but not necessarily the
same as) the physical display device used by an end-user.


On Tue, May 27, 2014 at 6:47 PM, Nigel Megitt <nigel.megitt@bbc.co.uk>wrote:

>  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.13makes 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> wrote:
>
>
> On Fri, May 23, 2014 at 1:45 AM, Michael Dolan <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]
>> 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> 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]
>> >Sent: Thursday, May 22, 2014 4:13 AM
>> >To: 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.
>> -----------------------------
>>
>>
>>
>