Aces/Academy IFF signal workflow

[Nick Shaw]

Suffice it to say that I had the same concern at first, but after seeing quite a bit of footage, I would say that the concern proved a bit unfounded.

Thanks Mike. I guess I need to to see it in action for myself.

All the pushing and pulling in the 3D luts really is not good as 3D luts are lossy by the nature of their imprecision.

How imprecise does depend on the mesh size of the 3D LUT, but when the input to a 3D LUT is linear to light you need a very large mesh to maintain precision and preferably a logarithmically spaced mesh. I do not know the details of the IIF implementation. Can somebody who does know comment on this?

As long as the fileformat bitdepth exceeds what is available from the camera (in r1s case 12 bit linearlight vs 16 bit float) the only thing which is baked in is the debayereing...

But 16 bit half float only has 11 bits of precision, the rest being used for the exponent.

 

[M Most]

How imprecise does depend on the mesh size of the 3D LUT, but when the input to a 3D LUT is linear to light you need a very large mesh to maintain precision and preferably a logarithmically spaced mesh. I do not know the details of the IIF implementation. Can somebody who does know comment on this?

In many, if not most current implementations, LUTs are not really what's being used, and in almost no case is a linear light interpretation being fed to one. IDTs are primarily implemented as transforms, not LUTs. Same with the ODT. The RRT is a set of rather complex mathematical transformations as well. A 3D LUT is only used when a transform is unavailable, as might be the case for, say, a viewing path in a compositing program. In Baselight, for instance, the system is implemented as a combination of Truelight profiles, which specify various parameters and matrix transforms. Just because it's being done with Truelight doesn't mean it's being done as a 3D LUT.

You also mentioned the half float file format. The file format is an exchange mechanism, not a primary part of the system. Unless you need to exchange ACES data with another program or facility, you would likely never use the file format. You would feed the original image into an IDT directly, manipulate the color in ACES space while monitoring through the RRT/ODT, and render through the appropriate path for the deliverables you need to create. Many people have concentrated on the file format, but it reality, it will likely prove to be the least used part of the specification. IIF/ACES is a color management system that happens to include an exchange file format, not the other way around.

 

[Gunleik Groven]

Thanks Nick and Mike. Very good info!

So... how does this relate to Sonys claim the F65 records 16 bit precission RAW?
Actually (refraining from speculative statement... )