Much of my writing on the benefits of working linear is tied to the eLin documentation. It occurred to me that it might be helpful to describe these advantages in more general terms, and to provide equivalences of the eLin color pipeline for two popular floating point compositing apps.
First, let's get some terms straight. A lot of people use the term linear to describe images that look correct on their displays without any color correction. In visual effects circles we sometimes hear about converting Cineon images from log space to “linear” so they “look right.”
When I use the term linear, I am talking about something else. I am talking about a linear measure of light values. I freely intermingle terms like photometrically linear, radiometrically linear, scene-referred values, gamma 1.0, and just plain old linear when describing the color space in which pixel values equate to light intensities.
If you were to display such an image on a standard computer monitor without any correction, it would look very dark. The best way to visualize this is to think about the “middle gray” card you bought when you took your first photography class. It appears to be a value midway between black and white, both to our eyes and in our correctly-exposed shots, and yet it is described as being 18% gray.
We’d want images of this card to appear at or near 50% on our display. But in scene-referred values, an object that is 18% reflective should have pixel values of 18%, or 0.180 on a scale of 0–1.
Virtual Graycard Comparotron2000™:
- Linear image with no LUT (card = 0.18, or 18%)
- Image with a 2.2 LUT applied (card = 0.46, or 46%)
If your digital camera didn't introduce a gamma 2.2 (or thereabouts) characteristic into the JPEGs it shoots, they'd look like the linear example above. The images where the card “looks right” are variously described as perceptually encoded, gamma encoded, or they may even be identified as gamma 2.2 encoded, or having a gamma 2.2 characteristic curve. A specific variant of gamma 2.2 goes by the name sRGB. In an attempt to create a catchy (and catch-all) term, the eLin documentation refers to these color space collectively as vid, since NTSC video has a gamma of 2.2 (kindasorta), and since these images “look right” on a video monitor.
Many of the image processing tools we use behave differently when performed at different gammas. If you gamma an image dark, blur it, and gamma it back up (inverse of gamma = 1/gamma), you get a different result than if you simply blur the image.
When you convert an image to linear space, your subsequent image processing operations better match real-world physical properties of light. If you are accustomed to processing perceptually encoded images, you will probably find that switching to g1.0 processing will make your familiar effects look more organic (with a few notable exceptions to be covered in a later article).
All this talk can be boiled down to a simple description:
Processing and blending in linear simulates light values interacting. To make a gamma 2.2 image linear, apply a gamma of 1/2.2 (0.4545). View linear images through a gamma 2.2 display correction (LUT). Convert images back to 2.2 (vid) for integer storage and display, or leave them linear for float storage (such as EXR).
Earlier we talked about Cineon scans. Converting a Cineon image from its native “log” space to true linear is very simple — just use a transfer gamma of 1.0. In Fusion, this means setting the Conversion Gamma slider to 1.0 (the default). In Shake, this means a DGamma of 1.7 (the slider's value is internally multiplied by 1/1.7, so 1.7 = 1.0. The ProLost definition of “high end” is “needlessly confusing.”).
There's a slight hiccup here, because the results of linearizing a Cineon to g1.0 and then viewing the results through a g2.2 correction are not the same as the results of using a Cineon transfer gamma of 2.2. This means that if you want to round-trip vid and Cineon elements in your comp, you have to choose your definition of “linear” — Cineon’s or video’s.
Welcome to the ConfusoDome™.
In eLin we differentiate between these two working modes with checkboxes for Cineon Emulation.
In the Fusion and Shake workflows, I've differentiated between these two methods with separate sets of Macros.
The straight gamma definition of linear:
- eLin_vid2lin
- eLin_log2lin
- eLin_lin2vid
- eLin_lin2log
And the Cineon flavor:
- eLin_cin_vid2lin
- eLin_cin_log2lin
- eLin_cin_lin2vid
- eLin_cin_lin2log
- eLin_cin_lin2vid.lut
Either one of these systems will round-trip Cineon and vid images safely. It’s just a question of which definition of linear you like better. The straight gamma version is more aggressive, yielding brighter highlights from a Cineon file and with a more precipitous slope near black. The straight gamma version also provides easier back-and-forth with certain 3D apps that support gamma correction but not LUTs (see an example).
Download the Fusion Macros (8kB .rar file)
Download the Shake Macros (32kB .zip file)
Armed with these Macros, you can follow the simple workflow outlined above. Convert vid and log sources to linear, comp away, and convert the results to vid or log for output. In the straight gamma method, you simply use a display correction of gamma 2.2 — easily done in both apps. In the Cineon method you will need to use the supplied LUT file, or create a Shake viewscript from the cin_lin2vid Macro.
This is exactly the color model of eLin, except that eLin packs this whole enchilada into the 15+1bpc color space of After Effects 6.5.
Any questions?
And now the caveats: I don't claim to be an expert at any of this. Use at your own risk. Offer void in Utah. No smoking in the bathroom. The Shake workflow really requires a view script for the cin_lin2vid LUT — the .lut file I've included is in Fusion format. But I don't know how to use Shake. Nor do I know how to use Fusion. I hope some brave soul will post a comment about how he/she made the Shake workflow actually work. Federal law prohibits removal of this tag except by the consumer.