What Log Is…….And Isn’t

With the rapid success of the Arri Alexa, the continuing evolution of Red (specifically its deployment of the RedlogFilm gamma curve), and the use of log curves in things like the Sony F3 and Technicolor’s Cinestyle curves for Canon DSLR’s, I thought it might be a good time to talk about exactly what log is and is not, specifically in the context of digital images.

In a mathematical sense, a logarithm is a “power function.” In a logarithmic progression, each value is the previous value raised by a power of the logarithmic base. This is a rather convoluted way of saying that if you have, for instance, a base 2 logarithm, each value is followed by a value that is the next power of 2. So if your first value is 0, the second value is 2. The next value is 2*2, or 4. The next value is 2*2*2, or 8. The next value is 2*2*2*2, or 16. You get the idea. In logarithmic notation, this is expressed in terms of the power, not the value. So 16 in a log base 2 progression would be 4 (2 to the 4th power). This comes in handy when doing math, since instead of having to do all kinds of multiplication, you can do simple addition, because in a logarithmic series, adding the log values is the same as taking the log value of the result. So if you wanted to multiply 2 times 4, you could take the log values, which would be 1 and 2, and add them. That would give you 3. Conveniently, 2 to the third power is 8, which is also the value of 2 times 4. Where all of this is going is that by using a logarithmic progression, you can express a very large range of values with fewer numbers. It also happens to be how both the world of light and human vision interact, which roughly relates to the concept of stops in photography, in which each stop represents twice the light of the previous stop – essentially, a base 2 logarithmic progression. But this really comes into play when we consider how images are captured and stored.

For practical reasons, the size of image files cannot be unlimited. It needs to be of a size and complexity that can be handled by software and hardware at a reasonable rate. In the case of moving images, it needs to be playable in real time by common hardware. This is where bit depth comes into play. The larger the bit depth, the more accurately the information is represented. With infinite bit depth, the information is essentially identical to the original analog equivalent, in other words, a perfectly smooth curve. But that is currently unachievable, so instead, we use bit depths that are an acceptable compromise between the practical needs of file size, and the characteristics of displays and human perception. The most common bit depth in professional image file formats today is 10 bits. That is increasing due to faster hardware and software, but it is still the most common format, and the one that was chosen by Kodak for its Cineon file format based on film imagery. Most modern digital cameras, however, have sensors that produce information that is at least 12 bits wide, and is usually used to create images that are 16 bits wide, even if only as an intermediate format. So the issue becomes how best to represent a 16 bit linear image (all digital cameras produce linear light images internally, regardless of their output format) in a 10 bit container. This is where log coding comes into play.

In a 10 bit format, you have 1023 possible values (2 to the 10th power). How you use those 1023 values is up to you. If you have a 16 bit image, and you want to express it in 10 bits, you have some choices to make. Since a 16 bit image has 65,535 possible values (2 to the 16th power), you can simply interpolate and make each of those 1023 values represent a larger range of input values, but doing that will likely cause banding or artifacting when a 16 bit value falls between 2 of those levels and the interpolator must choose one of the other. However, another way of looking at the problem is to consider that you’re dealing with images, not values. Assigning the 1023 values in a linear way means that all of the ranges contained in the image, from the darkest to the brightest, will be assigned the same number of levels with the same differences between them. Since our perception of visual imagery is basically logarithmic, this is a very wasteful use of some of those values, because humans don’t perceive detail in very bright areas or very dark areas. If we “weight” the 1023 levels, and assign fewer values to the very bright areas, and more values to the areas that are most critical to perception of the image – i.e., from the lower midrange to the upper midrange – we’ll get a very good representation of the image, but use more values where they’re needed. This is the essence of log coding. It allows us to use both mathematics and the science of human perception to essentially allow a 14 to 16 bit linear image to be effectively represented using 10 bits.

Which brings us back to the title of this post. What log is, is an image container. A bucket that contains image information. What it is not, is a practical, viewable image in and of itself. This is a very important distinction to make in order to understand how best to deal with log images in a typical color grading pipeline. Many people, both colorists and non-colorists, look at log images and think gee, this is a nice flat image that I can do anything with. And while there’s a bit of truth to that, what you do and how you do it determine whether you’re going to recreate the actual photography as originally intended, or wind up with something that is less than optimal. Since as we’ve already noted log coding is a mathematical way of fitting more information into fewer bits, it does things to the image that must be undone if the original image is to be properly recreated with the most fidelity. What needs to be done to accomplish that will be the subject of the next post.