How to export to DPX (or Cineon)

[bnw]

I see confusion everywhere 🙂

Kodak could have used a gamma function to achieve the same thing, but I think they went with log because it tied in nicely with existing sensitometry. People have been using density-log-exposure curves since Victorian times. It’s nothing to do with the film response, which is actually measured as a continuously varying gamma function. Log was just for convenient graphing of the transfer function, but whatcha know, it’s a reasonable match for our perceptual luminance response so it works for compression too 🙂

I’m sure you’re right about the laser taking linear data in the end, but it’s all beside the point, really – as long as you maintain enough dynamic range through your various log-linear and LUT conversions, you’ll get a good result. Seems to me that what the facility is used to accepting into their pipeline is more important, and that’s usually log. You’re more likely to have problems through giving the operator something they don’t expect than from 10-bit mach banding or whatever…

Woo, old Navy photographic training manuals! http://www.tpub.com/content/photography/14208/css/14208_41.htm

[Barbara Mills]

You’re more likely to have problems through giving the operator something they don’t expect than from 10-bit mach banding or whatever…

My point was, at the beginning, that log conversion is not so important for printers as people usually think. I live far, far away from Hollywood but two facilities I work with for years always have given me an option to work in Lin. As I work inside shake in Lin, I don’t bother with conversion to log at the end. The only thing I need to know is their top-secret experienced proven LUT 😉

I think we have an agreement ;).

cheers!
sy.

[Gregory Hill]

Without wanting to stir up the situation any more than it already is 😛 I’d like to add that since my original post, I’ve been working quite a bit with film and now understand the situation way more (steve wright’s digital compositing for film and video really does a great job of explaining it all!).

I agree that 10bit log files are not necessarily needed for printing to film. What is needed is, whatever they want! In my case I was working with Framestore CFC here in the UK and they specifically requested 10bit log DPX to put into their baselight8 and use together with other rushes. Using 16bit linear or 32bit float was out of the question.

But I have to say, that linked article is really misleading and quite wrong! Loops has pointed these out, but I just wanna emphasize them in case someone stumbles across this thread intending to learn something and is mislead!

Quote:

This means that 24 bit RGB color space can describe 8 bits of each RGB, or 256*256*256 variations of color, or 16.7 million different values.

But don’t assume that the 16.7 million colors are a sampling of the entire spectrum of color; you could choose to have 16 million shades of red, and the remainder in shades of blue. This wouldn’t buy you a very nice photorealistic image, but if you were really keen on red and blue, you would have some gorgeous tones.

That is just plain wrong!
24 bit RGB means 8bits per channel, especially if you say ‘can describe 8 bits of each RGB’. That means 8 bits for red, 8 bits for green, and 8 bits for blue – and then any combination. So you only have 256 (2^8) shades of red, not more. You COULD devise a custom storage system using 24bits to store 22bits of red and 2 bits of blue, but that is NOT 24bit RGB; that would be your custom storage system, and your 24bit RGB display would not be able to display it correctly.

Quote:

in the log color space, more bits are used to focus on the dark and light colors, with fewer spent on the midrange.

That is quite inaccurate too. You could say more bits are used to focus on the dark areas… BUT less is used for the bright bits, NOT MORE! However due to the nature of the log storage system, you can store information on the ‘superbright’ areas, which in a linear scale would normally be cropped. If thats what the author means then it is very badly worded.

To clarify a few points (not necessarily to those discussing this thread, but others reading trying to not get confused):

The important thing to understand why the 10bit log was developed, is for data efficiency. To be able to store as accurate information as possible, in as little space as possible. 16bit linear is NOT more precise than 10bit log. It is more precise in the bright areas, but it is less precise in the dark areas. And the amount of precision it has in the bright areas is unnecessarily high, too high for the human eye to even notice – and the reason for this is due to the eye’s perception of brightness – which is logarithmic – the brighter something is, the less sensitive the eye is too it – and interestingly, the same goes for film.

E.g. create a standard 8bit image in photoshop. Draw 2 boxes side by side, one with brightness 5 (out of 255), one with brightness 10 (out of 255). You can easily tell the difference. Now create a box with brightness 245, and one with 250. The difference is much less obvious, even though the difference in brightness is the same – 5/255. But in the first case the brightness of one box is double that of the other (10/5 = 2; 100% brighter), whereas in the second example the brightness RATIO between the two is quite low (250/245 = 1.02; 2% brighter)- and thats how the sensitivity of the eye (and film) works – its proportional to the RATIO of two brightness values and NOT to the DIFFERENCE of the values – and that implies a logarithmic scale.

The rule of thumb is that the eye can tell the difference of any brightness difference 1% or more. Less than 1% and it cant differentiate anymore.

While the eye cannot differentiate values at the high end of 8bit (e.g. 241, 240 => 0.41% brightness ratio), it can easily see the differences at the low end (50, 51 => 2%) which is why 8bit linear is no good and banding appears in the dark areas. 16bit linear takes care of that problem to some level, it has enough precision in one unit change of brightness (1/65536) to have no banding in most dark areas, BUT in the high areas there is way too much precision – so its not a very efficient way of storing the information – and thats where the log storage comes in, effectively the data is stored not by the difference between brightness values but by ratio of successive brighness values.

Without going into any more boring detail, by using 10bit log (2^10 = 1024 levels to measure brightness) each successive brightness value implies 0.67% change in brightness – and thats mapped to a dynamic range of 1000:1 (another advantage of log over lin, the ability to have super bright and super black): 0/1023 is mapped to black (brightness:0, nothing is ever really this black in the real world), roughly 700/1023 (685 to be precise) is mapped to bright (but not specular) white, and 1023/1023 is mapped to very bloody bright e.g. sun reflections etc. (brightness: 1000).

So all that range can be stored (from super black to super bright), with only 0.67% brightness difference between the closest two colors – and in only 10 bits (~40% less storage and bandwidth than 16bits, which has less precision in the dark, and cannot deal with super brights – or if it does deal with super brights, it would lose way too much precision in the normal exposure range) – and thats primarily why 10bit log is the most common way to scan and work with film.

P.S. I’m a bit drunk, so if theres anything wrong here I’ll try and correct it in the morning 😛

[bnw]

memo;24005 wrote:

the eye’s perception of brightness – which is logarithmic – the brighter something is, the less sensitive the eye is too it – and interestingly, the same goes for film.

True up in the shoulder region, where highlights roll off gently, but the region around mid-grey is actually pretty darned linear. Otherwise we couldn’t be going back to linear in Shake or similar and getting more or less photometrically linear data. A nitpick I know 🙂

Otherwise excellent post, sir! Comforting to know people out there actually do understand this stuff!

[Barbara Mills]

Great post! I agree in 100% (in log) and found some nice bit of highlights to remember ;)!

cheers,
sy.

[Sinan]

Great post Mehmet,
I also explained to people time to time, that 10bit log is not a bad thing. Especially when compositing, it causes lots of trouble, convert to lin, comp layers, back to log… Seems to have lots of trouble, and it seems that, they hate it. But log is a very efficient way of representing the film in a digital environment. If you ask me, even digital display devices should work that way (Ofcourse when they have the contrast ratio of 35mm positive) Everything in computer world is linear images, with crt gamma now. That is just because it was the easiest way to implement a ramdac. Maybe even gfx card manufacturers should think about using log space in terms of signals. That will solve the banding issue in 24 bit RGB. Even 8 bit log would be a better thing.

I know, the linear approach was quick solution for 320×200 CGA 4 color displays in 1980s, but now, everybody watches film from their computers. Plays photo realistic games with the PC. And now there are some newer type displays, which have really good contrast ratio.

Maybe, now it is the time for computer gfx world, to think more about log images…

[Author]

Posts