Re: [Openexr-devel] On YUV support

[Florian Kainz]

A couple of weeks ago, two statements were made in this thread:

1) The "Technical Details" page on the OpenEXR web suggests reserving
   the channel names Y, U, and V for "YUV images", that is, images with
   one luma and two chroma channels.  The channel names, and the term
   "YUV image" are misleading and should be changed.

2) The the luma and chroma channels in existing component video systems
   were defined assuming that R, G and B fit into a normalized zero-to-one
   range, and that RGB data are non-linear.  Outside the zero-to-one range,
   the luma/chroma definitions are not necessarily valid.
   Therefore luma/chroma encoding of high-dynamic-range images might not
   be possible or not desirable.

I agree with statement 1, except regarding the channel name "Y".

I disagree with sith statement number 2.  High-dynamic-range luma/chroma
encoding is possible.  RGB image files can be converted to significantly
luma/chroma files, in most cases with very little visual degradation of
the image.

---------

Digital video and image file formats employ various methods to encode 
images with one luma channel and two chroma channels.  The luma channel
represents the subjective quantity "brightness", and the chroma channels
together represent "color".  Different encoding methods differ in the
details of how the luma and chroma channels are derived from RGB data,
and also in how the channels are named (YIQ, YUV, Y'CbCr, etc.).

No matter which method is used, the goal of representing an image with
luma an chroma channels is data compression.  It is possible to reduce
the spatial resolution of the chroma channels without altering the
subjective appearance of the image too much.

In CIE terms, the subjective quantity "brightness" is represented by the
objective quantity "luminance", abbreviated Y.  All luma/chroma encoding
systems derive a luma channel that appxroximates Y by combining R, G,
and B, usually like this:

    Y' = fr*R' + fg*G' + fb*B'

Here, R', G', and B' are gamma-corrected red, green and blue values
(R' = pow (R, gamma), G' = pow (G, gamma), B' = pow (B, gamma)), and
fr, fg, and fb scaling factors that depend on CIE x,y chromaticities
of the primaries and the white point.

The two chroma channels are usually computed by subracting Y' from R'
and B', and then scaling and offsetting the resulting color differences:

    chroma1 = (R' - Y') * s1 + o1
    chroma2 = (B' - Y') * s2 + o2

The scaling factors and offsets, and the names used for the two chroma
channels differ from one luma/chroma encoding system to another.  

Computing Y' and the two chroma channels in this way makes sense for
low-dynamic-range luma/chroma encoding systems, because the method is
easy to implement.  R', G', and B' are readily available, and the luma
and chroma values can be derived with just a few multiplications and
additions.  In addition, the resulting luma and chroma values can be
represented with the same number of bits as R', G', and B', commonly
8 or 10, without introducing significant quantization quantization
artefacts.

Charles Poynton insists that the luma and chroma channels should not
be called Y, U and V, because the names U and V imply a particular set
of scaling factors, and Y' is not the same as Y (without the chroma
channels, Y cannot be computed from Y').  Terms like "YUV video" are
also misleading, and therefore inappropriate.

Poynton is, of course right.  We should use precise terminology.
The OpenEXR documentation should avoid talking about "YUV images",
and about U and V channels.

However, this doesn't mean that luma/chroma encoding of HDR images
is not possible.  Here's a method that works reasonably well: 

In OpenEXR, R, G, and B are stored as linear floating-point values, and
we can use true CIE luminance (Y, not Y') for the "brightness" channel:

    Y = R * M[0][1] + G * M[1][1] + B * M[2][1]

Here, M is the RGB-to-XYZ matrix derived from the file's chromaticities
attribute (see ImfChromaticities.h).

For the chroma channels, which I will call "RY" and "BY", we can use the
following:

    RY = (R - Y) / Y
    BY = (B - Y) / Y

The divisions by Y in the expressions above are necessary to limit the
magnitude of RY and BY.  Without those divisions, RY and BY can become
very large.  Our goal is data compression, and we intend to low-pass filter
and sub-sample the chroma channels.  If a pixel's RY or BY value is very
large, the filtering step effectively erases the surrounding pixels' RY
and BY values.  This causes objectionable artefacts near high-contrast
edges.  Division by Y eliminates most of those defects.

The tar file attached to this mail contains two programs.  One converts
OpenEXR images from RGB to luminance/chroma format, with RY and BY
subsampled horizontally and vertically (only one in four pixels has RY
and BY samples).  The other program converts luminance/chroma images
back to RGB.

As demonstrated by the two conversion programs, it is possible to store
luma/chroma images in OpenEXR files.  For convenience, the RgbaInputFile
and RgbaOutputFile classes should probably support automatic conversion
between RGB and luma/chroma.  If there is enough interest, I will add
this feature in a future release.

Florian

OpenEXR_lcr_test.tar.gz
Description: GNU Zip compressed data