Bluepixel posted this comment today (quoted here in its entirety):
Hi Stu!
Having used different colorspace workflows, and after reading your stories on the use of eLin on your blog, I was wondering if you could ellaborate a bit more on the topic “comping in real linear space makes tools behave in a more natural way, except for some tools”.
Let me explain my point. I do see the benefits within image processing tools that require “averaging” pixels, where the maths on a linear space behave more naturally than on a gamma=corrected space. But on my experience, color correction tools have a weird behaviour on linear images. Actually, I’ve found that only “mult” or brightness color corrections do behave more naturally on linear than they do on gamma-corrected space.
On the other hand, if you try to apply any correction involving changing the curve ono the blacks side, like a contrast, or even a gamma, the results are better when working on a gamma-corrected space. Same applies to pulling a key from a green/blue screen.
I have often found myself using different colorspaces depending on my needs, which is safe if you know what you’re doing at each stage, but I was wondering if that’s what you meant when you say that linear feels more organic to the use of compositing tools with some exceptions… are you referring to any of the issues I described above? It would be great to have some in-depth talk about that.
Thanks for your attention and for the great resource your blog is…
Cheers,
blue.
Blue, you said it perfectly. Your assessment of which color operations work well under which circumstances is exactly in sync with my opinions.
Simple RGB channel gain color correction works better in lin than in vid or log. So does image resizing, motion blur, focus blur, layering, adding, multiplying, simulating fog, simulating light, simulating a double exposure. Text rendering looks better in lin, as does rasterizing vector art. 3D lights and shading work better and more realistically in lin. All of these operations are cases of using simple math to simulate how light interacts in the real world. These are linear, physical events we’re simulating.
But some image processing falls outside of this category. Some image processing is perceptual, and wants to be performed in perceptually linear, AKA gamma-corrected space (vid). Examples include inverting an image, color corrections that want to have visually equivalent effects at any brightness level (such as crushing the blacks of an image). Some image sharpening wants to be perceptual (sharpening before printing maybe?) whereas some wants to be linear light (for example, canceling the effects of a slight defocus).
Some operations want to be in vid or log rather than lin because they are simulating events that have a native color space. Film has a logarithmic response to light, so adding grain, or simulating a cross-dissolve, or creating a fade to black all may want to be done in log, or at least vid.
When you perform a telecine-style color correction you are essentially creating a new “magic film stock” with uniquely non-linear responses to light. It makes perfect sense that you’d do this in a non-linear color space. Note that colorists use the same exact controls to color correct vid material as log, reinforcing the similarities between these color spaces.
So yes, I agree, there is no one color space that works perfectly for all situations. The key to effective image manipulation is to use the correct color space for the particular thing you’re doing, and that might mean bouncing back and forth between lin, log and vid within one project, regardless of where your source material came from or what format you’re outputting to.