While I have used ACES from time to time I never quite fully understood what necessitates the need for IDTs. I skimmed over the IDT documentation a bit but many things are outside my knowledge.
So I have some thoughts and questions that you can hopefully answer in an easy understandable manner.
As I understand currently, vendors are requested/required to provide IDTs to be part of ACES. But what makes an IDT different from data coming from a published white paper on their camera log encoding? If they are different, what justifies or necessitates such differences?
I believe some log encoding white papers provide matrices to XYZ and to ACES (AP0). Would there be possible differences as well? If matrices for XYZ are always created, do we theoretically not need only a conversion from XYZ to AP0?
In the very first section of the IDT document you read:
Camera system vendors are recommended to provide two IDTs for each product, one optimized for CIE Illuminant D55 (daylight) and a second optimized for the ISO 7589 Studio Tungsten illuminant.
Is anyone even doing that? I only recall Canon having camera specific IDTs and tungsten versions but were eventually merged to single D55 IDTs per log encoding and cinema gamut only no? (for practical reason?)
What are potential issues when an application provides an ‘ACES’ workflow but has it’s own fixed generalized color management in place that doesn’t replace it’s transforms with IDTs if ACES is used as display rendering? Or if the user does it manually, like using CSTs in Resolve for instance (with the expectancy that the same white point adaptation model is chosen).
In general vendor supplied IDTs are simply a CTL implementation of the maths from their published white papers. They are not different.
In theory an IDT could incorporate an exposure offset to standardise exposure between cameras from different manufacturers, as there is a degree of choice in the placement of mid grey in the manufacturers’ log encodings. However I am not aware of any published IDT where this has been done.
The IDT documentation describes the process for creating a transform from raw sensor RGB to ACES, and this necessitates use of a different matrix for different illuminants. However in most use cases the IDT is transforming not from sensor native but from a manufacturer’s encoding of the sensor data, such as ARRI LogC3. In this case an illuminant specific matrix has already been applied as part of the encoding, so only one IDT is needed to transform to ACES.
The only real variation is in the choice of Chromatic Adaptation Transform. Manufacturers usually use the same CAT for matrices in their white papers and published IDTs. This has been discussed in detail in another thread, but allowing manufacturers a free choice of CAT means that there is a small difference between the result of going e.g. directly from ARRI Wide Gamut 3 to RED Wide Gamut, and going AWG3 → AP0 → RWG, because both camera spaces use D65, so no CAT is needed for a direct conversion, but going to ACES and back uses a different CAT in each direction.
That’s something I wasn’t yet aware of and clarifies some confusion.
Yea that makes sense. I imagine that for most productions this is mostly a negligible numerical mismatch issue if it comes up, rather than visually clearly different?
The choice of free CAT space is problematic I think, because the CAT space is the actual connection space of a colour space conversion for all practical purpose.
Luckily the differences are small but conceptually I would like to see the fixed at some point in the future.
Also none of the current options of CAT spaces are really great choice for none colourimetric data from cameras.