The Road to HDR: A Bit About Bits and What They Get Used For in Digital Photography
Digital is all about off and on, zero and one. In order to represent anything more complex such as a photograph, you need multiple bits. Digital imaging is therefore a numbers game so I figured it would be worth taking a look at what all those bits get used for, and what all this has to do with HDR imaging.
Most images that you and I work on are stored in RGB color mode meaning that at each point (pixel), color is represented by a set of three numbers, one each for red, green and blue. The usual arrangement uses one 8-bit byte for each color, or 24 bits in total for each pixel. This is termed 8-bit RGB mode. A single bit can represent just two values, zero and one. Adding a second bit doubles that to four possible values and so on, with each additional bit doubling the number of possible values that can be stored. If you multiply all that out you get a total of 256 distinct values ranging from zero to 255 for each 8-bit byte, which translates into 256 distinct shades each for red, green and blue. That's not really all that many different shades for each primary color channel, but since each pixel has values for each, you can represent 256 times 256 times 256, or approximately 16 million different real world colors, which isn't too shabby after all.
That's a pretty big box of crayons to work with, but even though the resulting number of possible colors in 8-bit RGB is large, it is not unlimited. If you want to represent a color that happens to fall between two of these, you can't. You have to pick whichever one is closest to the color you really want.
If you're working in a smaller gamut color space such as sRGB, the colors you can represent are spread throughout a small enough space that each one isn't all that far from its nearest neighbors. But as you move to a larger gamut color space such as Adobe RGB or even ProPhoto RGB those colors must naturally be spaced further apart to cover the increased gamut. While the gamut gets larger, the total number of possible colors doesn't. Eight bits for each of red, green and blue still gives you only 16 million colors no matter how much area you have to spread them over. You don't get more colors in a larger gamut color space, you just space the ones you do have further apart. In a big enough color gamut, the inability to accurately describe those "colors between the colors" becomes apparent, particularly when those colors represent a smooth gradient area such as the open sky.
But what if you did have more than eight bits per color channel? Stepping up to 16-bits per channel will obviously make file sizes larger but it does give you a more colors to work with too. A lot more. Instead of stopping our doubling when we got to 256 as we had to when we ran out of the eight bits we had previously, we can now keep on doubling eight more times over. To spare you the arithmetic, that ends up providing over 65 thousand shades for each of the red, green and blue channels in an RGB image. Multiplying those together as we did above gives a grand total of over 281 trillion crayons to spread across whatever gamut we are working in. So now between each of those original 16 million colors we now have an additional 16 million colors that can be described. 281 trillion is 16 million times 16 million. Errors that might be noticeable when working in 8-bit mode become insignificant and quite unnoticeable in 16-bit mode. sRGB works just fine for the most part in 8-bit mode. Adobe RGB is pushing it, but ProPhoto RGB all but requires the use of 16-bits per channel to get good results.
So why doesn't everyone work in 16-bit ProPhoto RGB? After all, if 16-bit means greatly improved accuracy and ProPhoto means a wider range of possible colors, why use anything else? The simple answer is that sometimes you really just don't need that wide of a gamut. For example, there's little point in being able to describe colors you can't actually reproduce on a monitor screen if your target is a web browser display. Maybe someday in the future monitors, printers and other devices will be up to the task of wide gamut images, but at least for right now sRGB works fine for many purposes and sRGB works fine in 8-bit mode.
One thing that both 8-bit and 16-bit RGB have a problem with is extremely dark or extremely bright colors. Cut the exposure of a digital image by half and you end up not using a heck of a lot of colors that are describable in whatever bit depth and color space you are working in. The objects you are photographing don't really change, but your ability to describe them accurately suffers. Cut the exposure in half again and the problem grows progressively worse. The same thing happens if you increase exposure beyond the range of what you were expecting. At some point, everything becomes pegged at or near 255 in 8-bit mode or the equivalent in 16-bit.
Yes, you could keep adding more bits to solve this problem, but doing so would only make efficient use of those bits if an image had both extremely dark and extremely bright pixels at the same time as well as everything in between. And even then you could cause the problem all over again by changing the exposure of that image up or down a couple of stops. There's just no getting around the fact that describing colors and particularly brightness in this way has its limits no matter how many bits you have to work with.
All this brings me to 32-bit mode. While you might assume that 32-bit mode simply does for 16-bit what 16-bit does for 8-bit, but the people that came up with 32-bit had something else in mind. Often referred to as High Dynamic Range or HDR, 32-bit mode separates the problem of describing what color something is from how bright that color is. There are several similar HDR file formats but all are set up more or less the same way.
Rather than storing numbers simply as ever increasing integer values, the data is instead stored in what is known as exponential notation. This consists of using some of the available bits to store a floating point (fractional value) between one and 10 to describe how much of that color channel's color is present, and the remaining pixels to express a power of ten to multiple that floating point value by to describe how bright that color is. This brightness component is called the "exponent" while the fractional, color portion is technically known as the "mantissa." If you've ever used a calculator to work with extremely large numbers you've probably seen it display numbers this way. It's a common solution to such problems but may be new to those who spend more time around cameras than calculators.
With an HDR image, you can cut the exposure or raise it by any number of stops within an extraordinarily wide range and still describe the exact same color since only the exponent portion of the value changes while the mantissa stays exactly the same. While a standard "low dynamic range" (LDR) image uses one value to express both color intensity and brightness, an HDR image uses separate values for each so that a change to one does not affect the integrity of the other.
Earlier I said that since real world devices are only capable of displaying a limited range of colors it might not make sense to work in a format that describes colors you can't fully use. Of course, if you need to convert between the gamut of one device and that of another, it is helpful to work in a color space (and corresponding bit depth) that encompasses both. But what about a file format like HDR that is capable of accurately describing colors so extremely bright or dark that no device can really display them? If an image requires HDR to fully describe it without loss, what is the use if no device in existence can render at least parts of it as anything other than white or black?
To answer that I'll need to describe something known as "tone mapping," and that's the topic for next week's article.