About Bit-depth Independence |
First of all, bit-depth is a term to describe how precisely you want to describe a color range. The amount of steps in a color range is calculated by taking 2 to the nth power, with n representing the amount of bits. For example, a 1-bit image gives you two values black or white. A 2-bit image gives you 2*2, or 4 values per channel. How does this translate to image quality? This following chart shows a simplification by displaying a black-and-white ramp in 1 bit, 2 bits, 3 bits, and 8 bits. Normally, you work with images 8-bits 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 in an image, the finer the 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 on 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, images in Shake are set with a byte value of 1 (8 bits), 2 (16 bits), or 4 (32-bits, or float). The above examples of 1, 2, and 3-bit images are not supported by Shake, but are used for demonstration purposes.
Most non-film composites work fine at 8 bits, the standard output of 3D renderers and most paint packages. However, there are times when you need more information in your images, forcing you up to 16-bits, or a whopping 65,000 (more or less) values per channel. A typical example is a ramp of similar values (for example, light-blue to medium blue on an image of the sky) across a great amount of screen space. An 8-bit image, though sometimes indiscernible from 16 bits on a computer monitor, will give you banding on the film out. This banding is similar to the above 3-bit example as compared to the 8-bit example. If your image is generated in 8 bits in a different package, you get no immediate improvement by merely bumping it up to 16 bits. In the above example, the ramp needs to be generated in 16 bits in order to take advantage of the extra precision of 16 bits.
An interesting note about 8-bit images is that there is no 50 percent point you have a smidge less than 50 percent grey and a smidge more than 50 percent, but you cannot get an exact 50 percent value. This occasionally comes into play when doing macros.
So, why not always work at 16-bit? Most film houses do, but the price is slower calculations, more memory required, and larger-sized image files.
Shake's 32-bit representation is special float description values can go above 1 or below 0. In all of the above examples, the ramp goes from 0 to 1. If you add two 8-bit ramps together, it would take the white values and add them together (1+1), but clip it off at 1. This is fine visually, but you may later 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 swap your Z channel into your red channel, you wouldn't want it to get clipped off at 1, because you could not tell the difference between the pixels that are 2 units away and the pixels that are 1000 units away. A float representation, however, maintains these values.
Shake recognizes and maintains the bit-depth of incoming images except for 10-bit Cineon files, which are boosted to 16. Because of the concatenation of color corrections, you are 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 resulting image is returned to its source bit-depth. However, with the use of the Bytes node, you have the option of promoting your image to a higher or lower bit depth. As the name implies, the Bytes node takes bytes as its argument, so a value of 1 equals 8 bits, 2 equals 16 bits, and 4 equals 32 bit (or float) values (There is no "3 bytes" setting).
You may need to go to a higher bit depth when using a function, notably Emboss and Blur, since they naturally create smooth gradations. In the following example, the image on the left is Blurred and then Embossed. At 8 bits, you get terracing. By inserting a Bytes node (from the Other tab) setting 2 bytes (16 bits), the Emboss is smoothed out.
8
bits
|
16
bits
|
![]() |
![]() |
2-bits, 4 values total | Graph of 2-bit image |
![]() |
![]() |
Be sure to promote the image before the Blur. 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.
|
You can seamlessly layer images of different bit depths together. The lower bit-depth image is automatically promoted to the higher bit depth (for example, an Over node 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. To reverse this behavior, insert a Bytes node before the Over on the 16-bit image to compress it to 8 bits. Bit-depth level is calculated entirely locally. If you mix 8-bit and 16-bit images, only the sections of the tree after the 8-bit image is composited with the 16-bit branch are calculated at 16 bits.
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. However, the linearization of the log files may result in loss unless you first promote your images to float. For more information, see Overview - Log space.