Why linear

Let's see some differences between linear gamma space (gamma = 1) and "perceptually uniform" spaces, usually having gamma = 1.8..2.4

CCD/CMOS sensors have linear response to light. That is, they act not in the same way human senses do. For human eye, 100W bulb is not twice as bright as 50W bulb. But for sensor, it is the case - sensor output will be times two for 100W compared to the output sensor produces being litvwith 50W bulb.

Major reason to use linear gamma for editing is that we work directly with camera output, accessing real data coming from the sensor.

Linear response of sensor means that if we are taking photos of evenly lit surface varying exposure one step, resulting readings from the sensor will vary exactly two times for each step. So, in linear space it is very easy to correlate linear histogram to exposure compensation. In non-linear cases, when the signal is subjected to unknown or undisclosed transform, one can't do so.

Please review http://pochtar.com/gamut_view/gamma.htm

Effectively, linear response means that shadows are compressed compared to perceptually uniform response curve, while highlights are decompressed. That is why with linear data small manipulations in the shadow part of the image have such a strong effect, while results of manipulations in highlight portion are much less noticeable.

If one uses integer arithmetic, it is impossible to effectively manipulate those highly compressed shadows in gamma=1 space, where difference in 1eV is just 3 to 6 levels (R=G=B=3 is -4eV, while R=G=B=6 is -3eV) - because of rounding errors. Even in gamma=2.2 decompression full stop is only 13 levels in shadow zone. But with floating point this is not an issue.

For extracting details from shadows in perceptually uniform spaces with integer arithmetic our manipulations are limited, because once we go past "safe" slope of the curve, we encounter banding and posterization due to same problems of rounding in integer. But we need really extreme moves here quite often, as shadows are decompressed.

Highlights are also difficult in non-linear spaces because noise starts to show up.

Control over linear data is actually control of digital development. The goal of curve manipulations here is to extract maximum details and establish maximum dynamic range with regards to noise. That is, the goal is the same as with any development - extract maximum information by varying development process (we use dilution, temperature, time, agitation, chemical composition etc in endless combinations; obtaining results through trial and error - only to control that characteristic curve in wet lab; while in digital we have direct access to it!). (As an additional benefit, here it is possible to bring the image closer to visually pleasing look.)

After this is done, and our digital film is processed, we go to postprocessing.

 

Dear Chris,

Initial idea of having Shadow slider at "5" in resent ACR was to cut the noise off. Due to the above substantial amount of that noise is because of precision issues.

New ACR will have curve additionally to the sliders, that is expected (speculation on my part, of course   ) to improve shadow recovery.

Still, to treat shadows to maximum one needs different calculation methods then those used in ACR now, and probably then those used in 3.x versions.

32-bit HDR mode, however, can give substantial advantage in shadows over 15-bit - if HDR mode will be implemented in ACR.

 

Rich, you know how I like opening those cans of worms  

1:1, yes - but the scale is logarithms, and you work not in linear space in NC, it is the same usual gamma 2.2 space.

"eV" adjustments in NC and ACR are in linear space, however.

Histograms more then often are totally wrong, they are not displaying distribution of linear data, and not taking into account luminosities of chroma components. But different histograms are wrong in different ways - that is why you do not have match between NC and PS.

By wrong I do not mean that developers do not know how to make them correct - but there are two main reasons why they leave the things as they are.

First, inertia of users. Since the times histograms were introduced, our understanding of how to display "correct" histograms vastly improved. But users already got a hand over "wrong" histograms, so we have what we have.

Second reason - correct histograms take quite a time to calculate, that slows things down.
Histograms on the camera LCD are histograms of JPEG/PPM thumbnails, and they are not histograms of linear data of course.

Ron's technique is adapted to the NC methods, terminology, and inconsistencies. Gamma in NC is not true gamma, histogram is not the actual histogram, etc. But NC "gamma" is actually a handle that controls compression of shadows and decompression of highlights (or vice versa), in the same way middle slider in PS Levels do it.

I think Ron is using ad hoc terms speaking of gamma. He refers to the overall histogram distribution and the effect middle slider (often referred as 'gamma') adjustments will have on the image. Most important, not all the histogram is taken into account, but only that part of it where we want maximum level of details.

So, if you see shadows overly compressed while highlights and midtone are lacking good relief, or highlight details are not important, which is often the case with skies and backlit scenes - move it.

As we discussed earlier, eV adjustments are acting in linear. In some cases when shadows are compressed, eV adjustment counteracted with curve in highlights can help. But I would suggest the following sequence : eV for highlights, D-Light for shadows, then curves. I usually overdo D-Light just a little to have more room for curve adjustments.

 

Here is a quick comparison how histograms are displayed- same image opened in PS and NC

 

to add a little to the above - histogram window in PS is 256 pixels wide, but 100 pixels high (height of peaks though is not in percents).

NC histogram in Curves window is about 495x495 pixels maximum.

Scaling NC histogram windows to PS histogram windows may help to see where the resemblance to PS histograms is maintained closely. Channel histograms in PS and NC starting to look more or less similar that way, and "Master Lightness" histogram from LCH editor in NC closely follows Lightness and Composite histograms in PS. RGB histogram in NC resent versions stands aside.

On another note, having separate histogram window in NC is quite a treat - now I can see live what happens to channel histograms while I'm adjusting RGB or Master Lightness curves. That is not to mention that region selected on the histogram is now blinking negative on the image, and I can see what part of the image corresponds to each peak/plateau/depression on the histogram and decide are details and separation needed there or not.

Ah, and of course curve in Camera Control module is in true linear space.

 

Dear Paul,

Probably a little too brief on this one  

Smallest moves in shadows using in-camera curve have big effect, big moves in highlights have relativly small effect. What can I add? Examples how the same curve has different effect in linear and regular gamma spaces? Please help me here  

 

Dear Paul,

Yes, one of the reasons I mentioned that in-camera curve is linear was to strike the difference between that curve and regular curves.

What I can do is to take an image in linear space and in regular space and apply the same curve to show the difference - can that help?

 

On a) - Yes.

For all cameras, exept D1, curve has no inflence on RAW data. It is a tag, and is taken into account when rendering JPEGs/thumbnails. And in-camera histogram is based on those JPEGs/thumbnails.

On b) - yes, we can - if the NEF file is processed through Nikon Capture. No, we can't - if we use other RAW converters.

 

Here is an example showing how conversion from linear to "perceptually uniform" gamma = 2.2 space compresses highlights and decompresses shadows. Guess what happens to noise in shadows