Back To Listings RSS Print

Log vs. Raw: The Simple Version

Raw is all the rage, but should it be? Log gives us 99% of the benefit of a raw file in a grade but with much smaller files.

By Art Adams | February 06, 2013

Years ago I wrote an article describing how log encoding works using Sony's S-Log as an example. Sony's S-Log2 is coming down the pike in a big way in their F5 and F55, so it seems like an appropriate time for an update.

First of all, I should warn you that this is a much, much simpler article than the last one. Occasionally I'm accused of being too obtuse, so I'm going out of my way not to go that direction. I suspect this will be easy because my knowledge of log curves stops at the line where math starts. Thanks to a nifty new program I recently bought, OmniGraffle Sketcher, I can illustrate how log works without having to bother either of us with equations or references to exponents.

Well… there may be one or two references to exponents. Stay with me.

In its simplest sense gamma describes how tones are mapped into a range of values between maximum black and maximum white. (This isn't perfectly correct but it's the way gamma is most commonly understood.) Let's assume a video image is encoded in 10 bits per color channel, which means that red, green and blue each have a maximum possible value of 1024 and a minimum possible value of zero. (The actual values are different, but I'm rounding off for simplicity.)

When a photosite is hit with as much light as it can stand it outputs a voltage that is converted by the camera's analog-to-digital converter into the maximum brightness code of 1024. If that photosite is struck by half that much light it reports a voltage that is translated into value 512. Half of that much light is reported as value 256.

Do you see a pattern here? Nearly everything in photography relating to exposure is doubles and halves, and in this case halving the number of photons striking a photo site results in that photo site reporting half the light--or one less stop--from the previous value. The code value for the next stop down from 256 is 128; from 128 is 64; from 64 is 32; from 32 is 16; etc.

Here's how that looks on a graph:

What you'll notice is that the graph drops off really, really quickly at the highlight end (right side) of the curve. The top code value of 1024, representing the brightest highlight, plunges to 512 over a difference of one stop. If you're storing raw values that means that 512 steps of brightness in the range of 0-1024 represents only one stop of brightness. Half of a photosite's raw signal is dedicated to extreme highlights that most of us try to avoid and that usually take up a very small area of the frame.

Raw files tend to result in very pretty graded images, but they also waste a huge amount of storage space.

By the way, this is called linear gamma. When linear gamma is viewed on a Rec 709 monitor it looks really dark, and now you can see why: the midtones are buried way down the curve, making them appear much too dark.

Okay, this is where math comes in. During the linear gamma to log gamma conversion these code values are run through some sort of mathematical equation that redistributes them such that each stop difference in illumination gets the same amount of storage space. I'm not going to say that I know the math involved because I don't--not completely--and if I try to explain it I'll just end up making a fool out of myself. Suffice to say it has something to do with exponents. (See? I told you I'd mention those again.)

Fortunately the graphing program I use has a very interesting feature: a function that turns this linear curve into a logarithmic curve. Clicking that one button turns the graph into this:

That's the exact same data encoded in log format. It's quite different, isn't it? Our hypothetical camera's dynamic range is now captured in perceptually equal steps, roughly how our eyes see the world. Each stop is allocated the same amount of space, and a colorist has easy access to the last bit just before the line runs out at either end. Not all the data from the raw recording is preserved, as it is in this graph; there's no need to save so much extreme raw highlight detail, for example, so a certain amount of that is discarded. What's left is more than enough to count as a digital negative that can be graded just as film can.

Now, manufacturers do mess around a bit with these curves so this explanation isn't a perfect one. For example, when S-Log was first released it had an interesting characteristic, common for a log curve, that the closer a value got to black or white the harder it had to work to get there. This had the result that brightness values almost never ran to the dynamic range limits because the formula just didn't allow them to get there. It's a bit like trying to get somewhere by covering half the distance, then covering half that distance, then covering half that distance again… if you only ever move half the remaining distance to your destination then technically you'll never get there.

Because code values never quite reach the extremes of black and white S-Log looked really flat because normal shadow values in a scene never reached the minimum code number for black. For that reason they looked too bright, or milky. S-Log2 appears to rectify that problem by storing shadow values farther down the curve so that the darkest tone the camera can possibly see is mapped very close to the log curve's minimum recordable value. By making blacks black again the log image actually looks fairly normal on a Rec 709 monitor. The highlights are still crushed because they are heavily compressed by the log curve for grading, but the image otherwise looks "real." It's less likely to cause people to panic when walking by the DIT's monitor.

According to Charles Poynton it's possible to effectively record about 99% of the information contained in a 12-bit raw file in a 10-bit log file. Yes, you're throwing some information away, but do you really need all the highlight information that a raw file records when you'll never use it? You're most likely to throw most of that extra detail away when you roll off the highlights in the grading process. Highlight detail doesn't require that much storage space as highlights are always heavily compressed anyway. Our eyes just don't see that much detail in bright highlights. (There's a brief discussion of how many steps you need to transition from black to white in linear vs. non-linear gamma here.)

That's the short version of what a log curve is and how it works. Raw seems to be the buzzword of the day, and everyone wants to shoot raw for optimal picture quality, but the storage requirements for raw are pretty sobering. Log is a perfectly viable alternative that is much more efficient overall and certainly more post production friendly. There are certain requirements to recording log that are different to recording in raw: for example, you must white balance the camera in log whereas in raw the white balance is encoded in metadata as a changeable option... but any competent cinematographer should be able to white balance a camera.

ADDENDUM: A reader points out that some "raw" cameras create log-encoded raw files, so it's not always as simple as log vs. raw; you have to figure out what kind of raw you're working with. Yay!


Art Adams
Director of Photography
Twitter: @artadams

Editor's Choice
PVC Exclusive
From our Sponsors

Share This

Back To Listings RSS Print

Get articles like this in your inbox: Sign Up


Nick Shaw: | February, 07, 2013

Good Article.

One Comment. You talk about S-Log2 “rectifying” the problem of log images looking milky. I don’t know if that is something Sony did deliberately. S-Log2 is just S-Log with a half stop offset due to the high dynamic range of the F65. This has the side effect of squashing the histogram across to the left a bit, which may make the image look more “normal” on a Rec709 monitor.

Jamie LeJeune: | February, 07, 2013

Fascinating reading. Thanks for doing the math for us!

Have you seen this comparison of the ProRes and raw files produced by the Blackmagic Cinema Camera:

The test compares ProRes Log versus Raw Log (as your updated reader comment mentions) and the difference in highlight recovery is significant to my eye.  Unless I’ve misunderstood the chart in the video, it looks like two stops difference to me. At the very least, there’s definitely more than a 1% difference between the two. Or, am I missing something here?

Gavin Greenwalt: | February, 08, 2013

I think you’ve fallen into the trap of “making it so simple it’s wrong”.

“Raw files tend to result in very pretty graded images, but they also waste a huge amount of storage space.”

Let’s get our terms straight before we proceed since it’s important to make apples to apples comparisons.  By RAW I assume you mean linear bayer pattern raw.  Currently RAW is mostly stored in 12bit or 16bit linear.

When you talk about Log I assume we’re talking about a 10bit RGB log file.

There’s one important variable though that you’re missing.  A RAW file only stores one channel per pixel.  So that’s 12-16bits per pixel.  A Log RGB file stores 3 channels (red, green and blue) so that’s 30 bits per pixel. 

“Raw seems to be the buzzword of the day, and everyone wants to shoot raw for optimal picture quality, but the storage requirements for raw are pretty sobering. “

No they aren’t.  Also if you store a RAW file in a 16bit EXR it’s actually storing the image in log behind the scenes, dedicating 10 bits per stop of linear data and 32 stops of dynamic range along with a postive/negative sign.  With 20 stop cameras on the near horizon 10 bit log is going to be insufficient for all of the data.  You could also store a RAW image in 10bit log if you so desired.  In fact before REDCode for instance was encrypted you could open a redcode frame and see that it wasn’t stored in linear gamma.

Art Adams: | February, 08, 2013

Hi Nick- thanks for the information. Is that really only a half stop difference? It made quite a change in the look, to the point where a DIT can actually look at a real image now.

Hi Jamie- I’m trying to make sense of that test. Two things concern me:

The crossover on the chart was set to 50%. It looks to me as if that chart has the 18% gray background, so true middle gray should be 41.7% (I round down to 40%). That could be compressing highlights a little, although not enough to justify these results.

I also don’t understand the part where it says “ProRes clips were done in 709.” I’m not familiar with that camera… what does that mean? Clearly a Rec 709 curve was applied to both sets of footage, but I don’t know anything about the processing of one verses the other. Unless the Rec 709 processing was done in exactly the same way to both sets of footage (unlikely) there’s the possibility that the Rec 709 curve for ProRes is significantly different…

Without knowing the processing and capturing details I can’t really comment further.

Art Adams: | February, 09, 2013

Hi Gavin- thanks for all that, good stuff.

Hi Jamie- I took another look at that test and it’s hard for me to make sense of what’s going on. I do think it’s interesting to see the color shift on that one chip at T1.3. It would be interesting to see the scopes for a test like that, it’d be easier to see what’s going on.

macgregor: | February, 09, 2013

wonderfull as usual. Just one thing, in a 10bit image, shouldn’t the pure white occupy the value 1023 instead 1024?

Art Adams: | February, 09, 2013

That’s why I added:

“(The actual values are different, but I’m rounding off for simplicity.)”

If you guys are going to start grading my math we’re all doomed. smile I just rounded off as it’s easier to do 1024 to 512 (and, at one point, I still screwed that up).

DEvans: | February, 14, 2013

Really useful thanks.  I’m a little confused as to the line “the graphing program I use has a very interesting feature: a function that turns this linear curve into a logarithmic curve”.  My small brain says its the other way ‘round given the pictures?  Is that right?  Cheers.  DE

Art Adams: | February, 16, 2013

Hi DE- Yes, it can be confusing. Linear just means you’re counting things without applying any special functions: there’s a 1:1 relationship between how many photons hit a photosite and the signal that results from that. If enough photons hit a photosite to create code value 512, then that’s what happens; if a few more hit then that value goes up to 513. As everything in photography has to do with doubles and halves, however, just counting all the photons is not a very efficient way to store data as the difference between code values 16 and 32 is one stop at the lower end of the data set while it’s 512-1024 at the other end.

Log encoding applies a function that stores data in a non-linear way, so that you’re not simply encoding the values that the sensor puts out but you’re remapping them in a way that gives each stop of exposure equal weight. One stop of exposure at the bottom of the curve gets the same amount as at the top of the curve.

Linear doesn’t have to do with the shape of the graph but whether there’s a 1:1 relationship between the data collected and how it is stored. Does that make sense?

Vitor Novaes: | May, 11, 2013

Gavin, you’re making a mistake.

10, 12 or 16 bit means: 2^10; 2^12 and 2^16.

16 bit in one channel per pixel, then, is actually 65536.

10 bit is 1024. 10 bits per channel in three channels isn’t 30 bit per pixel, but only 3 x 1024. So, obviously, 16 bit is far more information then three 10 bit channels per pixel.

SagaTious: | June, 12, 2013

Vitor it’s the information that gets stored in a file. Look at it like this:

You need 16 digits to store a 16bit value (1010101010101010) but to store three 10 bit values you need 30 digits (1010101010, 1010101010, 1010101010). That’s 30bit you’re storing in your file. For every pixel. So I guess Gavin is actually right.
Also you don’t get 3x1024 = 3072 colors out of combining 3 10bit channels but you’ll get 1024^3 = 1073741724 different color-combinations if you mix 3 10bit channels.

Please login or register to comment