RE: Color fidelity during transcoding

Al,

It is not clear from your message below whether you are making a comment
on
the DFXP 2nd LC text, and if so, if you are expecting a response (since
the
comment period had lapsed).

In any case, in reviewing the DFXP spec, I see that it does not cite
WCAG1.0
in regards to content conformance. However, it does cite UUAG in the
context
of processor conformance (section 3.2, item 5):

"the processor should satisfy the user agent accessibility guidelines
specified by [UAAG]."

I would suggest we resolve this disparity by adding the following
sentence
at the end of section 3.1, item 5:

"In addition, the infoset should satisfy the web content accessibility
guidelines specified by [WCAG]."

and add a normative reference to WCAG.

Would this be a satisfactory resolution of your concerns?

G.



-----Original Message-----
From: public-tt-request@w3.org [mailto:public-tt-request@w3.org] On
Behalf Of Al Gilman
Sent: Friday, August 25, 2006 4:19 PM
To: public-tt@w3.org
Subject: Re: Color fidelity during transcoding


In the context of a thread with tail at:
http://lists.w3.org/Archives/Public/public-tt/2006Aug/thread.html#msg10
At 10:36 AM -0700 8/25/06, Michael A Dolan wrote:
>Chris and all,
>
>I concur with DaveS.  Loss if fidelity and other considerations in 
>color space conversion and gamma correction is an interesting 
>problem, but both not specific to TT or the color model we've chosen 
>(sRGB).  And, if 709, then what about YCrCb, YUV, etc, etc?
>
>It may be helpful to informatively point the reader to an 
>authoritative reference on the topic of color space conversion and 
>gamma correction.  But I don't see how the TT spec would benefit 
>from saying much of anything directly on the topic.

** summary

1) I want to set a hook claiming that there is an accessibility
interest in this topic

... but

2) I think I pretty much come down where Mike Dolan is on the mood of
what DXFP should say (imperative (= normative) vs. informative). DFXP
should include informative mention of accessibility guidelines for
the use of color in captions, and this should be in such a way that
authors of DFXP formatted content *and* those transcoding DFXP into
delivery channels are aware that they have *both, independently* to
pay attention to these guidelines.

** details

3) existence proof for accessibility interest -- WCAG 2.0 guidelines 
Success Criterion 1.4.1

http://www.w3.org/TR/2006/WD-WCAG20-20060427/guidelines.html#visual-audi
o-contrast

4) DFXP is targeted to be used for captions, that should meet
accessibility guidelines as presented at the final User Interface.

5) Some of the service delivery chains that will use DFXP
representations of timed text are Web delivery chains, including in
the mobile space where we are not so impeded by legacy standards and
channels. W3C takes an interest in providing end-to-end assurances of
interoperability between the people speaking the material that gets
included in captions and the people reading the captions. So at least
for Web use cases, flowing down Human Factors requirements from the
system level to the DXFP document are fair game. Nothing breaks
access faster than long chains of services each of which says it's
"not my problem."

I think that this could be why the Working Group might prefer to duck
this
issue, but Cris in his Domain Lead role feels compelled to press the
issue.

* next steps; could we perhaps?:

a) stipulate that DXFP docs will be used a lot to feed service
delivery chains where they don't have a lot of control over the
final color?

b) So shouldn't we warn authors of this?

c) Leave the color rep as is, presuming that this is fine enough, if
faithfully rendered, to meet the great preponderance of fidelity
needs. This format should afford color precision at a level which is
modest overkill for the great preponderance of applications.

d) Warn those who are going to use the color feature in this format
about common system-level risks (illegible color contrasts, lack of
user control, lack of definition in the controlling specs in the last
mile distribution link,...) that bear on this aspect of their content;
along with what known strategies they may wish to apply to mitigate
these
risks (pointers to accessibility guidelines, etc.)?

Al

>
>Regards,
>
>         Mike
>
>At 09:49 AM 8/25/2006, Dave Singer wrote:
>
>>I'm not sure I understand what's going on here.  We needed to 
>>define what the numeric R G and B values in our colours meant.  We 
>>say that they are as defined in the sRGB specification.
>>
>>If you then take our content and render it on a system with 
>>different colour characteristics, it's your job to work out the 
>>colour transforms and corrections that need to be applied.  This is 
>>strictly out of scope for a timed text specification.  It's in 
>>scope for the sRGB specification, and I believe it's covered there.
>>
>>We could insert an informative note that if timed text is composed 
>>with content, or rendered onto drawing surfaces, that have other 
>>colour spaces or formats, then the colours may need conversion to 
>>preserve visual fidelity, but more than that is surely not our job.
>>
>>Unless you feel that sRGB is under-specified, whereupon we should 
>>choose a colour space that is fully specified instead, of course.
>>
>>So sure, I agree, you can't take sRGB values and blast them onto a 
>>709 display without doing colour space conversion, but do we 
>>suggest you can?  Why would you think you could?
>>
>>
>>
>>At 10:03  +0200 25/08/06, Chris Lilley wrote:
>>>On Thursday, July 27, 2006, 5:07:48 PM, Glenn wrote:
>>>
>>>GAA> Chris,
>>>
>>>GAA> Thanks for your comment. The TT WG has reviewed this comment has
agreed
>>>GAA> upon the following response:
>>>
>>>GAA> Other than the use of sRGB, DFXP intentionally does not specify
>>>GAA> conformance requirements on fidelity of color conversion from a
source
>>>GAA> document to a DFXP document. At this point, we have not
identified any
>>>GAA> requirements that would suggest adding this level of
specificity.
>>>
>>>I am afraid that this response does not satisfy me. I suspect that 
>>>the technical aspects of sRGB, in particular the corrections for 
>>>flare and ambient illumination, have been insufficiently 
>>>considered.
>>>
>>>Note that sRGB, while using a 709-compatible phosphor and white 
>>>point chromaticity, has different assumptions to 709 regarding 
>>>flare and ambient illumination. RGB values cannot therefore be 
>>>simply transferred unchanged between the two systems while 
>>>maintaining acceptable broadcast quality. For a system aimed at 
>>>use in studio broadcast equipment, this is unacceptably lax and 
>>>will lead to interoperability problems.
>>>
>>>
>>>
>>>GAA> Regards,
>>>GAA> Glenn
>>>
>>>GAA> -----Original Message-----
>>>GAA> From: public-tt-request@w3.org [mailto:public-tt-request@w3.org]
On
>>>GAA> Behalf Of Chris Lilley
>>>GAA> Sent: Saturday, June 03, 2006 12:39 AM
>>>GAA> To: public-tt@w3.org
>>>GAA> Subject: Color fidelity during transcoding
>>>
>>>
>>>GAA> Hello public-tt,
>>>
>>>GAA>  I'm pleased to note that all colors are specified in the sRGB
color
>>>GAA> space.
>>>
>>>GAA> Does TT AF DFXP express any conformance requirement regarding
the
>>>GAA> fidelity of the colors when converting to and from DFXP? I am
thinking
>>>GAA> not only of chrominance and white-point adaptation effects -
which
>>>GAA> should be minimal for modern equipment given that sRGB uses the
709
>>>GAA> phosphor chromaticities - but more for differing assumptions 
>>>on headroom
>>>GAA> footroom, allowed colors, and corrections for flare, scene
brightness,
>>>GAA> surround and other viewing condition effects.
>>>
>>>GAA> There is a useful discussion at
>>>GAA> http://www.srgb.com/srgb709compatibility.html
>>>GAA> How are sRGB and ITU-R BT.709-2 compatible?
>>>
>>>GAA> Basically I am wondering how much guidance should be given in
this area
>>>GAA> such that reliable interchange between differing systems can be
>>>GAA> achieved.
>>>
>>>
>>>
>>>
>>>
>>>--
>>>  Chris Lilley                    mailto:chris@w3.org
>>>  Interaction Domain Leader
>>>  Co-Chair, W3C SVG Working Group
>>>  W3C Graphics Activity Lead
>>>  Co-Chair, W3C Hypertext CG
>>
>>
>>--
>>David Singer
>>Apple Computer/QuickTime

Received on Thursday, 14 September 2006 19:30:00 UTC