Is there a case for developing linear instead of gamma for some scenes?

[xpatUSA]

I'm thinking of scenes that have a bright part which is of interest while the middle and dark tones are less so. And further, that the bright part has low contrast - for which the eye compensates but the stupid sensor does not. In fact, this post was brought on by a yellow flower snapshot, taken in sunlight against grass and dirt.

Conventional literature carefully explains how the tones are crowded into the lower stops, etc, hence the application of gamma correction. However, if the scene were as described above, the gamma correction squeezes the tones in the area of interest making it flat looking - especially if that area has little color contrast. If that shot were converted in-camera to a jpeg, some tone levels would be lost forever.

On the other hand, if the raw image were converted to linear RGB by some means, the high tone would have more local contrast and fewer high tonal levels would lost in post.

Any thoughts?

Ted

[Jim Kasson]

Conventional literature carefully explains how the tones are crowded into the lower stops, etc, hence the application of gamma correction. However, if the scene were as described above, the gamma correction squeezes the tones in the area of interest making it flat looking - especially if that area has little color contrast. If that shot were converted in-camera to a jpeg, some tone levels would be lost forever.

On the other hand, if the raw image were converted to linear RGB by some means, the high tone would have more local contrast and fewer high tonal levels would lost in post.

Ted,

First off,  it's easy to demosaic to linear RGB, at least in DCRAW. Just use the -4 switch, and you'll get 16-bit linear RGB. Let's call that format A. If you take that file, and manipulate the values so that it has a gamma of, say, 2.2,  by scaling to the range [0,1], taking the values to the .45 power, scaling back into the range [0,16383], and writing it out, you'll get something we'll call format B. Let's say the primaries for format A were those of Adobe RGB. They will also be the primaries for format B. If you find or create ICC profiles for linear RGB with the Adobe  RGB primaries, and gamma 2.2 RGB with Adobe RGB primaries, bring both files into Photoshop, and apply the linear profile to format A and the gamma 2.2 profile to format B, the files are going to look the same on the screen.

When the files are tagged with the proper ICC profiles, gamma does not affect contrast, but does affect what tones are quantized to what accuracy.

I think I'm missing some subtlety in your question here.

Jim

[xpatUSA]

Ted,

I think I'm missing some subtlety in your question here.

With a conventional shot, gamma is applied which squeezed up the highlights and opens up the shadows. If I want more contrast in the highlights, I have then to 'unsqueeze' the highlights which brings a potential loss of levels especially if working in 8-bit. If I stay linear and moreover in 16-bit, no such loss can occur. That's the subtle bit which I may not have emphasized enough.

Yesterday, I gave it a try comparing the linear output from DCraw 9.19 with ACR 5.4/PSE6 and with Sigma Photo Pro 3.5.

ACR did badly, as is usual with out-of-gamut colors in yellow flowers so that try got discarded. Here is the result of SPP (gamma, no choice) versus DCraw linear opened up in RawTherapee:



I stretched the linear image in RawTherapee because it's the only app I have that does 16-bit calcs. Please ignore the hue differences, DCraw may have ignored the -w switch, it ignores quite a lot for Sigma X3F files  

The image above shows a bit more contrast in the linear but not enough to write home about. I will experiment further.

First off,  it's easy to demosaic to linear RGB, at least in DCRAW. Just use the -4 switch, and you'll get 16-bit linear RGB. Let's call that format A. If you take that file, and manipulate the values so that it has a gamma of, say, 2.2,  by scaling to the range [0,1], taking the values to the .45 power, scaling back into the range [0,16383], and writing it out, you'll get something we'll call format B. Let's say the primaries for format A were those of Adobe RGB. They will also be the primaries for format B. If you find or create ICC profiles for linear RGB with the Adobe  RGB primaries, and gamma 2.2 RGB with Adobe RGB primaries, bring both files into Photoshop, and apply the linear profile to format A and the gamma 2.2 profile to format B, the files are going to look the same on the screen.

When the files are tagged with the proper ICC profiles, gamma does not affect contrast, but does affect what tones are quantized to what accuracy.

I'll take your word for all that and [edit] I do see what you're driving at.

[Jim Kasson]

With a conventional shot, gamma is applied which squeezed up the highlights and opens up the shadows. If I want more contrast in the highlights, I have then to 'unsqueeze' the highlights which brings a potential loss of levels especially if working in 8-bit. If I stay linear and moreover in 16-bit, no such loss can occur. That's the subtle bit which I may not have emphasized enough.

Yesterday, I gave it a try comparing the linear output from DCraw 9.19 with ACR 5.4/PSE6 and with Sigma Photo Pro 3.5.

ACR did badly, as is usual with out-of-gamut colors in yellow flowers so that try got discarded. Here is the result of SPP (gamma, no choice) versus DCraw linear opened up in RawTherapee:

It looks like what you're doing is feeding a linear file to your editor, then lying to it and telling it that it's gamma 2.2. Quantizing accuracy aside, this is the same as converting the raw image with a gamma of 2.2, and using the 'Levels" control in Photoshop to change the gamma of the file by .45, like so:



In the above illustration, the input image is a series of equal steps in linear representation. I think your point is that if you do it your way, you'll have fewer operations that result in histogram depopulation. While this would be important, as you point out, with 8-bit color planes, I think it's unlikely to be important with 16-bit depth.

However, aside from the extra effort require to do it your way, I see nothing wrong with doing that, if the image you get is the image you want.

So, did I finally understand what you're doing?

Jim

[Simon Garrett]

I appreciate the problem: dificulty in keeping contrast in bright highlights.  I can think of recent examples I've had in yellow flower petals and in cloud details. 

Lightroom, which I use mostly, converts to 16-bit linear gamma anyway, so the problem of a greater-than-unity gamma is deferred to a later stage - normally after any tone adjustment.  I reckon it's a good idea to be able to do tone/curves adjustment in 16 bit and preferably linear gamma, before the raw data has gamma applied or is converted to 8-bit, for the reasons you say. 

[xpatUSA]

It looks like what you're doing is feeding a linear file to your editor, then lying to it and telling it that it's gamma 2.2. Quantizing accuracy aside, this is the same as converting the raw image with a gamma of 2.2, and using the 'Levels" control in Photoshop to change the gamma of the file by .45. However, aside from the extra effort require to do it your way, I see nothing wrong with doing that, if the image you get is the image you want.

So, did I finally understand what you're doing?

I believe so, Jim, and thanks for the enlightenment. I'll give it a try by saving that flower as a jpeg from SPP and then applying 0.45 in Levels.

Thanks again,

[Jim Kasson]

I believe so, Jim, and thanks for the enlightenment. I'll give it a try by saving that flower as a jpeg from SPP and then applying 0.45 in Levels.

Ted, don't save it as a JPEG, 'cause that's only got 8 bits per color plane, at least in standard form. If that's you're only choice, then the scheme you came up with is an imporvement. I was assuming you could get your raw developer of choice to output files with 16-bit deep color planes, like Lr or Iridient Developer.

Jim

[xpatUSA]

Ted, don't save it as a JPEG, 'cause that's only got 8 bits per color plane, at least in standard form.

No real need to tell me that, Jim, it was just for testing.

If that's you're only choice, then the scheme you came up with is an improvement. I was assuming you could get your raw developer of choice to output files with 16-bit deep color planes, like Lr or Iridient Developer.

My normal raw developer for X3F files is Sigma Photo Pro. For 'important' images, I normally work in ProPhoto color space and SPP internally uses Kodak RIMM for the working file. I export ProPhoto 16-bit TIFF to RawTherapee. staying in ProPhoto. Then save as sRGB using RawTherapee's perceptual rendering intent to clobber those pesky OOG colors.

For snaps, I save 8-bit TIFF and use quick-and-dirty Elements 6 which is more intuitive and a lot less cranky than RawTherapee.

I'm not a great fan of Adobe, so no LR or Cloudy PS. No modern Mac, so no Iridient either.

First a beer, then the test . . . 

[bjanes]

With a conventional shot, gamma is applied which squeezed up the highlights and opens up the shadows. If I want more contrast in the highlights, I have then to 'unsqueeze' the highlights which brings a potential loss of levels especially if working in 8-bit. If I stay linear and moreover in 16-bit, no such loss can occur. That's the subtle bit which I may not have emphasized enough.

Quantization in steps finer than noise doesn't make sense, as the noise will dither the image and the finer steps can not be resolved. See this post by Emil Martinec for an explanation of how Nikon lossy compression of their raw files is visually lossless--wasted highlight levels are discarded with no perceptible loss of image quality.

A high performance dSLR sensor might have a full well of 80,000 electrons and shot noise at this level would be sqrt(80,000) or 283 electrons. With 14 bit quantization, each 14 bit level represents approximately 5 electrons. Thus, quantization is much finer than the noise. PRNU (pixel response non uniformity) might add 0.5 to 1% of additional noise, or 400 to 800 electrons. I doubt that your linear encoding will improve highlights, and your shadows may suffer.

Regards,

Bill

[xpatUSA]

Quantization in steps finer than noise doesn't make sense, as the noise will dither the image and the finer steps can not be resolved. See this post by Emil Martinec for an explanation of how Nikon lossy compression of their raw files is visually lossless--wasted highlight levels are discarded with no perceptible loss of image quality.

Yes, I remember reading something similar when I owned a D50. 683 levels out, IIRC.

A high performance dSLR sensor might have a full well of 80,000 electrons and shot noise at this level would be sqrt(80,000) or 283 electrons. With 14 bit quantization, each 14 bit level represents approximately 5 electrons. Thus, quantization is much finer than the noise. PRNU (pixel response non uniformity) might add 0.5 to 1% of additional noise, or 400 to 800 electrons. I doubt that your linear encoding will improve highlights, and your shadows may suffer.

The shot was made with a Sigma SD9. Full well is 77,000e- which, however, is getting quite non-linear; I try to keep the max exposure closer to 45,000e- which allows a bit of raw headroom. A quick look at my example image in RawDigger prompts me to guess a max of 51,000-e for that shot. The camera has 3 ADCs (12-bit), one per channel. So, following your example above, shot noise was 226-e, and there would be 12e- per ADC count. Read noise is quoted at approx 40e- and PRNU at 1%. Does this information confirm your doubt? I ask because I've yet to fully understand the concept of dithering as it relates to the DSLR pipeline   

cheers,

[xpatUSA]

I believe so, Jim, and thanks for the enlightenment.

I'll give it a try by saving that flower as a jpeg from SPP and then applying 0.45 in Levels.

I did do that test and applying 0.45 gamma in levels produced missing codes in the histogram all the way down past gray level (118/255).

So the possibility of missing codes or levels appears to be real (at least for JPEGs SOOC) for what that's worth.

later,

[Bart_van_der_Wolf]

I did do that test and applying 0.45 gamma in levels produced missing codes in the histogram all the way down past gray level (118/255).

So the possibility of missing codes or levels appears to be real (at least for JPEGs SOOC) for what that's worth.

Hi Ted,

I think it is one of the reasons why Exposure Fusion works as well as it does, compared to straight forward HDR tonemapping. While regular HDR tonemapping has files with much better S/N ratio throughout the response curve to resist gaps in the histogram upon contrast manipulation and Gamma pre-compensation, Exposure Fusion has well populated Gamma pre-compensated histograms to work with.

Cheers,
Bart

[hjulenissen]

I might be missing the point here. But gamma is applied at encoding (from linear light) and the inverse gamma is applied at decoding (to linear light). I see it as a kind of "mu-law/a-law" signal representation that re-distribute quantization noise (usually 8 bits) and lossy coding errors in a perceptually sensible way.

Thus, when you have a linear image capture device (such as a digital camera raw file), you are expected to apply gamma when producing common distribution file formats (such as JPEG) such that when this image is transmitted to the display (in some gamma-encoded format), the display will apply an (approximate) inverse transform before modulating its physical light emission.

So far, it is all about reproducing scenes "objectively" (within the current understanding of human visual system as well as economic/practical limits). If you want to get creative, all kinds of tonal-altering tools are available in image editors. I believe that some "objective" reproduction systems calls for non-linear end-to-end light reproduction motivated by gross differences in absolute brightness levels and/or limitations in reproduction DR, but I don't know enough about that.

-h

[xpatUSA]

I think it is one of the reasons why Exposure Fusion works as well as it does, compared to straight-forward HDR tone-mapping. While regular HDR tone-mapping has files with much better S/N ratio throughout the response curve to resist gaps in the histogram upon contrast manipulation and Gamma pre-compensation, Exposure Fusion has well populated Gamma pre-compensated histograms to work with.

Hello Bart,

I had to Google 'Exposure Fusion' 

Yes, the technique does look useful for improving a total image DR. Yesterday I continued experimenting and found that the difference between linear and gamma processing (16-bit) of my specific flower snapshot is noticeable but not large. By 'difference' I mean mainly contrast and detail. I may be beginning to understand shot noise as explained above by Bill a little better. The flower petals certainly appeared smoothed and some deconvolution settings in RT made quite a difference, I thought. Perhaps no surprise, I think they use a Gaussian form.

In spite of my technical interest, I'm still a snap-shooter with simple tools BTW. One day, perhaps . . .

cheers,

[xpatUSA]

Trying to get closer to comparing apples to apples, I exported two raw composites from RawDigger, one with 2.2 gamma, the other linear. I selected auto-stretching (fits into 16384 levels). Here it be:



I opened the 16-bit TIFF images in ImageJ and calculated the contrast from the max & min histogram values for part of a petal. I used the formula (max-min)/(max+min)*100. The linear image gave 17.85%, the gamma'd image gave 7.76% and this is the nub of what I was trying to say in the OP. Kindly remember my total disinterest in the background of grass and dirt.

I'm not suggesting that RawDigger becomes part of the workflow for that image, of course. I just used it to clarify my original post.

So, for me, it's back to DCraw for this image and see if I can improve the WB  

[Simon Garrett]

So, for me, it's back to DCraw for this image and see if I can improve the WB  

Or do what I suggested earlier: use Lightroom, or any other raw convertor that allows you to do all the tone mapping in 16-bit linear, before any gamma correction is applied.    

[xpatUSA]

Or do what I suggested earlier: use Lightroom, or any other raw convertor that allows you to do all the tone mapping in 16-bit linear, before any gamma correction is applied.    

Good advice, of course. But I don't have Lightroom neither do I have PhotoShop CS and no intention of buying them. As I said to Bart earlier I'm not a real photographer but I am intensely interested in photographic theory.

Raw converters that allow me 'to do all the tone mapping in 16-bit linear, before any gamma correction is applied' are rare to non-existent for Sigma X3F files. Possibly Irridient but that's Mac only.

Thanks anyway,

[Simon Garrett]

...I am intensely interested in photographic theory.

Understood, and your comments (on all subjects) much appreciated. 

[kirkt]

You may want to stick to linear image data if you are interested in combining lighting (or manipulating light data) in a physical way prior to tone mapping the image.  This way you are not doing artistic "exposure blending" but physical combination of light.  It is best to do this in full 32 bit land, as I am sure you are probably aware.

kirk

[Jim Kasson]

Ted, I did a little quick simulation to help with the dither issue. I assumed a mean exposure of 51000 electrons with a fullscale of 77000 electrons on every pixel of a 1000x1000 monochromatic image, and assumed that all noise was photon noise.

Here's the Matlab code. All the images except the electron image are normalized to one. The histogram function plots the histogram between plus and minus two standard deviations of the mean at whatever resolution is specified )it un-normalizes prior to that operation):



When you run it with the camera bit depth set to 16 and look at the 16 bit linear histogram, here's what you see:



And here's the histogram of a round trip from 16 bit linear to 16 bit gamma 2.2, and back, quantizing at each step:



You can see that the histogram is more ragged, and that there is some depopulation, but you can also see that the photon noise dominates. The two peaks on either end are the result of big buckets there; please ignore them.

Now, what if we assume a 12-bit camera bit depth, and convert the image to 16-bit linear:



Taking it to 16 bit gamma 2.2 and back, we get:



You can see that the histogram isn't changed much, because the slope of the gamma compression curve never gets low enough that two of the twelve-bit buckets are conbined.

I've got statistics versus bit depth if you're interested, but I think this hits the high spots.

OBTW, I've a fan of dithering from way back:

https://www.google.com/patents/US4187466

Thanks,

Jim