@nick your PR has been merged!
After a bunch of wheel spinning at errors, trying to workout why 49 and 50 were both blowing up in my face, I finally realised you guys has switched to Nuke 15.0 (Derp…)
I’ve updated the LUT Repo with new bakes:
This contains the new 50, and revised 48.
The new OCIO Config template uses the 709 LUT for the 709 Limited P3D65, which massivly improves the inversion.
Currently this is only in the OCIO version. I’ll need to look at the Resolve DCTLs seperately.
Ah yes. Sorry if that messed you up. My laptop and desktop here are both Apple Silicon, so native support in Nuke 15 makes a big difference to me. Is something particular required when saving scripts from v15 to ensure backward compatibility?
@alexfry @Thomas_Mansencal (viz) @here
Sorry for the probably excessive ping, but I want to notify interested parties that Dr. Luke Hellwig has just defended his dissertation with additional work on CAM. It’a well worth testing.
lhCAM23 is not tested or modeled on HDR luminance ranges, so there may be strange behaviors there. In his defense he mentioned that they are actively pursuing future work on this, as well as on understanding local adaptation and image context (iCAM extensions possible in the future)
Also just saw our man @luke.hellwig got some prime time recognition in this recent Linus Tech Tips video!
For those playing along at home, I’ve just uploaded a v052 with should have the latest changes from @priikone @KevinJW @nick and myself.
Blink for Nuke:
Along with LUT bakes:
This is a recap of the gamut mapper issue in CAM DRT v052 talked about in the past couple meetings.
The basic issue is that with the current gamut mapping implementation it is not possible to change the projection angle to a steeper one, in order to better preserve highly saturated colors in the highlights in SDR, without introducing issues with gradients.
Important to point out up front that this issue is not related to the reach mapper or how far out the gamut mapper reaches in compression. The same issue happens also in non-reach mode.
Following images are ramps of Rec.709, P3, Rec.2020, AP1, AP0 and AWG inputs, in CAM DRT v052 with focus distance value set to 1.0 for a steeper projection. This is a way to clearly demonstrate the issue:
What we’re seeing here is that not all of the mapped hues have proper path-to-white. All colors are mapped within Rec.709 gamut, but only the Rec.709 input seems to have path-to-white for all the hues. All other examples show that some or most of the hues instead clip to white.
This happens because the quadratic used in the computations doesn’t have the ability to smoothly change the projection from a steeper angle to a more horizontal angle as it approaches display white (and black), as shown in the example slope plot below.
No path-to-white:
Smoother path-to-white:
Here is an example rendering of the above ramp image with a mapper that always has a path-to-white for any input value. This is the experimental version of the AP1 reach mapper:
Here’s one example of the implications of not having path-to-white (focus distance 1.0):
As far as I can see, there’s few things that can be done about this:
Do nothing, and set the focus distance to a high enough value (near horizontal projection) so that the slope hits the display white with shallow enough angle so that visually everything looks to have smooth path-to-white. This is the current approach. The downside is that highly saturated colors will lose saturation very quickly in SDR. The current value in v052 was picked to have visually smooth path-to-white in AP1, but AP0 and beyond shows clipping.
Go back to the old mapper we have which has smooth path-to-white for any input value. This mapper doesn’t use the quadratic approach. A reach version of that mapper can be done the same way as the current one. The downside is that the inverse will become an approximation. This mapper would have no limitations on how steep the projection is, it would always have smooth path-to-white, regardless of the input value.
Perhaps a separate path-to-white step after the gamut mapper could be added, but it sounds hacky.
This looks rather like it might shred to bits on pictures formed from tristimulus colourimetry that have transparent with reflected sheens or sharp reflections in it.
I have a very strong inclination that testing tristimulus data with an attempt to express this sort of spatiotemporal articulation will reveal the rate of change along the purity dimension as being too slow. The tests, I suspect, will reveal a cognition of the “things behind” the reflective surface as “punching through”.
Just a hunch, but I’ll put a coffee bet on it.
One thing I tried experimenting with when I saw the shape of your desmos plots was using a cosine raised to a power to create a “hat” weighting function for the current mapper, i.e. a function that is mostly 1 but falls off rapidly but smoothly near 0 and 1, unfortunately I lost my experiment as I forgot to save the desmos. but I’ll try have another go later today, if I have the time.
Something akin to this …
Where p controls the transition from 0 to 1 in the weight, so may need scaling depending on the Jmax value
I think that as soon as you start modifying the slope function in the current mapper, you might as well go back to the earlier non-analytically-invertible version with slope as a function of source J and M, as @priikone has proposed.
The purpose of the slope in the current mapper being based on the J intersect only is so you can solve for a J intersect value which passes through (M, J) and hence will lead to the same solution for any compressed (M, J) values which lie along that same line. That’s what creates the invertibility, by leading to the same J intersect (and hence slope) before and after compression, but it also imposes constraints. If the constraints are problematic, we need a different approach.
I don’t believe a slope function modified in this way will lead to a simple formula solution for the J intersect. And if the solve needs to be iterative, we are back where we started!
It wouldn’t be exactly where we started. In the start we didn’t have reach mapper and the forward direction had iterative boundary finding as well.
It would a reach mapper with approximation for the boundary in the forward direction (like it is now), and the iteration for approximation (if non-iterative isn’t possible), would be only in the inverse direction.
Hello, ACES team! Thank you for all your hard work and very interesting discussions.
I’ve seen in the project plan that Release Candidate 2 should be ready by January 15. Is the latest version the release candidate?
And will the developer release start at the beginning of the February?
@FedorDoc We are currently testing with colorists, vfx artists, etc. and would be happy to get you transforms if you’re interested in giving the latest output transform candidates a try. We are still targeting February for the develop release start and are working with key implementation partners (e.g. OCIO) to get them what they need based on their release schedules.
I’m a colorist and I work in DaVinci Resolve. I was playing with v052 in Fusion (I got it from here). I have not encountered major bugs yet, but I have not tried to grade a project underneath new DRT.
Is there a specific bug report topic on the forum? How bug report should be formatted? Is there any specific information that should always be included in the report?
I would be happy to help!
Hey @FedorDoc
We did have a formal feedback form when we were testing multiple candidates, but that’s a bit out of date now.
Best place it probably just here in this thread.
Please include as much context as you feel comfortable with, and example images highlighting any specific problematic areas (where possible).
Always looking for additional real world feedback.
I pushed CAM DRT v053-pex2 experimental version to my repo. It brings:
Rec.709 BT.1886 inverse round-trip:
Here’s two images comparing the Rec.709 BT.1886 inverse difference to CMSTestPattern. First image is the default mapper and the second is the experimental mapper, all else being equal. The images have been gamma-upped to show the differences:
v053-pex2:
In ACES OT VWG Sample Frame #21 the leather furniture appears more greenish in HDR and more reddish in SDR (tested with Nick Shaw’s v52 DCTLs on the same monitor and “Encode as BT.2100 PQ” ticked). It would be nice if someone could check this because I’m not sure how much I can trust my monitor.
I pushed CAM DRT v053-pex3 experimental version to my repo with a small update.
It is otherwise same as v053-pex2 but the threshold at which the focus gain gets applied is now determined by a blend of cusp J and limitJmax. The inverse is analytic below that threshold and approximation above it. The result is now that most of the transform is analytically invertible.
Here’s the same images of Rec.709 BT.1886 inverse round-trip difference to CMSTestPattern. First image is the default mapper, second the new mapper, all else being equal.
v053-pex3 default mapper:
It looks like there’s no difference between them, but there are. They’re just insignificant and not visible in these gamma-upped images.
Edit: v053-pex4 is out with one change. Based on testing SDR/HDR appearance match I decided to add scaling of the focusDistance value. The projection gets slightly less steep as peak luminance goes higher which makes the match better. Without that the mapping in HDR is a bit dark… It can be toggled on and off (with disableFocusDistScaling in kernel params).
I’m not seeing that with my DCTL (or the Blink). But I don’t have a reference monitor. I am only looking on the XDR display of my MacBook Pro.
But the DRT should not alter hue. None of the HDR or SDR processing alters the h value in the (modified) Hellwig JMh working space.
Unfortuntely something in this latest update (pex3 and pex4) stops it from compiling under macOS on Intel.
OpenCL returned error (-5)
EDIT:
Turns out it’s compiling file. But my GPU doesn’t like running the larger 2880 entry long hue tables (360*8).
Reverting back to 360 gets it going.
