[Tig] LOG [was Re: DI workflow, capabilities and requirements]

Chuck Harrison cfharr
Tue Mar 29 20:18:01 BST 2005

Steve Shaw wrote:
> The output format (not colourimetery) for the image data will
> vary depending on the job and the client's desires. But, the 
> image information will be LOG transfers with LUT based display,
> if necessary witht the LUT burnt in to the video image.

I hope everyone here is aware that the term "log format" is used 
in several incompatible ways in our industry. As we move towards
calibrated systems that can interchange HDR data in a truly
compatible way, it becomes more critical to understand this and
to use words carefully.

Two key concepts:
(1) "Image state" -- what do the numbers represent?
    (a) Scene-referred: the numbers represent light entering a
          real (or for CGI) virtual camera
    (b) Output-referred: the numbers represent light emitted/
          reflected from a viewing screen towards an observer
    (c) Intermediate: the numbers do not directly represent
          either the original input or final output, and may
          not even represent colors that are meaningful for
          a human to look at. However, the numbers are
          indirectly related to scene and/or output by some
          workflow processes.
(2) Numerical encoding
    (a) Linear-light: for scene- and output-referred encodings,
          this means "twice the photons, twice the numerical
          value". Common in CGI and color algorithm software
    (b) Log-light: for scene- and output-referred encodings,
          the numerical value is the logarithm (to some base)
          of a linear-light encoding.
    (c) Video gamma: for scene- and output-referred encodings,
          the numerical value is related to linear-light by
          a power-law or power-law-with-toe curve defined by
          broadcast video standards.

[Note: It is fairly common for TK people to use "linear" to refer
to what is more properly called a video gamma encoding. I've seen
this cause some unfortunate confusion.]

The more pertinent confusion to this discussion relates to
what "log transfer" means. We must note that, while
Cineon is defined using a log function, it is not the log of
any light that a human eyeball responds to meaningfully. That
is, Cineon is really log of negative transmission, which is an
intermediate-state format related to a device-dependent workflow
tied inextricably to chemical photo film. Cineon embeds that part
of the tonal rendering function which Kodak/Fuji have baked into
the toe and highlight behavior of negative stock for decades.
IMHO it is not a great basis for interchange in the long-term.

Viper uses a Log-light encoding (actually a bit modified) which
is in principle scene-referred, device-independent and calibrated.
While the numbers may be close to Cineon over most of the tonal
scale, the underlying definition and philosophy is entirely
different. Viper data represents scene light, *not* scene light
which has been purposely modified by exposure and development.
This may seem esoteric, but if the manufacturers and systems
providers do not understand and act on this core difference we
are headed for continuing problems with exchanging digital data
among systems.

In VFX work people have known for a decade or two that you
have to "un-bake" the film curve from a Cineon file in order
to get it to composite properly with CGI. One outcome of this
experience is the promulgation of OpenEXR, which is a scene-
referred, device-independent, linear-light color image
encoding. Because the numerical values are represented in
floating point, the dynamic-range issues commonly encountered
in integer linear-light representations are sidestepped.
OpenEXR has a lot to recommend it as an interchange and working
format for DI in the long term. However the fact that it requires
16 bits per primary is somewhat costly in storage terms.


More information about the Tig mailing list