About Bit-depth Independence

First of all, bit-depth is a term to describe how precisely we want to describe a color range. We can calculate the amount of steps in a color range by taking 2 to the nth power, with n being the amount of bits. For example, a 1-bit image gives you 2 values, black or white. A 2-bit image gives you 2*2, or 4 values per channel. How exactly does bit depth work? This following chart shows you a simplification by displaying a black-and-white ramp in 1-bit, 2-bits, 3-bits, and 8-bits. Normally, you are working with images 8-bit or above:

1-bit, 2 values total graph of 1-bit image
2-bits, 4 values total graph of 2-bit image
3-bits, 8 values total graph of 3-bit image
8-bits, 256 values total graph of 8-bit image

 

These graphs demonstrate that the more bits you have, the finer your color transitions. Because of the responsiveness of film, and the size of the screen, an image that looks fine at 8-bits on video may look terrible when brought to film. Digital film compositing refers to bit depth on a per-channel basis, so 8-bits refers to 8 bits per channel, or 32 bits total for an RGBA image. It gets slightly confusing, since Shake can go up to 32 bits per channel, meaning 128 total on an RGBA image. To complicate things, since 8 bits equals 1 byte, we set images in Shake with a byte value of either 1 (8-bits), 2 (16-bits), or 4 (32-bits, or float). The above examples of 1, 2, and 3 bits images are not supported by Shake.

Most composites will work fine at 8 bits, the standard output of 3D renderers and most paint packages. However, there will be times when you need even more information in your images, forcing you to go up to 16-bits, or a whopping 65,000 (more or less) values per channel. A typical example is a ramp of similar values (i.e., light-blue to medium blue on an image of the sky) going across a great amount of screen space. 8 bits, though sometimes indiscernible from 16 bits on a computer monitor, will give you banding on the film-out. This banding is similar to the 3-bit example up above as compared to the 8-bit example. If your image was generated in 8-bits in a different package, you will get no immediate improvement by merely bumping it up to 16 bits. In the above example, the ramp would have to be generated in 16-bits in order to take advantage of the extra precision of 16 bits.

So, why not always work at 16-bit? Most film houses do, but the price is slower calculations and larger-sized image files.

Shake's 32-bit representation is special, since it is a float description, which means values can go above 1 or below 0. In all of the above examples, the ramp goes from 0 to 1. If you added two 8-bit ramps together, it would take the white values and add them together (1+1), but clip it off at 1. Visually, this is fine, but you may later want to do other mathematical computations in which it is important to realize that 1+1 is 2, not 1. A good example is the Z channel, which is always in float. The Z channel is usually generated by a 3D render, and supplies the distance on a per pixel basis of the object from the camera. Therefore values could go from 0 to infinity. If you are swapping your Z channel into your red channel, you wouldn't want it to get clipped off at 1, because we wouldn't be able to tell the difference between the pixels that were 2 units away from the pixels that were 1000 units away. A float representation, however, would maintain these values. Another example is a yellowish pixel with an RGB value of (.8, .7, 0) gets a brightness applied that doubles its values. Normally this would produce a pixel with values of (1,1,0), but with a floating point representation, the pixel will actually have values of (1.6, 1.4, 0). Why does this matter? Because your next operator may divide these values by 3, leaving you at (.5333, .4666, 0), a medium orange. If the image was clipped at 1 (i.e., not in float), you would have (.333,.333,0), a dark yellow.

Shake recognizes the bit-depth of incoming images and maintains that bit depth. Because of the concatenation of Color corrections, the user is penalized less frequently when working at 8-bits than in other software. This is because the adjacent color corrections are collapsed into one mathematical lookup table, in effect doing the computation in float. The result is then returned back to its source bit-depth. However, with the use of the Bytes node, you always have the option of promoting your image to a higher or lower bit-depth. Note that the Bytes node, as its name implies, takes bytes as its argument, so a value of 1 = 8 bits, 2 = 16 bits, and 4 = 32 bit (or float) values. There is no '3 bytes' setting.

You can seamlessly layer images of different bit-depths together. The lower bit-depth image is automatically promoted to the higher bit depth (i.e., an Over command with an 8-bit image and a 16-bit image results in a 16-bit image). This is invisible to the user; it is automatic. If you want to reverse this behavior, insert a Bytes node before the Over on the 16-bit image to compress it down to 8 bits. Bit depth level is calculated entirely locally, meaning that if you mix 8- and 16-bit images, it won't calculate the entire tree at 16 bits, only the parts after where the 8-bit is composited in some way with the 16-bit branch.

10-bit Cineon files are automatically promoted to 16-bits when read in or written by Shake, so you don't have to worry about any data loss.

You will sometimes find the need to go to a higher bit-depth when using a function, notably Emboss and a Blur, since they naturally create smooth gradations. Here is a good example. The image on the left is Blurred and then Embossed. At 8 bits, we get banding. By inserting a Bytes operator (from the Other tab) and going to 2 bytes (16 bits), the Emboss is smoothed out.

8 bits

16 bits


Be sure to promote the image before the Blur, not afterwards. This doesn't mean you need to do this before every Blur, simply that Blurs, by their nature, are prone to displaying banding when you perform many operations on the blurred image.