The easiest way to support Prolost is to begin your Amazon, iTunes, Mac App Store, Zacuto or B&H shopping here. You can drag those links to your bookmarks bar so you never forget. It costs you nothing and it really helps. Thanks!
There are many misconceptions about Cineon files and the color spaces known colloquially as log and linear. The first is that Cineon files are stored in a log color space. It’s not that this is entirely false, it’s just that it’s not that simple. The pixel values in a Cineon file are represent dye densities on color negative film, and the relationships of these density measurements from one step to the next on the 10-bit scale are the same.
So while we say all the time that the Marcie Cineon file is “log,” what we really mean is that it is in Kodak's Cineon 10-bit encoding of negative densities as seen by the print stock. OK, so maybe I was being over dramatic when I said you were wrong earlier. That’s cool—let’s keep using the term log to describe Cineons, since the densities themselves are in fact logarithmic.
The problem is really with the second image. Many people freely use the term linear to describe images that look correct on their ≈g2.2 monitors. It’s particularly easy to fall into this trap when you are invited by your software to perform a “Log to Linear” conversion on a Cineon file. The standard practice is to use a Cineon conversion gamma equivalent to your monitor gamma and describe the results as linearized. But in truth, the results are gamma-encoded, as any image must be to look correct on a ≈g2.2 display, and are therefor not linear in the least.
As you can see here, a log curve and the gamma 2.2 curve are actually very similar. Gamma 2.2 images (which likely comprise the vast majority of digital images) actually bear more in common with log images than with linear ones. Logarithmic encoding and gamma encoding are both methods of distributing values perceptually, allowing them to be stored at reduced bit depths and to look correct on non-linear displays.
So it would be better to say that we converted the “log” Marcie above to “another kind of log-ish space” than to say that we made her linear. The eLin/ProLost/brave new future term wold be not log, not lin, but vid (like we talked about here).
“But Marcie looks all washed out in the log image and not in the second one (that I still desperately want to call linear).”
OK, I knew you were going to say that. Check this out. Here’s the log Marcie with all the values below 95 and above 685 clipped. Other than that, no color space change:
She's still “log” — all we've done is perform the clipping that happens in a standard Cineon conversion. Looks pretty darn similar to the second image at the top of the article, right?
So log Marcie is more like vid Marcie than linear Marcie. Linear Marcie is too dark to look at, but is the best Marcie for doing image processing operations on. Raw Cineon files look washed out because they contain so much headroom, not because they're log.
So repeat after me: Log is kinda like vid, and vid is not linear!
The last article was heavy on theory and light on practice. Fusion users, here's a more concrete how-to.
Let's say you have a shot with a Cineon plate, a linear EXR image, and a video-space (sRGB) JPEG. You want to comp them all up real nice in Fusion in linear color space, because you are S. M. R. T.
OK, so lin is where you want these images to be, so you'll be looking to the *2lin Macros. We'll chose the straight gamma version of linear for our example.
The EXR is already linear, so it needs no help from us. Add it to your comp with a Loader and display it in a viewer.
It should look dark. Right click in the viewer and select Display LUT > Edit. Enter a Gamma of 2.2. Now the EXR should look correct.
What you have just done is implement a linear color workflow! Crazy.
Now add your JPEG. It has a gamma of 2.2 burned into it. It would look fine in that viewer if we hadn't set the gamma to 2,2. But we did. So let's add a Tools > Macros > eLin_vid2lin tool after the Loader to convert our vid image to linear space. The Macro will promote the image to float automatically in the process.
The only control in vid2lin is Gamma. This value refers to the inherent gamma of the input image. You'll very rarely need to change this from the default of 2.2.
Now the Cineon. Load that puppy into your comp. Fusion will, by default, try to Lin to Log the image for you right in the loader. Bypass this with the Bypass Log to Lin checkbox under the Format tab.
Displaying the log pixels under our 2.2 view LUT will make for a heinously bright image, so add a Tools > Macros > eLin_log2lin tool after the Loader.
There are two controls in eLin_log2lin — Conversion Gamma and Gamma. Both should match the view gamma, so again, you'll probably never mess with the default of 2.2. (The only reason these are two sliders instead of one is a silly omission of publishability in the Fusion Cineon Log tool. The two sliders should always have the same value.)
Now we have linear, log, and vid images all united in one linear color space, and a view LUT that makes them look correct.
Word. Comp away.
Now, when the time comes to output, you need to use the lin2* tools. Tools > Macros > eLin_lin2vid for video space output (such as TIFF, Targa, etc.), and Tools > Macros > eLin_lin2log for Cineon log.
eLin_lin2vid has one control, Gamma, and it really is as simple as a the gamma in a BC tool. Again, you'll very rarely set it to anything other than 2.2.
eLin_lin2log has the same dual sliders as log2lin. You'll never guess what they default to.
If you load a gamma 2.2 image, vid2lin it and then lin2vid it, it will roundtrip unharmed. Same with log and the log2lin/lin2log pair.
The “looks right” state of a Cineon log image (log2lin followed by a lin2vid or the 2.2 view LUT) is based on the standard Kodak conversion with a Dispamma of 1.7/2.2.
Try it. It's way less crazy than it sounds, it will make your work look better, and with the view LUT set to 2.2, you will always know that when things look right in your viewer, they are linear and happy.
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).
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.
DV Magazine's March issue features a overview of gamma-corrected compositing by the venerable Meyers. Thanks to Chris and Trish for the shout out to eLin, and for boiling down the evangelism portion of the eLin docs into a very readable two pages!
Trish and Chris Meyer are the authors of the undisputed bibles of After Effects: