Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: xpatUSA on April 24, 2014, 02:58:12 pm
-
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
-
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
-
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:
(http://kronometric.org/phot/post/LL/compGammaLin.jpg)
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.
-
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:
(http://www.kasson.com/ll/gamma.PNG)
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
-
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.
-
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,
-
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
-
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 . . . ;)
-
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 (http://www.openphotographyforums.com/forums/showthread.php?t=5499) 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
-
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 (http://www.openphotographyforums.com/forums/showthread.php?t=5499) 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,
-
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,
-
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
-
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
-
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,
-
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:
(http://kronometric.org/phot/post/LL/compGvsNGimageJhists.jpg)
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 ::)
-
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. :) :) :) :)
-
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,
-
...I am intensely interested in photographic theory.
Understood, and your comments (on all subjects) much appreciated.
-
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
-
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):
(http://www.kasson.com/ll/bitdepthpgm.PNG)
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:
(http://www.kasson.com/ll/16bitcameralinear.PNG)
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:
(http://www.kasson.com/ll/16bitcameraroundtrip.PNG)
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:
(http://www.kasson.com/ll/12bitcameralinear.PNG)
Taking it to 16 bit gamma 2.2 and back, we get:
(http://www.kasson.com/ll/12bitcameraroundtrip.PNG)
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 (https://www.google.com/patents/US4187466)
Thanks,
Jim
-
Jim, thanks for the time and effort that you put into the above simulation - quite illuminating!
Although my original post was of a general nature, I should have noted that the Sigma SD9 does an awful lot of preconditioning in-camera; including several matrix operations, a linearization look-up table and, I believe Huffman compression. The net result being 16bit values for image data in the X3F with possible saturated values well over 10,000. (On other fora, I have become wearily accustomed to being told that the three ADCs are 12bit so "how can numbers exceed 4095?"). Histograms show missing codes in the dark areas but somehow interpolation or something sets in at quite a low level. Sigma being a law unto themselves, we just have to take it as it comes :D
Did some comparison work on the flower, please see attachment.
cheers,
-
Although my original post was of a general nature, I should have noted that the Sigma SD9 does an awful lot of preconditioning in-camera; including several matrix operations, a linearization look-up table and, I believe Huffman compression. The net result being 16bit values for image data in the X3F with possible saturated values well over 10,000. (On other fora, I have become wearily accustomed to being told that the three ADCs are 12bit so "how can numbers exceed 4095?"). Histograms show missing codes in the dark areas but somehow interpolation or something sets in at quite a low level. Sigma being a law unto themselves, we just have to take it as it comes
Ted,
Yes, the old question of how much precision we need for intermediate values, and how does that relate to initial and final precision. There are no easy answers without knowing the precise calculations involved, which is why when I do image processing in Matlab, I nearly always use 64-bit floating point and take the easy way out.
But even assuming that all 16 bits coming our of the camera are meaningful, look at how much photon noise there is compared to the relatively minor histogram changes caused by the histogram depopulation due to gamma compression.
This may be old news to you, but about a year ago I did a series of posts on histogram depopulation:
http://blog.kasson.com/?p=1648
Thanks,
Jim
-
Ted,
Yes, the old question of how much precision we need for intermediate values, and how does that relate to initial and final precision. There are no easy answers without knowing the precise calculations involved, which is why when I do image processing in Matlab, I nearly always use 64-bit floating point and take the easy way out.
But even assuming that all 16 bits coming our of the camera are meaningful, look at how much photon noise there is compared to the relatively minor histogram changes caused by the histogram depopulation due to gamma compression.
This may be old news to you, but about a year ago I did a series of posts on histogram depopulation:
http://blog.kasson.com/?p=1648
Thanks for the link - this sentence stood out for me: "If we had a histogram tool with 65,536 “buckets” we’d see the gaps."
It is why I like RawDigger for it's excellent histograms - one per raw channel, log or lin X or Y - and the levels can be 'zoomed' in to show just a narrow part of the X-axis thereby getting down to 1-bit bins.
cheers,
-
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.
Hi Simon,
I've been warning people about the default behavior of Lightroom and ACR with Process version 2012, it significantly compresses highlight tonality. You need to reduce the Highlights slider a lot (upto -100 !) to undo that, to restore some sparkle and detail.
Cheers,
Bart
-
Thanks for the link - this sentence stood out for me: "If we had a histogram tool with 65,536 “buckets” we’d see the gaps."
Guillermo Luijk has written such a program, Histogrammar (http://www.guillermoluijk.com/tutorial/histogrammar/index_en.htm). It can zoom into a histogram with 65536 buckets. The latest version is Ver 1.2 (http://www.guillermoluijk.com/software/histogrammar/index.htm). Unfortunately, it has an expiration date and will not run unless you change the system clock to an earlier date.
Bill
-
Hi Simon,
I've been warning people about the default behavior of Lightroom and ACR with Process version 2012, it significantly compresses highlight tonality. You need to reduce the Highlights slider a lot (upto -100 !) to undo that, to restore some sparkle and detail.
Cheers,
Bart
Yes, I agree. Overall I find PV2012 is great improvement over PV2010, and one can (well, I can) extract detail in highlights more easily with highlights/whites sliders than by using curves. However, it does have a tendency by default to compress highlights. I assume this is part of a fairly agressive attempt to prevent highlight clipping.
One good thing about PV2012 is that you can swing the sliders between -100 and +100, more often than not without unpleasant artefacts or a "processed" look.
-
Some egg on my face, but a big step forward in understanding!
The last comparison shot that I posted of the yellow flower - both images had gamma :-[
It turns out that if you select linear gamma in DCraw v9.19 (-g 1 1) and sRGB (-o 1) the selection of sRGB overrides the gamma option selection. (Haven't tested if it does the same without a specific color space selection.)
As if that was not irritating enough, the shot itself happened to be taken in Sigma LO res, which on an SD9 gives effectively 18.24um pixels (true 2x2 binning on-chip). It comes as no surprise therefore that RawTherapee was able to bring up individual pixels when playing with local contrast, micro-contrast and sharpening. Thus what I naively thought was detail was actually (wait for it Jim) noise - lots of it - in spite of the slight reduction afforded by binning.
A hard lesson learned via public embarrassment which has caused me to rethink my camera and shooting needs :-\
Thanks to all,
-
There is a good reason to use linear, bright snow. In the past I have used linear to separate out detail in snow. In the last year I paid close attention to what you actually SEE when you are out in bright conditions. The snow does actually look shades of grey. People look at a winter scene then think it looks wrong if the snow is not white white. They need to actually go out in the stuff. The image where people say the snow looks dirty is actually what it looks like.
example
(https://farm9.staticflickr.com/8374/8412312649_4e69646dc2_o.jpg) (https://flic.kr/p/dPnitg)
-
There is a good reason to use linear, bright snow. In the past I have used linear to separate out detail in snow. In the last year I paid close attention to what you actually SEE when you are out in bright conditions. The snow does actually look shades of grey.
Hi Arthur,
And another benefit of linear is that more subtle differences in highlight rendering are preserved, ready to get enhanced with e.g. Topaz Clarity (see attachment, with only snow enhancement), which adds the play of light over the surface.
Cheers,
Bart