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]

This is an issue on IMSC 1 - if that document needs a pictorial model to
help define its scope please go ahead and propose one.

If there's an issue additionally on TTML please raise that too.



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

>The concept of a related video object is in TTML1.  Relationships exist
>and
>models are already defined which have been recognized as a problem.
>
>If you want TTML[1|2] to be a pure text object, I'm afraid we're long past
>that.
>
>-----Original Message-----
>From: Nigel Megitt [mailto:nigel.megitt@bbc.co.uk]
>Sent: Friday, May 23, 2014 3:18 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]
>
>I agree generally, however I think the more generic way it is described in
>TTML is entirely appropriate for its scope. I think a reference model
>would
>be an excellent addition to IMSC however, perhaps in the Scope section, to
>explain the extra constraints that apply.
>
>Nigel
>
>
>On 22/05/2014 17:45, "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.
>>
>>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/ttm
>>>l-w
>>>w
>>>-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.
>>-----------------------------
>>
>>
>
>
>
>-----------------------------
>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.
>-----------------------------
>
>



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

Received on Friday, 23 May 2014 14:32:08 UTC