Just for my understanding, being able to hit the corner is primairily for sake of an inverse? I would guess no one would really care about hitting it in grading if that results to what we currently have?..
How far off is ‘not hitting the corner’? Is there be a world where we could say, we can ‘get away’ with it?
If there really is no way to have smooth rendering and being able to hit the corners I can live with an LMT.
The only thing that is not quite clear to me is how this would be implemented. What if having that LMT enabled becomes so ‘popular’ pretty much everyone not needing/caring about inverse wants it enabled? We’d always have to place/apply it manually which may not be as trivial or even possible in some software utilizing OCIO. I know Blender has a look dropdown but not many other CG/Composite packages do no? And including it as Display Space (LMT+ODT) within the config, giving it an extra option in that list sounds a bit unelegant.
But maybe I’m already running too far ahead with this.
I pushed a pull request for @alexfry for CAM DRT v056, also available from my repo. This version only adjusts the blue LMS primary and is otherwise identical to v055. This is done to reduce the skew towards cyan that was discussed in the last meeting and in this thread.
Here’s @TooDee’s star image exposure ramps with v056, and I threw a comparison to ARRI Reveal as well.
I would disagree, for many this is the top priority.
Here we see the biggest challenge again.
The success of a DRT is mainly defined by the objectives and priorities one sets. An acceptable DRT for one might be unacceptable for the next.
But I agree, smoothness is quite up the list. And it stands in direct conflict with “gamut mapping” because the display gamuts have quite discontinued hulls.
No “reaching out” cannot be accomplished if a DRT limits to early.
To be fair to the people involved. You can tear down any DRT if you change objectives, amplify the weaknesses and sell deliberate tradeoffs as bugs.
It is an impossible task this group is forced to accomplish.
Again, most important to whom?
I can understand your frustration, but we need to start to manage our expectations here, otherwise my joke about meeting 200 will become reality.
Maybe it’s a good time to revisit the whole approach how to add graphic elements? Sort of an alpha channel for bypassing the DRT for some parts of the screen, but only for frames where it needs to be? Well, not completely bypassing DRT, but a separate special conversion for graphics between display devices, that is applied using that alpha channel.
Or even optional additional RGB channels, for better transparency, that will only be added (and take disc space), if there are some graphics in those frames.
Not exactly this, but something, that could be accepted as a standard way of adding graphic elements in ACES framework.
And to have an approximate inverse, just for using the old show LUTs or some other unusual cases. Which would not force to make compromises in the forward DRT.
A lot of unnecessary complications. All this can be achieved by using DRT only for specific clips with post-groups / adjustments layers in Resolve or layers in Mistika / Baselight. I do not think it is an ACES problem.
I assume that the main goal for DRT development team is to ship it and test in real production workflows. That would help to identify the most important visual issues and understand if they are fixable in DRT or it is better to use LMT instead. All DRT fixes that resolve one problem can create another.
Next step might be to document all remaining bugs and create LMTs that should be used in specific cases. Explainer videos and clear documentation should make adoption easier.
That said, I believe in ACES team and their judgement on what to do next and in what order.
No DRT that pursues so wildly different goals will be devoid of issues, it should be accepted at this point.
Also glad you compared rev056 with Reveal because one of the reasons I like this ACES2 version is that the Blues are more to Blue whereas Reveal more to Cyan. So the better, smoother Blues are appreciated.
I do not wish to emulate Reveal nor Resolve, but rather find an alternative that works well and may be better for some. Also feeling that “smoothness” is a high priority, I give high priority to SDR - HDR consistency. As it was stated that most use SDR, I will say that my intent as an artist is to utilize the HDR. Displays are now being produced that can really harness HDR. My appreciation goes to the ACES team for sticking with HDR as one of the priorities. I am not sure if any other DRT builders have been quite as concerned.
Literally no one has identified what the purity dimension does in pictorial depictions here yet. That means it’s not fixable because no one knows what is broken.
Try the milk glass test.
Try to tint “under” the picture formation.
Same old same old.
Visual cognition is computation from the visual fields, and as such, this is literally an impossibility.
But the protocol did not outline what the creative parameter space is at the onset.
PS: Visual cognition doesn’t have an HDR mode, despite what subscription services and TV salespeople would have us believe.
If I get it right, this should be basically a set of rules on how to build your own workflow and still be compatible with ACES using some metadata thing?
Below isn’t basically a reply to your proposal, but it reminded me about my message from one discord discussion.
And regarding DRT - I’d prefer something like that: standard s curve, that has an option to adjust contrast. But the overall design should allow to easily change the path-to-white / “hue preserving” / per-channel modules.
So no waiting for major updates. Just different modules, loaded into DRT, that provide different qualities. So if someone needs “hue-preserving”, just downloads it or makes it by themselves.
Sort of a simple to use constructor. No choosing between different DRTs, but a standard system that allows to change or modify it’s qualities as files containing some code or a 3d table responsible for the particular part of rendering.
I wouldn’t focus too much on my specific LMT. I am not proposing it as the ultimate solution. It was just a quick experiment into the concept of a JMh based LMT.
My real point is that a range of LMTs are possible, for various technical or creative purposes, and a DRT which does not limit the scope of what those LMTs can do allows the widest range of possibilities.
And ARRI Reveal doesn’t always reach the corners, whereas CAM DRT has that as a requirement we’ve chosen to have. Here’s an example sweep for v056 and ARRI Reveal:
Here is an updated version of my LMT, written as a single Blink kernel, rather than built from multiple DRT nodes in diagnostic modes. It also now includes parametric control of the hue to be compressed, rather than using a curve lookup, so it is easier to try the effect on different hues.
Well, if you want to create an archive master without DRT, this does not work. Also, how do you treat graphics for different versions (SDR vs. HDR)? If it would be simple, it would have been done .
OCIO is a colour management system; it is not the same as defining a meta-framework. For example, IDTs are only expressed as 1D LUT and Matrix in OCIO, which is unacceptable for a meta-framework. Creating a framework would actually be quite an undertaking in practice. This working group has not even started defining the rest of the pipeline (Viewing Conditions, White Point Handling, EOTFs etc…). It is still a lot of work…
It is never too late.
I think this would only move the issue a step further up the abstraction layer. People would want a different algorithm at some point, also the system would be so complex that it would be hard to control.
The only way I found satisfying all use cases is to make the DRT a swappable building block.
I was not thinking about archival purposes, point taken. You and Anton are right, this is a whole different can of worms.
Out of curiosity, why are 1D LUT and 3x3 matrix not enough for IDTs? This approach satisfies “linearity” condition.
In my mind (and mind of a lot of my colleagues) ACES is an established color-management system with its own set of pros and cons. There is some mental inertia which we should overcome to pivot it to a meta-framework. It is a very interesting challenge, especially because some of the concepts should be defined from ground up, but I wonder…
What specific problem(s) does meta framework solve? I don’t see a lack of innovation in the industry, but I may be missing something.
P.S. I think that the latter part of the discussion can be continued in the framework thread.
Thanks for taking star image for through another test.
I am not really sure if this is kind of image is a good method to test a DRT in the first place. But it is simple test image at least. And I am pretty sure if someone in AE with the new ACES configs would look for an intense blue, why not using 0/0/1?
I noticed not only the blue changed (but there is still the kink in the plot), but also the yellow changed slightly. I got more straight to the gamut boundary?
The gamut mapper is what creates the curvature in chromaticity space as it compresses along the perceptual hue lines. It’s not just the blue, green and red stars shows curving as well. There’s also clipping (which further skews) as the gamut mapping result is not quite exact to the boundary.
.
