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