This came out on June 10… maybe a paper on ACES2 would be in order.
Note that comparisons are made to “ACES”, not noting which version.
Most likely ACES 1.X. I kinda recognize the patterns.
My tuppence,
Chris
The article says "Also, because ARRI’s earlier color space, AWG3, is larger than ACES AP0, original ALEXA footage sometimes clips in the blue region when mapped into ACES. " using these side-by-side images:
These images are taken from this article on Aces Central.
which says at the very top “ACES 1.3 introduces a new and improved solution to this issue with a Gamut Compression LMT.”
That this is not mentioned in the article strikes me as a notable oversight.
Saying that makes it sound as if the IDT can clip AWG3 data, which is not true. Some AWG3 values will be transformed to have negative AP0 values, but they are not clipped at that point. The potential clipping, and resulting artefacts, occurs in the ACES 1.x Output Transform. And as @Derek and @ChrisBrejon point out, the RGC and ACES 2.0 renderings improve that situation.
I don’t think that article adds much to the original ARRI article it appears to be based on. And not all that it adds is strictly accurate.
Strictly what the Custom Colour Management gives you is the option NOT to use REVEAL processing, or at least not the DRT part of it, which is where the majority of the look comes from.
1 Like
Following on from discussion in the last meeting, I have been experimenting with code to procedurally generate Transform IDs.
Coding it forces you to think how the logic should work, and raises issues like how to deal with non-standard settings. It also made me wonder about whether some of the naming which is currently implicit should perhaps be more explicit. E.g. <ACEStransformID>urn:ampas:aces:transformId:v2.0:Output.Academy.P3D65.a2.v1</ACEStransformID> is implicitly 2.6 gamma. But should that be explicit in the ID?