Back To Listings RSS Print

The Not-So-Technical Guide to S-Log and Log Gamma Curves

What you need to know about log curves--with hardly any math at all

By Art Adams | February 03, 2009

For a couple of weeks I've been researching the mystery of Sony S-Log, and log curves in general, trying to determine what they are, what they do, and whether they are a good thing or not. After interviewing three different people (George Palmer of HDPix, Michael Bravin of BandPro and especially Steve Shaw of Digital Praxis) I finally had a sartori. I get it now. It's really cool. And it's surprisingly simple.


I've written before about how advanced gamma curves of any sort are intended to fit up to 12+ stops into the five stop bucket specified in the Rec 709 HD standard. While the other curves built into the F35 and F23 are basically what-you-see-is-what-you-get curves, S-Log is the only one that's not. At first I had a hard time getting my head around the math of how S-Log is storing bits until Steve Shaw helped me see that it's all about working with Mother Nature.

An image sensor sees light one way: linearly. It simply counts photons. A 14-bit sensor, with 16,384 steps per channel, will distribute brightness this way:

16,384: totally saturated sensor (maximum white)
8,192-16,383: First stop down from maximum white
4,096-8,191: Second stop down from maximum white
2,048-4,095: Third stop down from maximum white
1,024-2,047: Fourth stop down from maximum white
512-1,023: Fifth stop down from maximum white
256-511: Sixth stop down from maximum white
128-255: Seventh stop down from maximum white
64-127: Eighth stop down from maximum white
32-63: Ninth stop down from maximum white
16-31: Tenth stop down from maximum white
8-15: Eleventh stop down from maximum white
4-7: Twelfth stop down from maximum white
2-6: Thirteenth stop down from maximum white
1-2: Fourteenth stop down from maximum white

As you can see, the first four stops of dynamic range get an enormous number of storage bits--and that's just about when we hit middle gray. This is the origin of the "expose to the right" school of thought for "raw" cameras: if you expose to the right of the histogram you are cramming as much information as possible into those upper few stops that contain the most steps of brightness. As we get toward the bottom of the dynamic range there are fewer steps to record each change in brightness, and we're also a lot closer to the noise floor.

The solution to this strange state of affairs continues on page two…

Page 1 of 5 pages 1 2 3 4 5 Next »

Editor's Choice
PVC Exclusive
From our Sponsors

Share This

Back To Listings RSS Print

Get articles like this in your inbox: Sign Up


Charles Angus: | February, 01, 2009

You say that the origin of ETTR is in wanting to encode data more precisely.

I don’t know about the origins of ETTR, but I would say the main advantage of ETTR is not increased precision, but decreased noise (because darker areas are noisier on digital cameras).

Steve Shaw: | February, 04, 2009

The best way to think of exposing digital cinematography cameras is to think of them as being like reversal film stock… Make any sense with respect to ETTR?

The problem with digital cameras is they can clip too harshly, so make sure highlight exposure is correct, and almost let shadow detail fall where it will, adding fill lighting as required.

The extended range gamma curves described here help by maximising the range available, so putting off the clip (saturation) point.

billS: | February, 06, 2009

good article!

createbmx: | January, 21, 2010

Hey Art!
Thanks for the Article.

I have to say that one thing that really bugs me is the inconsistency in definitions/understandings of all this business.

After reading a thread on CML and thinking that I “got it”, I saw people chime in on the thread and disagree with the person who basically schooled everyone.

Where do we draw the line? (or the curve)? Who is to believe?

When is this information going to be widely available, and in layman’s terms? It becomes increasingly frustrating to try and figure out the magic of a camera, and waste your energy on doing so, instead of creating good work.

How can someone like me visualize the differences in Linear/log, instead of reading it? After all, most of us behind the camera don’t react to something emotionally till we visualize it…

Thank you for the article. I will have to read it a few more times to have everything sink in.


Art Adams: | January, 21, 2010

I should probably work on making it a lot simpler to understand. Here’s the bottom line:

Linear records ALL the data off the sensor, but the way the sensor records information it saves much more highlight info than shadow info. 50% of linear data describes detail in your brightest highlights… which is a complete waste, because you don’t often have much in the way of bright detailed highlights in the shot.

Log remaps these values when they are stored so that you only record perceptually equal steps (steps that your eye can see the difference in)  instead of every bit of data in linear, which records tons more info in highlights than the eye can see.

Linear gamma looks really dark. It must have a gamma curve applied to it to make it look proper on a CRT or LCD display. In raw form it contains every bit the sensor captured.

Log gamma looks really flat. It doesn’t contain nearly as much data as linear gamma but most of the time that’s okay, because it records brightness in perceptually equal steps and doesn’t favor either highlights or shadows.

Both should offer excellent results, depending on the post house. RED’s “raw” isn’t really linear raw because it has a slightly different gamma curve applied, but it’s pretty close and it is 12-bit color (although heavily compressed). S-Log is only 10-bit color, but that seems to be fine as it hasn’t hobbled the numerous TV shows and features shot that way.

12-bit linear has close to 4096 possible steps of brightness per color channel. (Some bits at the top and bottom are reserved for meta data.) This is linear data so half of this goes immediately to the brightest highlight details. Not very efficient.

10-bit log has close to 1024 steps of brightness per color channel. (Some bits are reserved here as well, so the entire range isn’t used for image data.) The brightness values are spread out much more evenly than linear, though.

I’m not going to say I understand it all well enough to lay out all the definitions and be right on every one. I’ve got an overall idea of how all this is supposed to work. The bottom line is that both methods work fine as long as your post house is competent.

The one thing you don’t want to do is have a post pipeline where the footage drops down to 8-bits. That looks really nasty, and can happen when dealing with Final Cut Pro or if the footage gets dumped to HDCAM at some point. The banding and color noise are horrible.

Please login or register to comment