Quick PSA:

Because this seems to come up all the time, just want to write down the reason why you should not put log encoded images into a floating point codec like openEXR .

The difference between floating point and integer based codecs is basically:

Integer saves data as “full values”, for 10bit that is 1024 different values per color channel. We can say that in this case data gets saved in a linear fashion. So if we save something thats logarithmically distributed into a integer format, we are distributing the bits more efficiently, in linear - HALF of all possible values are taken up by the last stop of light.

In most comp systems that work floating point under the hood, you can have values that are above the max value 1023 also reffered to as “1” as in “full” in regards to whatever bitdepth you are writing to, this can lead a clipped values, so logarithmic encoding squeezes all those linear input values back into 0-1 or 0-1023.

Floating point on the other hand is built very differently, data is not saved linearly but inherently logarithmic under the hood, the higher the values go, the less precise it is (you can read a bunch of papers on half vs float and how it work with mantissa bits and all that jazz… ill keep it simple here)

It can save values that go way beyond 1, as again its just like log encoding but smarter.

This can also give you funky issues , when you do a simulation in houdini and are too far away from origin, the precision of distance calculations goes down so much you get awful results.

So but what does this all mean for us?

This means that saving Log (logC, acesCCT, slog3 or whatever) data in a EXR is a bad idea, 12bit integer has more precision when it comes to logarithmic data than a 16bit float EXR.

But where is the proof?

I made a 32bit floating point ramp from 0-55 , this matches the dynamic range of a arri alexa, I then converted that to logCv3(all in 32bit float domain) and rendered it out as 10/12/16bit integer and 16/32bit float.

I then heavily graded the ramp to exeggerate the banding on each:

Do try this yourself in your software of choice, i have done this exact thing in flame before as well, its the same thing.

I do believe that if you work with graded SDR material encoding stuff as EXRs is, while a bit dirty not the worst choice ever, espeically for a 10bit or even 8bit delivery, Personally id still linearlize the rec709 but thats just me and my opinion that for interoperability putting anything other than linear data into a EXR is bad practice.

10bit integer

12bit integer

16bit float

16bit integer

32bit float

Q: Ok cool, but whats the fix, if we want to have log data saved in a frame based format that offers losless compression?

A: Convert it to linear and then back on import