Howdy all - first off, congrats on ACES 2.0! It’s a great improvement and an impressive accomplishment.
I’ve read that ACES 2.0 is truly “invertible” now, so I wanted to check in to see what the preferred workflow is. Is it fine to slap an sRGB - Display on a PNG or JPG or is there more to it?
Thanks!
Any insights into this? Thanks!
Yes, the Inverse Output Transform for sRGB should work quite well in v2.
Just remember that the Inverse does not claim to revert an output referred image back to what would have been its original scene ACES colorimetry. It is simply deriving ACES values that, when put through the forward again, will result in the same image. Sometimes the inverse might result in what may seem like weirdly shaped data and thus might not “grade” as normally expected. But for the use case of matching a look already established in an output space, it is believed that it should function quite well.
The inverse is tested via a round-trip, meaning that:
“output referred image” > Inv > “quasi-ACES” > Fwd > “output referred round trip”
At some of the more extreme dynamic ranges and gamuts, the behavior isn’t perfect all the way out to the extremes, but it was intended to work nearly perfectly at least to P3 and up to 1000-nit peak luminance.
In v1, some edge values (mostly in the yellow corner) compromised.
In v2, the roundtrip image matches the original image. See the examples below.
Here is an image depicting the faces of an code value cube.
Through the v1.x Inv followed by the Fwd, we lose saturation in the yellow hues at left above the split.
Through the v2 Inv followed by the Fwd, the image matches the original.
Thanks for the great info, Scott. I checked out that test image in ACES 2.0 and 1.3 on my system and I see precisely the difference you describe. So nice to have a worry-free solution for this now!
