Something to discuss in our next meeting.
I’m not sure about activating an LMT by default. I feel the all blue grade is quite an extreme edge case. Most people seem to agree that for “normal” images the rendering does “look good out of the box” in a fairly neutral way that they can then impose a preferred look on.
In fact, I just did a quick test, and the current RGC smooths out the artefacts on the all blue image quite significantly. So we already have something available.
During development I also expressed certain doubt about the blue region. I did some testing again in conjunction with @nick 's Jmh compress DCTL for Resolve and came to the following findings.
The most interesting I found was that ACES2.0 remains highly hue linear and reaches the blue primary but a smooth transition seems impossible and variant depending on the gradient of the source image. To get a better perceptual result I felt you need a bend to cyan and less luminance preservation for the higher exposure to smoothen the otherwise fast change.
Here’s a version I graded with the ACES2 OT rc1 DCTL disabling it’s Gamut Compress and using the Jmh compress DCTL + grading instead. I couldn’t push it further because then the information still sort of folds before nearing the boundary.
I also think this will still be a thing for ACES2 for blue region mostly. Hopefully future ACES development removes this necessity and still has a way to reach the corners for sake of inversions. Maybe LMTs need to be more a (default) thing and more easily accessible in apps that support ACES. It feels like gamut compression inside a DRT that also requires to provide a full inverse is too challenging. If design wise it can be fully separate, the design of the compressor itself can also be made without the limitations inversion imposes. It would mean only 1 gamut compressor can be present in the chain rather than needing to add a second RGC one which is potentially a lot smoother with less compression?
In context of OCIO based apps I think having Look+ViewTransform+DisplayDevice by default for viewers it would work better. Most only do ViewTransform and DisplayDevice and the worse ones out there only combined definitions in a very long list. And not many apps AFAIK properly support OCIOLookTransform. Blender is to my knowledge the only one that has Look built into it’s color management to be included by default rather than a separate effect/node.
“Hueness” is not present in stimuli. This is false.
I should’ve clarified, I meant by observing the vectorscope. I personally don’t feel like such a property is necessarily desireable in appearance as observer, if that’s what you meant.
A vectorscope tells us nothing about the articulation of the stimuli, therefore nothing.
I’m not sure what the property here is? At any rate, I will cautiously promise that evaluating stimuli devoid of the spatiotemporal articulation is a fool’s errand.
We can, for example, increase the distal spatial articulation size by “zooming into” any of the examples from Chris or Jed, and the proximal landing of the stimuli will change. Given that at the very core of our visual cognition assemblies, the signal is a differential one, an A to B gradient if you will, the cognitive inference of “This is not part of the form” may or may not be induced. And the same applies if we “zoom out”.
The bottom line is whether or not one wants to accept the pictorial formation of the stimuli as the folks who designed it presented. Or whether such manipulations are viable and respond in a cognitively congruent manner when manipulating the stimuli wattages under this specific pictorial formation.
It would seem that the goalpost of a picture that is emulating a “filtered” BT.709 B channel is now an “edge case”.
Hi Jed!
In this example, the most saturated blue is Linear 0, 0, 1 in Rec709, not AP1?
I’m asking, because it looks like too much artifacts for just a rec709 blue.
I mean, the first one, with the face. Can’t quote it correctly
Yes, we are discussing a “lin_bt.709” blue primary in that scenario. Jed´s tests and mine are the same.
I agree that these artefacts are concerning for a “bt.709” primary and part of the debate is to figure out if this is an edge case or not. I personally think it is not.
We have seen in the past (ACES 1.X) similar artifacts BUT in wide gamuts, never in “lin_bt.709”.
Happy to discuss,
Chris
Hey, just to keep this interesting conversation going…
The example that I shared indeed uses a lin_bt.709 blue primary (0,0,1) but one may also reproduce the exact same behaviour with these values (0.04737, 0.01345, 0.8698) in ACEScg.
Because these values are nothing more than the blue sRGB/BT.709 primary expressed in ACEScg. So even without any channels at 0, one may reproduce these examples.
I just wanted to highlight that even if I still recommend to avoid channels at 0 in a RGB render engine (as opposed to spectral), these channels are relative to the colorspace they are expressed in.
Regards,
Chris
It’s true that the issue is not specific to having any channels at zero. That is just an easy way of creating a very saturated colour.
As was acknowledged in yesterday’s meeting, the requirement to hit all the corners of the display cube (which other renderings are not bound by) limits the ability to produce a nice looking image from every possible source without an LMT / grading. The DRT is only a start point.
I find this idea of Chris very good and logical.
There should be a simple way to choose between the not fully invertible and the invertible version of the DRT.
And the default should be the not invertible version in my opinion, because the average new user of ACES 2.0 wants to have rather a clean image in “edge” cases rather than “look, here is the new version of ACES, but you can reverse at any time?”.
The idea should be to use the new DRT, even for the so called “edge” cases.
Best
Daniel
I am “just” thinking about our target audience, that we discussed briefly two or three years ago.
If we think about non-professional users (students, freelancers, Unreal users…), the current behavior might create confusion. So adding a default LMT would help for the adoption I think.
And professional users would just switch this LMT for whatever they want to use.
Having LMTs available in implementation and configs would also allow non-professional users to know about them which can open some new possibilities.
My tuppence 
I completely agree with you, Christophe. The process should be as simple as possible for those who aren’t experts in color science. Generating non-smooth results from the outset isn’t ideal, particularly in the world of 3D VFX, where highly saturated colors are more common than in live-action cinematography. Many VFX artists know they need to work within ACES, but likely have little understanding of LMTs.
