2002.04.05 09:19 "Saturation problem with REC601 YCbCr TIFF files", by Peter Vince

Dear Sam et al,

I believe there is a problem handling YCbCr files with the TIFF Library, as two separate applications ("The GIMP" under Unix, and "GraphicConverter" for the Macintosh) are over-saturating the image when decoding a test file. I have studied the TIFF library source files, but with it being such a large and necessarily complex program, I have got lost, and am hoping those of you familiar with it might be able to help.

I am working with television standard REC-601 data that has the headroom and footroom as defined in the TIFF 6.0 specification, i.e., luminance from 16 to 235, and the colour-difference signals from 16 to 240, centred about 128. From these figures it can be seen that the luminance has a range of 219, whilst that of the colour-difference components is 224. The results I am seeing from the two applications mentioned suggests that the colour-difference signals are being decoded as if they too had a range of only 219, thus over-saturating the image by about 2% when decoding back to RGB.

Some comments in lines 1811 - 1820 of the file libtiff/tif_getimage.c read:

/*
* Initialize the YCbCr->RGB conversion tables.  The conversion
* is done according to the 6.0 spec:
*
*    R = Y + Cr*(2 - 2*LumaRed)
*    B = Y + Cb*(2 - 2*LumaBlue)
*    G =   Y
*        - LumaBlue*Cb*(2-2*LumaBlue)/LumaGreen
*        - LumaRed*Cr*(2-2*LumaRed)/LumaGreen
*

This is not quite correct, as the G result produced needs to be divided by LumaGreen. However, the program must actually do that, as the observed results don't show green being only 58.7% full amplitude!

Lines 1853 - 1862 of the same file read:

      /*
       * i is the actual input pixel value in the range 0..255
       * Cb and Cr values are in the range -128..127 (actually
       * they are in a range defined by the ReferenceBlackWhite
       * tag) so there is some range shifting to do here when
       * constructing tables indexed by the raw pixel data.
       *
       * XXX handle ReferenceBlackWhite correctly to calculate
       *     Cb/Cr values to use in constructing the tables.
       */

I was unable to find any range-shifting in this file, but a separate file, "tools/ycbcr.c", does appear to be doing the right thing by referencing the appropriate RefBlackWhite parameters.

Could I ask that you check the code regarding this problem please? I have left a couple of test images on my home web site at:

http://www.noctua.demon.co.uk/private/ycbcrtest.zip

Within the zip file are two TIFF files, "ColourBarsYCbCr.TIF" and "ColourBarsRGB.TIF", the latter being my decoding of the former by a totally separate program. The images are 720 x 576 (the size of a 625-line REC-601 television frame), and the YCbCr file has the TV standard sub-sampling such that chrominance has half the horizontal resolution of the luminance, but the same vertical resolution. The images comprise a horizontal luminance staircase with 25% steps; another with 20% steps; some TV standard 100% colour-bars (when decoded, the Red, Green, and Blue components are each either 0% or 100%); some "EBU" (European Broadcasting Union) standard 75% colour-bars (R, G, & B are 0% or 75%, except for white where they are all 100%); and some special 50% saturation bars I created, where R, G, & B are either 25% or 75%.

Thank you,

                Peter Vince  (Snr.Engr., BBC Television, London)

Email:   peter.vince@bbc.co.uk
Phone:   +44 20 8576 0000
Fax:     +44 20 8576 0018
Address: Room 3057, BBC Television Centre, London, W12 7RJ, England

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.