W3C home > Mailing lists > Public > public-tt@w3.org > August 2006

Re: Color fidelity during transcoding

From: Dave Singer <singer@apple.com>
Date: Fri, 25 Aug 2006 09:49:27 -0700
Message-Id: <p062309c5c114d9698693@[17.202.35.52]>
To: Chris Lilley <chris@w3.org>, "Glenn A. Adams" <gadams@xfsi.com>
Cc: public-tt@w3.org

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 Friday, 25 August 2006 16:51:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 November 2009 22:41:34 GMT