RE: Color fidelity during transcoding

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

RE: Color fidelity during transcoding

Glenn Adams

Chris,

Thanks for your comment. The TT WG has reviewed this comment has agreed
upon the following response:

Other than the use of sRGB, DFXP intentionally does not specify
conformance requirements on fidelity of color conversion from a source
document to a DFXP document. At this point, we have not identified any
requirements that would suggest adding this level of specificity.

Regards,
Glenn

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Chris Lilley
Sent: Saturday, June 03, 2006 12:39 AM
To: [hidden email]
Subject: Color fidelity during transcoding


Hello public-tt,

 I'm pleased to note that all colors are specified in the sRGB color
space.

Does TT AF DFXP express any conformance requirement regarding the
fidelity of the colors when converting to and from DFXP? I am thinking
not only of chrominance and white-point adaptation effects - which
should be minimal for modern equipment given that sRGB uses the 709
phosphor chromaticities - but more for differing assumptions on headroom
footroom, allowed colors, and corrections for flare, scene brightness,
surround and other viewing condition effects.

There is a useful discussion at
http://www.srgb.com/srgb709compatibility.html
How are sRGB and ITU-R BT.709-2 compatible?

Basically I am wondering how much guidance should be given in this area
such that reliable interchange between differing systems can be
achieved.

--
 Chris Lilley                    mailto:[hidden email]
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG



Reply | Threaded
Open this post in threaded view
|

Re: Color fidelity during transcoding

Chris Lilley

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: [hidden email] [mailto:[hidden email]] On
GAA> Behalf Of Chris Lilley
GAA> Sent: Saturday, June 03, 2006 12:39 AM
GAA> To: [hidden email]
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:[hidden email]
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG


Reply | Threaded
Open this post in threaded view
|

RE: Color fidelity during transcoding

Glenn Adams
In reply to this post by Glenn Adams

Your comment appears to make the assumption that the existing legacy caption and subtitle formats for which DFXP is designed to effect interchange have a defined model of color interoperability that correlates with color interoperability in the underlying presente video material. However, our investigation of this matter does not indicate there exists correlation or definition of interoperability regarding caption subtitle coloring. In other words, the designers of these legacy formats have similarly not defined color interoperability or compatibility with the level of precision you are asking for.

For example, EIA-608B, the current standard for US Analog Television states:

"A manufacturer may choose not to implement all the colors in Table 3. If the code for a non-implemented background color is received, the decoder should default to a black background."

"If the opacity attribute is not supported, the default opacity is opaque (or another opacity or background feature selected by the viewer or manufacturer)."

"The FCC caption decoder rules of 1991 gives manufacturers the option of implementing the color attributes defined in the rules or else displaying the captions monochromatically."

"Decoders may implement less than the full array of seven foreground colors."

Here the cited Table 3 above specifies the following colors:

Background White, Opaque
Background White, Semi-transparent
Background Green, Opaque
Background Green, Semi-transparent
Background Blue, Opaque
Background Blue, Semi-transparent
Background Cyan, Opaque
Background Cyan, Semi-transparent
Background Red, Opaque
Background Red, Semi-transparent
Background Yellow, Opaque
Background Yellow, Semi-transparent
Background Magenta, Opaque
Background Magenta, Semi-transparent
Background Black, Opaque
Background Black, Semi-transparent
Background Transparent
Foreground Black
Foreground Black Underline

No reference is cited in EIA-608B for the definition of these colors or their related color space.

In EIA-708, which is the US Digital Television Closed Caption Standard, the definition of RGB color is just slight expanded as follows:

<quote>
8.8 Color Representation

Foreground and background colors are specified in the Caption Commands as combinations of the red-green-blue color triad. Two bits are specified for each red, green, and blue color value which defines the intensity of each individual color component. Colors are specified as a group; i.e., (<red>, <green>, <blue>). The range of color specification is (0, 0, 0) [for black] through (3, 3, 3) [for bright white]. Bright red has a color value of (3, 0, 0); bright green has a color value of (0, 3, 0); and bright blue has a color value of (0, 0, 3). This coding scheme provides 64 different colors.
</quote>

Then the following requirements are placed on decoders (Section 9.20):

"At a minimum, decoders must support the 8 colors described in Table 21."

where Table 21 lists the following colors as defined by the color representation above:

Black 0 0 0
White 2 2 2
Red 2 0 0
Green 0 2 0
Blue 0 0 2
Yellow 2 2 0
Magenta 2 0 2
Cyan 0 2 2

The following language also applies (Section 9.20):

<quote>
When a decoder supporting this Minimum Color List receives an RGB value not in the list, it will map the received value to one of the values in the list via the following algorithm:

* All one (1) values are to be changed to 0
* All two (2) values are to remain unchanged
* All three (3) values are to be changed to 2

For example, the RGB value (1,2,3) will be mapped to (0,2,2), (3,3,3) will be mapped to (2,2,2) and (1,1,1) will be mapped to (0,0,0).
</quote>

In addition EIA-708 defines the following alternate minimum color list table 22:

Black 0 0 0
Gray 1 1 1
White 2 2 2
Bright White 3 3 3
Dark Red 1 0 0
Red 2 0 0
Bright Red 3 0 0
Dark Green 0 1 0
Green 0 2 0
Bright Green 0 3 0
Dark Blue 0 0 1
Blue 0 0 2
Bright Blue 0 0 3
Dark Yellow 1 1 0
Yellow 2 2 0
Bright Yellow 3 3 0
Dark Magenta 1 0 1
Magenta 2 0 2
Bright Magenta 3 0 3
Dark Cyan 0 1 1
Cyan 0 2 2
Bright Cyan 0 3 3

And adds the following:

"All decoders not supporting either one of the two color lists described above, must support the full 64 possible RGB color value combinations."

Again, as with EIA-608B, EIA-708 also does not specify any more formal definition of the color space in which these colors are defined.

Considering the European Subtitling standards and specifications, an examination of EBU Document Tech. 3264-E (February 1991), entitled "Specification of the EBU Subtitling data exchange format" indicates a complete absence of the word "color" or "colour", and only an indirect reference to certain color control codes in Appendix 2 as follows:

  0              1
0 Alpha black    Mosaic black
1 Alpha Red      Mosaic red
2 Alpha green    Mosaic green
3 Alpha yellow   Mosaic yellow
4 Alpha blue     Mosaic blue
5 Alpha magenta  Mosaic magenta
6 Alpha cyn      Mosaic cyan
7 Alpha white    Mosaic white

In the case of the DVB Subtitling Systems (ETSI EN 300 743), which is used predominantly in digital terrestrial television transmision in Europe, we have a non-character based subtitling format. Here, subtitle (caption) content is represented as pre-rasterized images that use a 2-, 4-, or 8-bit indexed colors (pseudo-colors) through either a specified or default CLUT. Two types of CLUT entries are supported: (1) Y8 Cr8 Cb8 T8 and (2) Y6 Cr4 Cb4 T2, where Y, Cr, and Cb components are defined as follows:

"Y, Cr and Cb have meanings as defined in ITU-R Recommendation BT.601 [3] and in ITU-R
Recommendation BT.656-4 [4]."

The following note is also supplied:

"Note that, whilst this subtitling specification defines CLUT entries in terms of Y, Cr, Cb and T values, the standard interface definition of digital television (ITU-R Recommendation BT.656-4 [4]) presents co-sited sample values in the order Cb,Y,Cr. Failure correctly to interpret the rendered bitmap image in terms of ITU-R Recommendation BT.656-4 [4] may result in incorrect colours and chrominance mistiming."

The T component is defined informally as:

"T_value: The Transparency output value of the CLUT for this entry. A value of zero identifies no transparency. The maximum value plus one would correspond to full transparency. For all other values the level of transparency is defined by linear interpolation."

Three default CLUTs are defined:

(1) 4-entry (Section 10.3):

<quote>
Let the CLUT-entry number be represented by a 2-bit field, the individual bits of which are called b1 and b2 where b1 is received first and b2 is received last.

The resulting colours are described here in terms of Red, Green and Blue contributions. To find the CLUT contents in terms of Y, Cr and Cb components, please see ITU-R Recommendation BT.601 [3].

if b1 == '0' && b2 == '0' {
  T = 100 %
}
if b1 == '0' && b2 == '1' {
  R = G = B = 100 %
  T = 0 %
}
if b1 == '1' && b2 == '0' {
  R = G = B = 0 %
  T = 0 %
}
if b1 == '1' && b2 == '1' {
  R = G = B = 50 %
  T = 0 %
}
</quote>

(2) 16-entry (Section 10.2):

<quote>
Let the CLUT-entry number be represented by a 4-bit field, the individual bits of which are called b1, b2, b3 and b4 where b1 is received first and b4 is received last. The value in a bit is regarded as unsigned integer that can take the values zero and one.

The resulting colours are described here in terms of Red, Green and Blue contributions. To find the CLUT contents in terms of Y, Cr and Cb components, please see ITU-R Recommendation BT.601 [3].

if b1 == '0' {
  if b2 == '0' && b3 == '0' && b4 == '0' {
    T = 100 %
  } else {
    R = 100 % × b4
    G = 100 % × b3
    B = 100 % × b2
    T = 0 %
  }
}
if b1 == '1' {
  R = 50 % × b4
  G = 50 % × b3
  B = 50 % × b2
  T = 0 %
}
</quote>

(3) 256-entry (Section 10.1):

<quote>
NOTE: The CLUT is divided in six sections: 64 colours of reduced intensity 0 to 50 %, 56 colours of higher intensity 0 to 100 %, 7 colours with 75 % transparency, 1 "colour" with 100 % transparency, 64 colours with 50 % transparency and 64 light colours (50 % white + colour 0 to 50 %).

Let the CLUT-entry number be represented by an 8-bit field, the individual bits of which are called b1, b2, b3, b4, b5, b6, b7 and b8 where b1 is received first and b8 is received last. The value in a bit is regarded as unsigned integer that can take the values zero and one.

The resulting colours are described here in terms of Red, Green and Blue contributions. To find the CLUT contents in terms of Y, Cr and Cb components, see ITU-R Recommendation BT.601 [3].

if b1 == '0' && b5 == '0' {
  if b2 == '0' && b3 == '0' && b4 == '0' {
    if b6 == '0' && b7 == '0' && b8 == '0'
      T = 100 %
    else {
      R = 100 % × b8
      G = 100 % × b7
      B = 100 % × b6
     T = 75 %
    }
  } else {
    R = 33,3 % × b8 + 66,7 % × b4
    G = 33,3 % × b7 + 66,7 % × b3
    B = 33,3 % × b6 + 66,7 % × b2
    T = 0 %
  }
}
if b1 == '0' && b5 == '1' {
  R = 33,3 % × b8 + 66,7 % × b4
  G = 33,3 % × b7 + 66,7 % × b3
  B = 33,3 % × b6 + 66,7 % × b2
  T = 50 %
}
if b1 == '1' && b5 == '0' {
  R = 16,7 % × b8 + 33,3 % × b4 + 50 %
  G = 16,7 % × b7 + 33,3 % × b3 + 50 %
  B = 16,7 % × b6 + 33,3 % × b2 + 50 %
  T = 0 %
}
</quote>

While the above define the fidelity of content representation, EN 300 743 states the following about decoders (IRDs - integrated receiver decoders):

<quote>
An IRD can present only a limited number of different colours simultaneously within a single region. The colours themselves may be chosen from a larger palette, but the number of choices from the palette that can be used per region is limited. The subtitling system directly supports IRDs that can present four colours, sixteen colours and 256 colours,
respectively. Three cases are distinguished:

- 4 colour IRDs. Pixel codes that use a 2-bit CLUT can be decoded into Y, Cr, Cb and T directly; pixel codes that use a 4-bit or 8-bit CLUT can be decoded also, but only if the region allows for decoding on a 2-bit CLUT. If such decoding is allowed, a reduction scheme is provided for translating the original 16 or 256 colours to the available 4 colours.

- 16 colour IRDs. Pixel codes that use a 2-bit or 4-bit CLUT can be decoded into Y, Cr, Cb and T directly; pixel codes that use an 8-bit CLUT can be decoded if the region allows for decoding on a 4-bit CLUT. If such decoding is allowed, a reduction scheme is provided for translating the original 256 colours to the available 16 colours. When pixel codes use a 4-bit CLUT, it is possible to switch to a 2-bit coding scheme within certain areas where at most 4 out of the 16 available colours are used. This requires a map table specifying which 4 CLUT entries are addressed with the 2-bit codes.

- 256 colour IRDs. All pixel codes can be decoded into Y, Cr, Cb and T directly, irrespective whether they use a 2-bit or 4-bit or an 8-bit CLUT. When a pixel code uses a 4-bit or an 8-bit CLUT, it is possible to switch to a 2-bit or a 4-bit coding scheme within a certain area where at most 4 or 16 out of the 256 available colours are used. This requires a map table specifying which 4 or 16 CLUT entries are addressed with the 2-bit or 4-bit codes, respectively.
</quote>

For conversion between different levels of supported colors (4, 16, 256), a set of reduction rules (Sections 9.1 - 9.3) and mapping tables (Sections 10.4 - 10.6) are pre-defined.

Now, neither the above definitions nor the two recommendations cited (BT.601 and BT.656) explicitly treat the subject of opto-electronic conversion, such as is defined by ITU-R BT.709-3. For example, no assumed chromaticity for equal primary signals (reference white) is defined. Furthermore, no assumption or reference is made by the above of use of a 709 based viewing environment (or any viewing environment for that matter) - a premise of the URI you cite on comparsion of sRGB and 709 viewing environments I might say.

Finally, as noted above, EN 300 743 uses representations in a different content domain than is the case for DFXP: namely raster images versus unrasterized character encoding. As such, EN 300 743 functionality was not considered as an input requirement for the purpose of supporting interchange to and from DFXP.

On might then reasonable conclude that introducing a concrete color transfer function that ensures optical interoperability of caption and subtitle coloration appears to go significantly beyond the state of the art with respect to the intended interchange of DFXP with legacy caption and subtitle content. While this may perhaps be an appropriate requirement for a more advanced, full featured timed text authoring format exchange profile, such as the AFXP profile that has been discussed in the past by the TTWG, there appears to be no legitimate rationale for such a requirement in DFXP.

The TTWG respectfully requests that you accept the unanimous consensus of the group on this matter. However, if you are able to show that the legacy caption and subtitle domain does require more exact treatment of optical (viewed) color transfer, then the group is open to adding a requirement to address this issue. If not, then we fear such work constitutes unnecessary effort for no identified benefactor.

Regards,
Glenn

-----Original Message-----
From: Chris Lilley [mailto:[hidden email]]
Sent: Friday, August 25, 2006 4:04 AM
To: Glenn A. Adams
Cc: [hidden email]
Subject: Re: Color fidelity during transcoding

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: [hidden email] [mailto:[hidden email]] On
GAA> Behalf Of Chris Lilley
GAA> Sent: Saturday, June 03, 2006 12:39 AM
GAA> To: [hidden email]
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:[hidden email]
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG


Reply | Threaded
Open this post in threaded view
|

Re: Color fidelity during transcoding

David Singer
In reply to this post by Chris Lilley

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: [hidden email] [mailto:[hidden email]] On
>GAA> Behalf Of Chris Lilley
>GAA> Sent: Saturday, June 03, 2006 12:39 AM
>GAA> To: [hidden email]
>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:[hidden email]
>  Interaction Domain Leader
>  Co-Chair, W3C SVG Working Group
>  W3C Graphics Activity Lead
>  Co-Chair, W3C Hypertext CG


--
David Singer
Apple Computer/QuickTime

Reply | Threaded
Open this post in threaded view
|

Re: Color fidelity during transcoding

Michael A Dolan

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.

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: [hidden email] [mailto:[hidden email]] On
>>GAA> Behalf Of Chris Lilley
>>GAA> Sent: Saturday, June 03, 2006 12:39 AM
>>GAA> To: [hidden email]
>>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:[hidden email]
>>  Interaction Domain Leader
>>  Co-Chair, W3C SVG Working Group
>>  W3C Graphics Activity Lead
>>  Co-Chair, W3C Hypertext CG
>
>
>--
>David Singer
>Apple Computer/QuickTime



Reply | Threaded
Open this post in threaded view
|

Re: Color fidelity during transcoding

Al Gilman

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-audio-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: [hidden email] [mailto:[hidden email]] On
>>>GAA> Behalf Of Chris Lilley
>>>GAA> Sent: Saturday, June 03, 2006 12:39 AM
>>>GAA> To: [hidden email]
>>>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:[hidden email]
>>>  Interaction Domain Leader
>>>  Co-Chair, W3C SVG Working Group
>>>  W3C Graphics Activity Lead
>>>  Co-Chair, W3C Hypertext CG
>>
>>
>>--
>>David Singer
>>Apple Computer/QuickTime



Reply | Threaded
Open this post in threaded view
|

Re: Color fidelity during transcoding

Chris Lilley
In reply to this post by Glenn Adams

On Friday, August 25, 2006, 3:45:08 PM, Glenn wrote:

GAA> Your comment appears to make the assumption that the existing
GAA> legacy caption and subtitle formats for which DFXP is designed to
GAA> effect interchange have a defined model of color interoperability
GAA> that correlates with color interoperability in the underlying
GAA> presente video material.

You are correct that I made such an assumption.

GAA> However, our investigation of this matter does not indicate there
GAA> exists correlation or definition of interoperability regarding
GAA> caption subtitle coloring. In other words, the designers of these
GAA> legacy formats have similarly not defined color interoperability or
GAA> compatibility with the level of precision you are asking for.

Many thanks (really, and not rhetorically) for the useful documentation
in your reply regarding color fidelity for captioning in existing
systems.

GAA> On might then reasonable conclude that introducing a concrete
GAA> color transfer function that ensures optical interoperability of
GAA> caption and subtitle coloration appears to go significantly beyond
GAA> the state of the art with respect to the intended interchange of
GAA> DFXP with legacy caption and subtitle content.

You have convinced me that this is so. Thus, conversion to DFXP does not
introduce quality loss compared to the original in terms of color
fidelity.

GAA>  While this may
GAA> perhaps be an appropriate requirement for a more advanced, full
GAA> featured timed text authoring format exchange profile, such as the
GAA> AFXP profile that has been discussed in the past by the TTWG, there
GAA> appears to be no legitimate rationale for such a requirement in DFXP.

GAA> The TTWG respectfully requests that you accept the unanimous
GAA> consensus of the group on this matter.

I am happy to do so and withdraw my objection.


--
 Chris Lilley                    mailto:[hidden email]
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG


Reply | Threaded
Open this post in threaded view
|

Re: Color fidelity during transcoding

Chris Lilley
In reply to this post by David Singer

On Friday, August 25, 2006, 6:49:27 PM, Dave wrote:

DS> I'm not sure I understand what's going on here.  We needed to define
DS> what the numeric R G and B values in our colours meant.  We say that
DS> they are as defined in the sRGB specification.

Yes, I'm very clear on that point.

DS> If you then take our content and render it on a system with different
DS> colour characteristics, it's your job to work out the colour
DS> transforms and corrections that need to be applied.  This is strictly
DS> out of scope for a timed text specification.  It's in scope for the
DS> sRGB specification, and I believe it's covered there.

Since timed text is aimed at both broadcast systems and web-based systems, it seemed that a small amount of guidance was merited when moving between one and the other.

DS> We could insert an informative note that if timed text is composed
DS> with content, or rendered onto drawing surfaces, that have other
DS> colour spaces or formats, then the colours may need conversion to
DS> preserve visual fidelity, but more than that is surely not our job.

That was the area where I suspected some advice and guidance would help.

DS> Unless you feel that sRGB is under-specified, whereupon we should
DS> choose a colour space that is fully specified instead, of course.

I consider it to be well specified, and indeed I contributed to the specification. I am also aware that it uses very different viewing conditions to broadcast color spaces. Some guidance to implementors therefore seemed in order.

DS> So sure, I agree, you can't take sRGB values and blast them onto a
DS> 709 display without doing colour space conversion,

Good

DS>  but do we suggest
DS> you can?  Why would you think you could?

I don't think you can, but then I have some grasp of color theory. I suspect that people who do not, will do exactly that.



--
 Chris Lilley                    mailto:[hidden email]
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG