[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Color Spaceing Problem in Flame/Fire/Inferno
> Known for some time now the color spacing problem in Discreet
> logic machines has been a difficult problem to solve.
> The flame takes in a digital 4:2:2 signal and spits out a
> signal chopped at 100 units. making all highlights turn a
> Different color or pure white. All we have been able to do is
> color correct in RGB to make the problem go away.
> Is there another solution ? When Will Discreet logic fix this
> Problem ?
This level problem is one of the significant differences
between the "computer" and "video" worlds. Video standards,
specifically CCIR-601, allowed for "headroom" above white
and below black (footroom?). This was done for very real and
valid reasons: highlighting, over/undershoot, and superblack
come to mind, but there are many others. As most of us
know, CCIR-601 puts black at level 16, and white at level
235 (using 8 bit notation). The computer world has always
put black at 0 and white at 255. Of course the level debate
will rage on forever, but several observances can be made:
1. "Computer" levels (0-255) have no "headroom", so the
problems that video standards were addressing (by
allowing headroom) are still there in the computer
world. (It's interesting to note that one of the reasons
for headroom, overshoot, is inherent in filtering
operations - which of course are the bread and butter of
2. When a computer interface, e.g. DL, limits and remaps
video from the 16-235 range to the 0-255 range, there
are several problems:
a. the non-linearity of the limiting operation
introduces distortion (hue shifts, mach bands, etc.)
How anyone calls this "correct" is difficult for
video people to understand.
b. the level re-mapping is really a gain operation
which introduces error (when the extra bits from
the multiply operation are tossed, of course you
get this twice, going in and out)
Even if the computer platform is operated in YUV space, there
is no such thing as a transparent path due to clipping
and round-off errors introduced by level re-mapping. (And you
thought digital was going to make generation loss go away).
If the computer platform operates in RGB space, as most do,
then there are even more errors introduced in color space
conversion. I've talked to several engineers who were less than
delighted to find that a simple D1 in/out transparency test, of
their new million dollar DL/Onyx, produced distorted video.
Solutions? Don't hold your breath waiting for the computer folks
to change their software, after all, they still claim that video
people have it wrong. One possible solution, although not
that great, is to reduce the level (gain of .92) of source
video before transferring into the computer - then bring it
back up later (of course this means that any graphics that's
added while in the computer domain be of a similarly reduced
level. Also, this only covers the upper limit - doing both
would mean a gain of .85 and a DC shift up of 6.2%).
Kind of klunky, but possibly better than using color
correction to fix limiting distortion.
thanks to Tarcis Verfaillie for support of the TIG in 1998
TIG subscriber count is 908 on Tue Dec 16 21:03:07 PST 1997
complete information on the TIG website http://www.alegria.com/tig3/