D800, histogram and overexposure

[Taxista]

I love my D800, but there´s something bothering me:

- when I shoot airplanes, the photos tend to be overexposed (by .5/.7 stops);
- the histogram on the back of the camera seems normal, but the one in ACR is different: the overexposure is there.

 

[the Pond]

Change your metering mode from Matrix to Spot or Center Weighted and try again.

 

[uscmatt99]

The histogram on the camera is for the in-camera generated jpeg, while the one in ACR would correspond to the RAW (if you shoot RAW). But it's odd, as normally the jpeg histogram is more compressed.

As for the overexposure, why not just dial in some negative exposure compensation if it's consistent?

 

[480sparky]

The histogram on the camera is for the in-camera generated jpeg, while the one in ACR would correspond to the RAW (if you shoot RAW). But it's odd, as normally the jpeg histogram is more compressed.

As for the overexposure, why not just dial in some negative exposure compensation if it's consistent?

I think more to the point is the in-cam histo is based on the embedded JPEG thumbnail.... which is generated anyway whether you shoot raw or JPEG.

 

[Cleanimage]

Taxista - I'm surprised that your picturea of planes would be overexposed. I would expect the overall brightness from the sky to underexpose the plane.

 

[Taxista]

As for the overexposure, why not just dial in some negative exposure compensation if it's consistent?

I must use -0,7 under bright sun, -0,3 in the evening and no compensation as the sun sets down.

Change your metering mode from Matrix to Spot or Center Weighted and try again.

Center weighted works better than matrix for me; I use it most of the time.

I went back to my spotting places today and tried different settings. When the plane is white, the resulting image is not good enough. An American Airlines plane (new livery) landed; the camera exposed and focused correctly.

I´m starting to think that my camera is not ok.

 

[TonyW]

What are your default settings for ACR, Exposure, Contrast etc etc? Can you post a screen shot of the camera raw settings

 

[WayneF]

- when I shoot airplanes, the photos tend to be overexposed (by .5/.7 stops);
- the histogram on the back of the camera seems normal, but the one in ACR is different: the overexposure is there.

Maybe not the problem, but odds are good... Don't check "the histogram". Instead check the three RGB separate channel histograms (keep pressing the up button to get to them). In this case, the blue channel is surely higher than the others, and it may be the problem. That screen shows the single histogram too, see?

But the point is, the "single histogram" is not your actual picture data, but is instead merely a math simulation of "lumnosity", i.e., the brightness that B&W film would show the colors (each color is more dim, but they may add bright). The Single histogram is NOT the real data, so always only look at the three RGB channels, which is the real data
See http://www.scantips.com/lights/histograms.html
(EDIT: corrected link - it's pretty good info if you don't already know)

Taxista - I'm surprised that your picture of planes would be overexposed. I would expect the overall brightness from the sky to underexpose the plane.

Me too. Sky peak is maybe 5/8 scale on my D800.

Center weighted works better than matrix for me; I use it most of the time.

Me too. I see very little difference, but I can understand Center, and Matrix is not documented. :smile:

 

[Taxista]

Shot today, 10 AM, Nikon D800 + Sigma 70-200 OS HSM, 1/1.600, f6,3, ISO 160:

Subscribe to see EXIF info for this image (if available)

It doesn´t look overexposed, but the quality is terrible.

 

[TonyW]

The image as posted does not give any real clues about the reported histogram issues jpeg to raw in ACR.

I assume this was shot as raw and processed in PS Camera raw prior to saving the images as sRGB or using Save for Web in PS?

Did you attempt any post processing and if so what did you alter?

In the camera calibration tab of ACR what process settings did you use e.g. 2012, 2010 or 2003?

What Camera profile did you select ACR 4.6, Adobe Standard or one of the camera specifics e.g. Landscape, Neutral, Portrait, Vivid?

If not already have you tried any of these settings to see what improvements may be had?

TBH I would not say that the quality is terrible, rather for this image some pp in ACR would help lift it. For instance perhaps a touch more contrast to deepen the shadows and with the addition of HSL to darken and saturate the blues and lighten the greens and yellows would add a little punch to the image.

Assuming your lens and filter if used are clean then any shortfalls in the image (contrast/density etc) are likely to be due to position of the sun and any peculiar atmospherics at the time of the shot.

 

[Taxista]

Thank you for your analysis. The image I posted is a 14 bit Raw, downsampled and saved as a JPEG. It was not processed.

The image is not overexposed and, for this reason, is not a good example to ilustrate the reason why I created this topic. It is an ugly image, and this surprises me. Maybe the problem is the light and it´s angle of incidence on the plane.

In the camera calibration tab of ACR I use 2012, and Neutral as Camera Profile.
The version of ACR is 7.1.

As I said, the image is ugly, but the morning was a nice one. I don´t understand this.

 

[TonyW]

I think you are correct about the light not flattering the subject plus the potential for atmospherics at the airport not helping?

Trying to understand exactly why you see the image as ugly the only conclusion I can come to is one of colour saturation - this may of course be wrong. Hope you do not mind posting a quick change to your image (if you do I will remove) with the question does the bottom image look any better to your eyes and represent any closer to what you wanted/expected?

Subscribe to see EXIF info for this image (if available)

 

[Taxista]

Hope you do not mind posting a quick change to your image (if you do I will remove) with the question does the bottom image look any better to your eyes and represent any closer to what you wanted/expected?

TY again. The photo looks better, but the blue on the vertical stabilizer should be bluer.

Sometimes passions are frustating. We go from D80, to D90, to D300, to D800 and think "the camera is superb, the resolution is there, the high ISO performance is extraordinary; shouldn´t some photos look better?".

Is there too much resolution? Are some cameras too complex nowadays?

 

[TonyW]

Bluer, Bluer sheesh some are hard to please :biggrin:. I guess you are an aircraft officianado and you need to get it correct. Quick change to illustrate anything is possible (and probably still not exact but...) and a note if the vertical stabiliser is the thing I would refer to as the tail the blue does not match the body stripe, should it? These corrections are very simple and at times can be expected in ACR - in this case I just used HSL and adjusted as posted earlier

Subscribe to see EXIF info for this image (if available)

Seriously you have a very fine camera quite capable of capturing superb images but the fact remains that however good the camera and your capture is there is almost always something that can be improved in post to match your visualisations and intent.

 

[TonyW]

I love my D800, but there´s something bothering me:
- when I shoot airplanes, the photos tend to be overexposed (by .5/.7 stops);
- the histogram on the back of the camera seems normal, but the one in ACR is different: the overexposure is there.

Sorry but the thread got a little diverted (my fault!) from the original issues. Trying to pull it back on subject to see if any light can be shed on what you are observing.

Concentrating on the difference you are seeing on the histogram between the jpeg rendering on the LCD and ACR, what you are observing does not at the moment make sense. In as much as an ideally exposed jpeg (according to the in camera histogram) should yield at least in theory an underexposed raw.

Just a few thoughts - these are generalisations not camera specific:

The histogram that you see on the LCD screen has only a passing relationship to the raw data as one is gamma encoded and the other is linear. Plus the rendered image (and histogram) will appear very different in various raw converters due to the makers intent of either a general starting point or trying to match the manufacturers rendering.

If your goal is a properly exposed Jpeg the camera LCD and the displayed histogram tells you all you need to know and should show a pretty histogram :smile:. Also it could be argued that if you expose for an ideal jpeg you are actually underexposing for raw!

If you expose correctly for raw it is highly likely that you will see blown highlights on the camera LCD including the histogram. Remember that the rgb is gamma encoded and the raw is linear.

Should be easy to prove by setting the camera to take raw+jpeg image for comparison.

While it seems at odds with your original post where ACR indicated over exposed! This may be partially explained by your choice of working space within camera raw where the histograms will appear quite different.

Below examples showing differing working spaces and the resulting histogram. In most cases the actual on screen rendering changed very little with the exception of the sRGB which is clipped and is mainly an OOG issue

Subscribe to see EXIF info for this image (if available)

Hope this serves to help in eliminating potential trouble spots rather than muddying the waters

 

[Cleanimage]

I agree with Tony; I don't think that the image quality is terrible. With some minor adjustments in ACR I think that it would look pretty good.

 

[WayneF]

If you expose correctly for raw it is highly likely that you will see blown highlights on the camera LCD including the histogram. Remember that the rgb is gamma encoded and the raw is linear.

Tony, I agree with all of your post except not this, not about gamma.

Any RGB image we can view has gamma in it. We cannot view Raw, we can only view RGB. LCDs in our monitors are RGB. If shooting Raw, the Raw processor creates RGB with gamma for us to view, both while in work, and at output. Also the camera creates a small JPG (embedded in the Raw file), which we see on the rear LCD. It necessarily has gamma in it, any RGB we see does. (However, gamma is always removed before our eyes see it, one way or another).

This little embedded JPG may look a bit different (than when we see the Raw image converted to RGB later in ACR), because the camera applies its settings to the JPG (of WB, contrast, Vivid, whatever). But we may set different settings in the Raw software. We may select Daylight WB then instead of Auto WB in the camera for example. WB and all these things, do shift things.

But specifically, while gamma does boost the data values in the file, and while our histograms do show gamma encoded data values (midpoint is NOT 128), this boost cannot cause additional clipping. Simply because, the data values are normalized first, to be values between 0 and 1. Then 0 to power of gamma is still 0, and 1 to power of gamma is still 1. They thought this out pretty cleverly. :smile: There are no bad effects.


My own notion about why we discover things are clipped after all, is because we watched the single channel gray histogram in the camera, INSTEAD of the the three individual RGB channels it also offers. The gray channel is a false math simulation of our data (luminosity), to represent it in the same brightness tones of gray that our human eye (or film) would see for those colors. It is NOT real data, it is NOT in our file. Our eye is more sensitive to green, so it is favored (mathematically weighted), and red less so, and blue even less so. In short the Single gray camera histogram is NOT our real data, which rarely shows clipping. It shows a different concept (whereas, Adobe does their single histograms very differently, and do show real data). Why Nikon does not is a huge mystery to me.

If we instead only watch at the individual three RGB channels, then we see the real and true data, which does show clipping.

http://www.scantips.com/lights/histograms.html

 

[TonyW]

Tony, I agree with all of your post except not this, not about gamma.

Wayne we do not actually disagree :smile:. It was my explanation that was ill thought out and lacking detail :redface:

What I should have said was that as far as the camera sensor goes it is AFAIK a linear capture device and of course when we view an image we are viewing RGB which must have a gamma.

The native gamma is 1.0 for most raw capture devices and is the value used in LR for all its calculations using a single workspace based on the coordinates of ProPhoto but differing in gamma as ProPhoto is 1.8.

I assume that Camera Raw is a slightly different beast as there is a choice of spaces ProPhoto and ColorMatch having a gamma 1.8, sRGB and Adobe RGB which I believe are 2.2, but no space equal to 1.0.

The midpoint values as you pointed out are often misunderstood and misquoted as 128 RGB. These values are a handy value for Adobe PS calculations (blending modes) being the midpoint between 0-255 but do not represent a mid point in brightness to any gamma encoded workspace, at least those common that I am aware of. From memory a value of around 117/118 rgb is a mid point for sRGB and Adobe RGB and a value of around 99 rgb (if memory serves!) for ProPhoto and ColorMatch.

I agree it is folly to base our notions of exposure just based on the luminosity histogram and we should be keeping an eye on all channels, still we are limited by what is presented on the LCD display and this is an sRGB image which by its nature is not able to record all the colour gamut available in modern DSLR's which even exceed Adobe RGB. Therefore in the case of sRGB and Adobe RGB colour has to be clipped if the scene data encompasses most of the gamut of the camera sensor and AFAIK the only working space that can actually cover the full sensor gamut is ProPhoto. Sadly there are no monitors that can view full ProPhoto gamut (they may never appear!) and no printers that are able to reproduce the full gamut, although there are some inks and paper combinations that can exceed Adobe RGB in certain areas

Your link to the histograms is a very good example of why we should not trust a single luminosity histogram :smile:

 

[sizzlingbadger]

The original image looks cold, maybe the WB needs tweaking too. I also find ACR does lack saturation in the blues compared with Capture One & Aperture.

My default ACR Camera Calibration setting is now Adobe Standard with the Blue Hue at +10. This gives me the best colours for my D800, very close to an Xrite calibrated profile. I often find the Adobe Standard tone curve to be a little aggressive in the highlights though.

 

[WayneF]

Yeah, I am unaware of any reason the camera should even have the single gray histogram. It is not our real data, and in fact, it hides the clipping we want to detect. In older days, scanners often had that type, but back then, they were more likely to scan in grayscale.

Sensors are linear, but regardless of the value of gamma to be added later, gamma does not boost the 255 point. Gamma does shift data, more at low end, but it causes no clipping... the exponent math disallows it. Decoding gamma (exactly) should get our prior data back.

128 is midpoint in linear data, one stop down at 50%, just like is always explained, as if that was all there was. But in RGB (which is all we ever see), and thus in our histograms, gamma shifts it higher, closer to 3/4 scale. No one ever mentions gamma in the histogram, no doubt because then it would have to be explained. :smile: Bruce Fraser tried once in an Adobe PDF, and his stuff was normally good, but this may be his worst one. He was very wide of the mark. No details, all he did was mark gamma off into five equal steps, presumably stops, which is wrong of course.
http://wwwimages.adobe.com/www.adob...e/en/products/photoshop/pdfs/linear_gamma.pdf

But for linear midpoint 128, 128/255 = 0.5, so after normalizing, then:

Gamma 2.2, 0.5^(1/2.2) = 0.73 x 255 = 187
Gamma 1.8, 0.5^(1/1.8) = 0.68 x 255 = 173
But 1.0 ^(anything) = 1 x 255 = 255

These should be the 50% "one stop down" points in RGB, and it is approximate, but the camera does things to shift it, white balance, contrast, etc, and it varies, numbers are not very precise.