OK, so the main thing I’ve been thinking about lately is how to deal with the fact ZCAM doesn’t know or care about your display gamut, and therefore is throwing values all over the place as you move things up and down.
The animated gif below shows the same ramp used above:
x = -180 → 180 in h
y = 0 → 100nits in J
And time is running from 0 → 100 in M
Anytime any channel in sRGB drops below 0, or goes above 1, I’m flipping to black.
Once I have this, I’m doing a looping Over operation (1024 steps) to build up an image that contains the maxium M value for any J and h combination (under 100nits). Which gives me an image that looks like this:
So despite being stored as J,M,h values, when visualed in 3D (flipped back into sRGB), this forms a limit cube.
So now I have an image that effectivly stores the max M value for any given J/h combination:
I can treat it as a 2D LUT, and take something like this image, which is 0->100nits, with an M of 33
And do a soft clip of the M channel, based on the max M availible in the sRGB volume.
Now this soft clip is currently pretty crude, but it does do the main two things I want, which is deal with the negs down on the bottom left, and the big excursions above 1.0 when I ask for M values of 33 at 100nits (which clearly isn’t possible).
The approch I’ve taken here is clearly not suitable for real-time work. But I’m just trying to make it work for now
So now the flow looks like this:
ACES → XYZ → ZCAM → Apply SSTS style 1D curve to J → softclip M to sRGB gamut boundry → convert to XYZ → sRGB → inverse EOTF
Below are a series of images showing how it all adds up.
ZCAMishDRT - OpenDRT - ACES 1.2
3 Stops down
Normal exposure
5 Stops up
Results are a mixed bag, some wins, some losses. But interesting none the less.
ACESCentral seems to be scaling them down, so the full rez ones can be found here:
