Two Histogram Types
Definitely be aware of this - One type of common histogram does not actually show your real data.
Histograms can show just the one individual Red or only the Green or only the Blue channel, but they typically show a three channel combined "gray" value (another reason I refer to "middle gray" when the image is mostly green.)
There are two types of these combined histograms:
There is a "RGB" type (Adobe is a leading example) where the three RGB channels are simply shown superimposed on the histogram (overlaid in place, real data, but gamma encoded), so that any red pixels are still shown at the red pixel values, etc.
The colors may not be distinguishable there as such, but they do not shift position.
And there is the "Luminosity" type, where the RGB channels are combined by first converting to compute simulated gray scale data using the NTSC television standard formula, to create the new simulated grayscale pixels:
Luminosity = 0.3 R + 0.59 G + 0.11 B
Graycale is just one gray value per pixel, and this is that value created from RGB colors. This formula has been used for over 70 years as the universal accurate way to convert RGB to grayscale. The numeric coefficients add to 1.0, and this is the way the color components of every RGB pixel are "weighted" to create the pixel's one gray value.
That gray value represents the relative brightness that pixel's original color would appear to the human eye in a grayscale image, including on B&W film.
The idea is that the pixel's resulting single gray tone represents the relative brightness that human eyes and brains perceive color, based on our being more sensitive to green, and less sensitive to blue.
Luminosity was very important in gray scale images - to maintain accurate relative brightness of red lipstick, green grass, and blue skies, etc. The photo editor's Grayscale menu will use this standard formula.
Example: a Nikon D300 camera LCD showing a close up picture (camera exposure mode A) of this one red color (original is RGB 255, 103, 95, gamma encoded values.)
The D300 camera LCD shows the histograms as above, which shows the individual RGB channels (255, 103, 95), plus it shows the computed Luminosity composite (grayscale value).
Note that when Nikon is showing the single value, it is luminosity.
Also note the Luminosity display does not give any hint that the red channel is clipping. I selected a red color here, because red flowers are tough this way.
The Luminosity value shows 148, in which each pixel's gray value is computed from the standard formula. The Red 255 value contributes to the sum only as its 0.3R component (equivalent gray tone is 77). The luminosity 148 sum is not any one of the RGB values - it is a computed theoretical value (the grayscale value).
Most normal images have wider content and a smoother response and may appear "less different" than this one, but they are not, any image is the same concept. This new luminance sum shows the "relative brightness",
specifically, the way this color would look in B&W film. Here it is near the middle - not bright, and not dim.
Adobe shows the three RGB channels overlaid in place for this same image, this way:
This was ACR (Adobe Camera RAW.) Photoshop Levels is RGB type, but does not indicate the colors - the same overlaid data is shown as one gray curve, but it is not the grayscale luminosity curve (unless it is a grayscale image.)
The Photoshop "Window - Histogram" menu window has an option to show luminosity, but it is not the default for RGB images (grayscale data is necessarily luminosity.)
However, luminosity is the default view in some programs and cameras and scanners (just how it was always done.)
The Nikon camera's single histogram shows luminosity too, so be aware that only the individual RGB histograms show the red clipping information we seek.
Note that while we may have alternate creative methods of converting color images to grayscale (Adobe channel mixer for example),
these methods are ways to do tonal editing to modify the standard grayscale results (for nonstandard results, about how dark is red or green made to actually appear?)
Note that the editor's actual Grayscale menu uses Luminosity, which is THE ONE numerically precise way to do it, to represent the same real way B&W film would have done it. There is a good reason for the Grayscale menu.
BUT ... when concerned about our digital images tones being clipped, Luminosity is not a good choice, it does not show actual RGB values.
These RGB and Luminosity modes are easy to detect - just inspect to see if the composite graph contains peaks corresponding to the individual channels, or not.
Regardless of histogram type, all data in all RGB images is gamma encoded.
So there are two ironies here... 1) Our only use for histogram in the camera is to judge clipping, but the standard luminosity curve cannot show that in practice.
2) Luminosity is used to represent relative brightness of the colors, but the RGB data is gamma encoded, so that middle range is not at middle, but instead up closer to 3/4 scale.
It does go better when we understand this.
Histograms
A histogram is a simple bar chart showing the count of the image pixels having each data tone 0 to 255. The height of each bar shown represents how many pixels have tonal value of 0 (black), and how many pixels have values of 1, and 2 and 3, ... all the way to how many, if any, have tonal value of 255 (white.) It shows the distribution of the pixel tones, over the tonal range. More exposure will shift the graph data right, and less exposure shifts data left (because relatively more pixels will have brighter or darker data). With enough exposure, we can make black appear white, or vice versa, but the correct exposure is important to put the tones where they ought to be, which makes them be the tones they should be. A histogram is NOT a light meter, and nothing there has any clue what it is or how it "ought to be", but the histogram can show "what we do have", and can help show relationships, for us to decide.
Histogram bar charts are commonly shown 256 pixels wide on video screens, and thus always necessarily represent 8-bit color. Our monitor's width simply cannot display a 12-bit histogram 4096 bits wide, so don't kid yourself about the histograms for your 16-bit data (64K bits wide).
Where should the histogram data be? Well, that depends on the scene in front of our camera. If it is a correctly exposed black cat in a coal mine, most pixels will be near the left end. If a correctly exposed polar bear on the snow, most pixels will be near the right end. However, the reflective meter in the camera will try to put both of these cases somewhere around the middle, as shown at How Light Meters Work. Proper exposure is what shifts the tones to be what they should be. Most "average" or "typical" general scenes will usually meter about accurately enough, because their subject includes a wide range of stuff that covers most of the full range - some bright stuff and some dark stuff, and all in between. The typical general scene really does often average out near middle gray, and the reflective meter tries to put all scenes at middle gray, and this often works out about right (mostly). That is simply how reflective light meters work. But many scenes are exceptions too, which we need to watch for.
The one unquestionable thing the histogram data shows us, why we watch it, is if we see a thin spike right on the right edge (too many pixels of value 255), then we have overexposed, and are clipping our tones, so that any brighter tones are clipped to remain at 255. Generally too, we do like the right end of our data to be up high, not right at 255, but fairly high. Which is not absolute, it merely assumes our wide-range image actually contains some tones which ought be up high - which is not always correct. We must use our heads too, and the image preview on the camera rear LCD is maybe better to judge this.
The problem : Regarding the specific numbers, we need to understand what histograms actually show. At first, everyone seems to imagine that 128 is midpoint of their histograms, and that 18% gray cards are middle gray, and the gray card ought to show up at midpoint of their histogram too. We are led to believe this by much of the literature. But none of that is right, at least there is more to it, so that it is not the right idea. Specifically, at the most fundamental level, the histogram shows gamma encoded data, and all numbers in the histogram are different than "theory" - which I hope to make obvious.
The overwhelmingly significant one-line answer:
Our histograms show gamma encoded data values.
And some cases are instead showing simulated grayscale luminosity (column at right).
Gamma
We know our digital images use profiles like sRGB, which we know specify gamma 2.2. Unfortunately, what no one ever seems to realize is that this obviously specifies that our digital pictures are gamma encoded. Unequivocally, all of the digital pictures in the world are gamma encoded. It needs to be overtly said that all of our histograms specifically show this gamma encoded data. We seem to ignore that. The technical stuff assumes it of course, but it never seems mentioned in any basics. The basics just seem to blunder around it, avoiding the subject, and which is no explanation at all, misleading at best.
Here is the tricky part: There are two concepts involved - one is analog light in the real world, including also digital RAW data at the camera sensor itself. These are linear data. And then there is also the gamma-encoded digital data in the output image - which is NOT linear. Here, the word linear simply implies "not yet gamma encoded". In the math sense, linear means data which graphs as a straight line, so that twice as much input will output exactly twice as much. Opening each f-stop is twice the light and half the shutter speed, that's an example of linear. Non-linear means the response does not exactly track the original data. Gamma is an exponential math curve, not linear, and common usage comes to be that "linear" in video work often simply denotes "not yet gamma encoded". Because, it will be, before it goes into an image file. The RAW data is still linear at the digital sensor itself, and in RAW data, but all output RGB data has been gamma encoded.
My entire point is that if we are going to ponder the numerical values in the histogram, then first, we must understand what it shows. And we need to realize that all discussion of gray cards, and step charts of gray tones, Ansel Adam and his Zone System, anything about film or paper, is all analog stuff. Nothing wrong with it, processing film to paper print, until we try to imagine our digital data is the same. It is not the same. Analog is 1) not digital, and it is 2) not gamma encoded data. There are no histograms in analog data. Our digital data is a different representation of the original analog scene, and the concepts differ. Histograms show gamma encoded binary RGB data.
The sources never tell us about that part... Because then they would have to explain gamma, and that's like math, and many of us would tune out. However, you are never going to "get it" until you are at least aware that gamma exists. Gamma can be made complicated, but I'm going to tell you the simple story, and it really is pretty easy... really, no big deal at all, so hang in there. It is the least you should know about the histogram numbers.
Why Gamma?
Frankly, we don't even care why anymore, it just always happens. Automatically, silently in the background, simple fact, all of our digital images have always been gamma encoded. Gamma is easy to ignore, it takes care of itself... Until the time we get involved with the details, like pondering the numerical values in the histogram, then we have to pay attention, and know more. The histogram shows that gamma encoded data.
But here is why gamma: Up until LCD monitors in recent times, for years and years, we used to watch television and computer screens on cathode ray tube displays (CRT - the old stuff.) But this took some doing, because CRT screens do not have a linear response. Their electron gun has an exponential response curve. Meaning, only the brightest signals showed up on the face of the CRT, and dim values simply disappeared. Without correction, it was not possible to show tonal data.
This faulty CRT response curve was called gamma (gamma is just a Greek letter, used in science like X in algebra.) Many other things are also called gamma - film gamma for example is a completely different concept, not remotely related in any way to CRT monitor response gamma.
Earliest television (first NTSC spec in 1941) solved this CRT problem (non-linear response curve) by encoding the transmitted broadcast signal with opposite compensation for the monitor. Television boosted the darkest values more, and the brighter values less. This was called gamma correction (which is the proper search term.) The CRT problem was that it showed output response to data X as if it were instead (X to the power of 2.2.) The screen images came out unusably dark, only the brightest areas remained. So to offset this problem, each data value was first intentionally oppositely encoded using an exponent of 1/2.2. This 1/2.2 exponent is numerically near 1/2, so the idea roughly approximates using the square root of all data values. This reduces the bright areas more, but then after subsequent amplification, in effect, low values are boosted more than strong values.
That concept is the only math to be presented here. You've seen it all now, so hang in there. :) But seeing the graphs probably would help - see HERE .
That corrective 1/2.2 gamma curve boost compensation corresponds to about how much the CRT display loses low level signals, and it came out looking just about right on the screen of the CRT. Doing this encoding in the broadcast transmitter one time was much better than adding circuits in EVERY television receiver to do it. Boosting the low level signals helped noise on the transmitted analog signals too. Because the data was gamma encoded, then all a CRT had to do was to display it, and the losses were precomputed, and it came out right. It became the original linear signal again (the brightness on the CRT screen output), for the human eye to see.
When we started using CRT for computer monitors, they had the same CRT losses as TV. This didn't matter in the first days, when all we viewed was text - early text only had eight colors and two intensities, and the hardware managed the levels. But when we started getting into tonal computer images (increasingly popular by 1990), this gamma correction necessarily became the world standard for all images... All computer digital images, and all TV images, all are gamma encoded, with exponent of roughly 1/2.2. Again, this was to compensate for the CRT losses which were roughly exponential with a 2.2 exponent, which we call gamma.
This means EVERY photo image (and every television or movie frame) digitized into any computer has been gamma encoded. The only exceptions are the RAW images (which are not gamma encoded yet, and our monitors cannot show RAW anyway, but certainly these will be encoded later, before we can have any use for them.) And also, one bit images (called line art, bi-level, B&W, fax, etc ... which is not tonal data - not photos - contains only two values, 0 or 1.) But any photo image (color or grayscale) that we can view on a computer is gamma encoded. Other exceptions are of course film images while actually on film or print paper - all still analog - but when in a computer, they were scanned to be digital, and everything is gamma encoded. All scanners and all digital cameras have always output gamma encoded digital image data.
Printers need gamma too, not as much as 2.2 for the CRT, but they need most of it (for dot gain, etc.) Until recently (2009), Mac computers used gamma 1.8. They could use the same CRT monitors as Windows computers, and those monitors obviously required gamma 2.2, but Apple split this up. This 1.8 value was designed for Apple's early laser printers, to be what the printer needed. The Mac video hardware added another 0.4 gamma correction for the CRT monitor, so the result was an unspoken gamma 2.2, roughly - even if their files were gamma 1.8. The last few Mac versions now observe the world standard gamma 2.2 in the file, because all the world's images are already encoded that way. But yes, printers are programmed to deal with the gamma 2.2 data, and to adjust it to their needs.
Today's LCD monitors have a linear response... a very different technology. LCD has no losses like CRT - therefore they do not need gamma correction. However, the world standards now are that all of the image data in the world is gamma encoded, digital TV signals too. The original reason may have been years ago about CRT, but now the LCD has to deal with it too. A LCD monitor specifically must decode gamma first, where a CRT does the same by merely showing it. It is built-in, it just always happens. This is not a bad thing, there are reasons it may even be a good thing, but either way, it is simply easier to continue this now, than to change everything - and I mean everything. ALL of the existing digital image data in the world has been gamma encoded, and continues to be, and the LCD monitor must deal with it. Today's silicon chips make that be an easy job. Your little pocket player that shows images deals with it too.
The gamma image is always decoded back to linear analog, one way or another, before it is shown to the analog human eye - so that it is hopefully still a faithful reproduction of the original real world analog scene. The CRT and printer merely output it to analog, and their losses decode it to be linear again. The LCD monitor just does some math - it is only numbers, nothing physical which can fade or erode. When this image is in the air on its path to the eye from the monitor, the image is no longer digital. So linear is always sent to the eye, as the eye expects - to be the same linear view that the camera lens saw.
But then (another tricky part) the human eye's own response is logarithmic (exponential.) It is said that our brain perceives that we see 18% as "middle gray" (in common lighting situations, not too bright or dark.) This is the ONLY relationship with the term "middle gray". The term is certainly not about histograms or digital. It is only about how the human eye perceives 18% ink on paper. In 1940, Ansel Adams hoped his 18% Zone V on film and print would appear middle gray to the human eye.
The digital camera CCD and CMOS sensors are linear (not yet gamma encoded), speaking of the RAW data at the sensor. However, we don't have tools to see RAW data. Our monitors and our printers display RGB data. The camera's RAW file includes a RGB JPG to show a preview on the cameras rear LCD, and the histogram shows that JPG's gamma encoded histogram. All digital image data (all but RAW) is gamma encoded.
The word linear has two meanings in video, one is the "graph as a straight line" idea in math, but mostly in video, usage also simply implies "not yet gamma encoded". Because it will be gamma encoded at RGB output. This is the world standard - all image data in the world is gamma encoded. All cameras and all scanners, and all RAW processors and all photo editor programs, output gamma encoded images. Excluding RAW images (which we cannot view anyway), all photo images are gamma encoded. All histograms show gamma encoded data. The histogram numbers are simply different than the linear numbers we might imagine (chart list below.) Just how life is. We may as well expect it. :)
Simplest test to show obvious truth - Histograms show gamma data
With your camera, carefully expose a white subject, adjusted so the histogram data edge lines up very near 255 (but without significant clipping.) Then intentionally underexpose it exactly one stop. We know that one stop is half of the light, and we might imagine that the right edge will move down to 255/2 = 128. And it would, in a linear histogram, at the RAW sensor, just like we have always been told. However, we cannot see RAW data (no tools.) Anything we can see on a monitor is RGB data, and all we can ever see in a histogram is the gamma encoded RGB data. 128 may be the linear midpoint of 0..255 RAW data, but all we can see is that all RGB data is gamma encoded, which shifts the linear 128 up to about 187 (73%) on the gamma encoded histogram that we see. In that gamma encoded histogram we see, it is a mistake to call 128 the midpoint. This concept is sort of big, and it obviously exists, just look. It doesn't actually affect our pictures, because it will be decoded back to linear before our eyes see it - but it obviously affects the numbers in "storage", in the encoded histogram data.
-1 stop = (0.5 ^ 1/2.2) = 0.73, x255 = 187 73% of 255 full scale. This is obviously the midpoint we see.
Here is the ugly part: These numbers vary. This 187 is not a precise number. It depends ... the camera is busy doing other shifts - white balance and contrast shifts (S curves), and other manipulations, like brightness and saturation, etc. These are tonal changes, and when it changes things, it changes things. But it is clear that this new value of "half intensity" is far from 128 in gamma data. The 255 shifted down one stop will be much closer to 3/4 than to 1/2. This is obvious, just look once. It is due to gamma encoding the data, done according to sRGB specifications. The histogram data we see is gamma encoded. The midpoint we see is not at 128, not even close.
Again, camera manipulations (like contrast, white balance, brightness, etc) can shift these values a little.
I am not saying our data has 8 stops of range. Sure, we can compute any infinitesimal fractional value, but no claim is made that we can distinguish the seventh stop from the sixth. The gamma encoding does increase these values (good for noise in transmitted analog signals), but all data is decoded back to linear again before we ever see it.
The linear chart is only applicable to the RAW data at the camera sensor. The only reason to show it here is that much literature we see refers only to it. However, we are unable to see RAW data - our eyes and our monitors are only RGB. Any digital data we can see has previously been gamma encoded (and is decoded just before we see its analog equivalent.)
Idle discussion: There are some tricky points : Note that while the clipped red 255 in the right hand column above is gamma encoded, seeming to imply the original value was lower, in this case (full scale = 1.0, and 1 to any exponent is still 1), so this full scale case was in fact 255 at the raw sensor too.
In the gamma data, the end points do not move - the dynamic range stays the same - but the binary data definitely is gamma encoded (in the histogram too.) And of course, the data is ultimately decoded back to linear analog just before the analog human eye sees it. Many LCD monitors have been only 6 bits internally, but televisions are more likely to be 8 bit, and a few are 10 bits now. So CRT or not, there are some possible pluses today. If you have 10 bit video output, gamma can get more of the 12 bit camera data range to it, by bypassing 8 bit linear conversions (in the file.) Gamma turns out to be a very fortunate coincidence.
The funny thing is that some people recalibrate their light meter to put a gray card at histogram 128 (calling it "midpoint".) They heard 18% was middle gray, and they heard 128 was the midpoint of the histogram, so naturally, middle is middle (if we don't know or care what the terms refer to), and they assume there is some magic so that the gray card ought come out at middle. It doesn't, 18% is not 21.8%, so it should always be a bit low.
18% is not the middle of anything digital. Simply unrelated. Plus, it does not matter if they meter a 18% card, or a white card, or a black card... the meter tries to make them all come out the same, near middle, more or less.
The right idea is that we can meter the 18% card (an average subject) to get a reading to use for the external scene, also assumed to be average. It is NOT about photographing the dumb card.
Coincidentally, this "midpoint" misunderstanding causes only a small error, maybe 4%, not really the worst thing. Certainly it can be compensated, but certainly it is pointless, and plainly is the wrong idea. It is only coincidentally close to "center" because of gamma.
18% is not the midpoint of anything digital, and actual midpoint is up near 187 at 73% anyway. And it can vary with different contrast manipulations in digital cameras.
Better read Sekonic's calibration procedure again, which does not mention gray cards.
According to Sekonic (and the ISO organization), the right idea is that if your meter repeatedly and continually gives a consistent error on a wide range of scenes, THEN adjust the meter to compensate.
Yes, Ansel Adams did promote 18% as middle gray at Zone V back in the 1930s, but he was not using digital, histograms, or gamma encoded data. He likely never saw a histogram back then. His reference was the human eye's response of analog tones printed on paper.
And Kodak said to open 1/2 stop, after metering on their 18% gray card.
The more correct value used by light meters today is more near 12% (which is Kodak's half stop under 18%).
Most light meters (Sekonic, Nikon, Canon) are factory calibrated to 12.5%.
Reference links
Google - Gamma Correction
How Light Meters Work
Wikipedia - Calibration of light meters
Menu of other photo pages here
Copyright © 2011-2012 by Wayne Fulton - All rights are reserved.
