RE: Color fidelity during transcoding

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:chris@w3.org] 
Sent: Friday, August 25, 2006 4:04 AM
To: Glenn A. Adams
Cc: public-tt@w3.org
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: 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

Received on Friday, 25 August 2006 13:45:20 UTC