I would like to share a few updates on my end. As a personal exercise for myself, I have developed a LMT for ACES 1.3. It is available for free on my Git with an OCIO config.
My main goal was to develop a pleasing and natural look for ACES 1.3 by tweaking purity, brilliance and hue shifts:
Reduce overall contrast of ACES 1.X
Avoid clipping as much as possible to ensure “smooth” gradients
Improve purity attenuation to avoid passing g0 threshold
I was overall pleased with the result and I thought that maybe such an LMT would be useful for CG students or freelance colorists as a starting point. I have put all my love for beautiful pictures and movies in this LMT, although I would easily admit it is far from perfect.
To perform this look development as best as I could, I looked at hundreds of images (both live-action and CG) and compared against several picture formations to avoid visual adaptation.
A bit like the ARRI Film Lab (where they mention that “the grain profiles were not designed to perfectly emulate a specific stock but instead represent a look that is characteristic of many different styles of stocks […]”), I have put a bit of all the picture formations that I like in this LMT (JP2499, openDRT, High Contrast Venice 2 LUT from Picture Shop…).
Here are some visual examples (ACES 1.3 with RGC and ACES 1.3 with my LMT) :
I would love to get some feedback about the LMT if possible. If you want to use it in Resolve, it needs to be applied on “Tlog_Egamut2”. I could not find a proper shaper space within the ACES family (happy to also hear some thoughts about this).
I think my next step is to try the same exercise for ACES 2.0, although I can already share that I struggled much more than ACES 1.X on my preliminary tests. Could it be because ACES 1.X is at its core a “simple” Matrix 3x3 and an s-curve (per-channel/RGB tonescale) when ACES 2.0 is a much more complex model (CAM and such) ? I would love to hear from anyone who had experience with this.
I experienced similar difficulties in the context of grading a single shot, where at a certain threshold the data sort of gets vacuumed into the blue corner and the only way to stay away from it would be to reduce saturation and/or luminance by such an amount that you either end up with a muted image, or drop the luminance enough that you’re just enough under the top side of the volume in the blue area if that makes sense. Both solutions weren’t ideal imo as they were very sensitive to fail again with subsequent grading decisions like upping the exposure for example.
I understand grading operations tend to be much more coarse and/or local compared to algorithms for continuous smooth adjustments but I can understand similar issues are encountered along the way as you’re still underneath the DRT in the process and thus potentially limited by it’s mechanisms and it’s in the case of ACES fixed parameters.
unfortunately I was not able to investigate the issue further. But I will, once I have some more free time. It’s also a good opportunity to test Blender 5.0 with the new combined ACES 1.3, 2.0 and AgX ocio config.
This is exactly what I have experienced with blues. I am tweaking them in every possible way and somehow I cannot find a way to make them look “right”. Like if I was fighting the picture formation or something.
You actually can see it very clearly in this example:
This image is like the killer stress test for picture formation and it has helped me a lot in the past months to evaluate things.
And yes I agree with you. I see look development as a grading pass where we try to develop the aesthetics of a project at a more global level. Mine is very generic because I am merely trying to make things look a bit more natural and pleasing out-of-the-box.
I am worried that now ACES 2.0 has been implemented basically everywhere (Nuke, Resolve, Blender…), we have to deal with pink salmon fires for the next ten years. But maybe I am just worrying too much.
