[Tig] Colour Correction, telecine or DI.

[glenn chan]

In reply to Bob's message:

Contrary to what you stated, a legitimate and legal R'G'B' source CAN
generate a Y'CbCr signal that results in values below black level.  This is
probably the most asinine artifact I am aware of.  For the quick visual
explanation, skip to #4 in this message.

Suppose you have a R'G'B' source with alternating red lines and black
lines.  When you convert to digital components, you get these alternating
sets of values:
Y'=0   B'-Y' = 0  R'-Y'= 0            This corresponds to the black
lines/background.
Y'=29.9  B'-Y' = -29.9  R'-Y'= 70.1  This corresponds to the red line.

With 4:2:2 sampling, you need to get rid of a bunch of the B'-Y' and R'-Y'
components.  Conceptually, it's like changing image size in Photoshop.  And
if you use Photoshop, you know there are 4+ ways of changing image size (i.e.
nearest neighbour, bicubic, etc.).  I will assume a simple scheme, where the
image is filtered with weighings of 1/4 1/2 1/4.  So now, the values are
such:
Y' = 0  B'-Y' = -14.95  R'-Y' = 35.05    (formerly the black line)
Y' = 29.9                    (formerly the red line)

Note that the first value has a Y' (luma) value of 0, but has
non-zero/non-neutral color difference components.  In most equipment, this
sample will be converted into something like the following R'G'B' values:
R' = 35.05  G' = -14.95 B' = -14.95
You actually have *negative* green and blue values.  These values are fairly
erroneous, since monitors can't produce negative light.  Some systems will
clip these values beforehand, since negative values cause programming
problems.  So in practical systems, the following values are displayed:
R'= 35.05  G' = 0  B' = 0

This sample was originally a black line, and should have R'G'B' values all
equal to 0.  However, because of the way the math works out, you get an
erroneous color.  In the displayed values, there is error in both luma and
chroma!
*I ignore the scale factors and offsets for Y'CbCr to make the math
simpler.  Rec. 601 co-efficients used, not 709 (  Luma (Y') = 0.299 R' +
0.587 G' + 0.114 B'  ).  Quantization error is ignored.
Improperly-calibrated displays ignored (they can display values below black
level).

2- The math doesn't have to work out like that.  If the chroma values are
reconstructed in a chromaticity-style color space, the red and black lines
can be re-constructed perfectly (assuming no quantization error).  However,
nobody does this as far as I know.

3- Situations like this almost never happens.  I can't think of any
real-world or computer-generated imagery (titles, animations) that would
really cause such a situation where this artifact/error is obvious.  It is
also nowhere as objectionable as other artifacts, such as Y'CbCr-->R'G'B'
convertors not applying chroma interpolation.  This is what the Apple
uncompressed codec does, and it does result in visible artifacts on
real-world imagery (i.e. titles, Red LED in an instrument panel).  Even
those artifacts don't seem objectionable, except in 4:1:1.

4- For a visual proof of this, see Marco Solario's codec site.
codecs.onerivermedia.com
Compare any of the 4:2:2 uncompressed codecs to the original test image.  On
the red lines on black background test (to the upper left corner), every
codec noticeably fails.  The red lines become these fuzzy greyish lines on a
reddish background.  The difference in the "uncompressed" codecs are mainly
in the chroma resampling.  Conceptually, it is how the "image size" of the
color difference components is rescaled that produces the differences.
Think Photoshop / changing Image Size.  The other differences (i.e. in white
count) are caused by quantization error.

Glenn Chan
Currently pursuing software development.
Toronto, Canada