8 Bits Per Channel Or 16? An Old Debate

By: Kevin K. Gordon, CTO SCGI

Impassioned arguments have reverberated around forums and discussion groups on the topic of 16 bits per color component image processing vs. 8 bit. One comment referred to the subject as “a huge can of worms”. In fact, bounties have been offered for proof that a 16-bit (per component) representation of an image, enhanced in Adobe® Photoshop® can be differentiated from an 8-bit version. My explanation from an engineer’s standpoint follows and my hope is that you will have a new understanding of an old debate.

As you probably know, for 8-bit component representation, each component (Red, Green or Blue for RGB or Cyan, Magenta, Yellow or Black for CMYK) can have 256 distinct values represented by the whole numbers 0 to 255. For 16-bit component representation, each component can have 65,536 distinct values represented by the whole numbers 0 to 65,535. So for every single 8-bit level, there are 256 levels of a 16-bit representation.

Now, the typical problem with manipulating color image components in 8-bit, is resultant banding. That is, a discernable ramping, or chunky gradation of some tonality may occur when you perform certain types of correction, particularity when you really push the parameters. Even converting a source 16-bit image to 8-bit, could result in some banding, if the program converting the image data does not implement some kind of dynamic rounding or dithering. I have read many complaints about scanner software doing this.

Why?, is the question. The reason is quite simple - its in the math. Operations (as we call them at Asiva), Filters, or Effects all involve mathematical manipulation. Some are simple and other very complex. We all know for 8-bits/component, each component can have 256 distinct values represented by whole numbers. Even when you multiply or divide an 8-bit color component once with a real number resulting, it has to be converted back to a whole number. Depending upon the algorithm, the fractional part could be lopped-off, rounded-down, rounded-up. Nonetheless, the result is not necessarily accurate and will tend to lump values together, as the number of bits gets smaller. This is how Photoshop users, working in 8-bit, come up with the infamous ‘comb histogram’ or non-smooth levels with lots of gaps.

The good news for Asiva® users, Asiva Photo and Asiva Plug-ins, is that all processing is accomplished in 16-bits per component, even if you open an 8-bit image.

To get around the potential banding problem, many advanced users of Photoshop have learned some tricks to move selections from 8 bit files to 16 bit files, of the same image. This is necessary because Photoshop has limited capabilities in 16 bit. However, these methods are tricky and require quite a bit of expertise. (see schewephoto.com/workshop/pdfs/16bit_Editing.pdf)

Photoshop 8.0 will be fully 16-bit capable, so I would submit that Adobe® has made a choice on the subject.

For Photoshop® users, if there is no chance banding will appear in print, on film, on screen down the road, including clients of clients then you may well be able to work entirely in 8-bit. However, if there is any risk whatsoever, you should work entirely in 16-bit. With today’s blazing machines, enormous memory and hard drive capacities, the speed issue should be somewhat a moot point.

A More Advanced Perspective: It’s really in the Luminance component

Here, we won’t start with the same old tasteless numbers about how many levels can be represented by 8-bit and 16-bit - Lets start with something more interesting, like our visual system - yes, we humans. After all, we are the ones looking at these processed and enhanced digital images, on screen, in print, enlarged, to film recorders, etc.

Each of our eyes has about 100 million rods and only about 6.5 million cones. Rods cannot discriminate color and are much more sensitive to light than cones. It is a fact that we are significantly more sensitive to light level than color, or color level. What in the heck does this have to do with 8 or 16 bits per channel? Be patient - I am going somewhere with this.

8-bits per component for an RGB representation of an image, (known as 24-bit color) together can produce a digital range of 16.7 million different colors. We can distinguish only about 3 million different color values, so clearly the dynamic range for 24-bit color goes way beyond what we can actually differentiate.

The importance of maintaining luminance integrity is evidenced by encoding schemas like JPEG, and for video D1, D2, MiniDV, etc: the color information is compressed far more than the light information. In order for an image to appear pleasing, the dynamic range and detail of the light levels presented is much more important than a precise color reproduction.

So if we could have a hypothetical digital color representation where luminance had at least a 10-bit bandwidth (1024 discrete levels), then we could in fact get away with representing the chrominance (basically hue & saturation combined) in 8 bits.

For digital image and video processing and enhancement, my experience is 10 bits per component will do the trick. This exists in one flavor of the professional digital video format D1. Scanners will also often output a RAW format with 12 bits per component.

Years ago, working in 8-bit D1 video, we saw banding problems and other oddities often enough to switch to 10-bit D1. Any and all problems were solved. With this knowledge we designed all other Asiva products to work in 16-bit internally, since you can only hold data in 8-bit increments. In other words, I feel 10-bit is sufficient for most cases but 10 bits can only be stored in a 16-bit ‘slot’ so why not use all of it.

Kevin K. Gordon is the CTO of Shapiro Consulting Group, Inc.