We use the same GoToMeeting URL and phone numbers for all VWG meetings.
You may join via computer/smartphone (preferred) which will allow you to see any presentations or documents that are shared, or you can join using a telephone which will be an audio only experience.
Please note that meetings are recorded and transcribed and open to the public. By participating you are agreeing to the ACESCentral Virtual Working Group Participation Guidelines.
Audio + Video
Please join my meeting from your computer, tablet or smartphone.
Audio Only
You can also dial in using your phone.
Dial the closest number to your location and then follow the prompts to enter the access code.
Regarding the planned test candidate OCIO config, P3 and Rec709 were mentioned for the ODTs. I wonder if it would be good to add in an sRGB (gamma 2.2) ODT as well? Since many CG artist monitors would be set to that.
I think it could be interesting to see how the creation of CG renders behave under these DRTs for lookdev and lighting. In addition to seeing how they do with existing images.
Blind test without descriptions for the candidates seems like the best idea for sure. And if there is going to be description then a single sentence technical description per transform is enough.
I also think that @sdyer’s suggestion in earlier meetings of chucking the ACES transform entirely and replacing it with @jedsmith’s rgbDRT would be better. The out of the box rendering primaries are actually very good. Anyone who hasn’t tried it yet, really should. It’s better than the modified ACES transform, imho.
The image set Scott was showing was great. It would be nice if that image set was made public. We only have similar images from CML and camera manufacturers and they’ve all been used a lot.
I agree with what has been written above. I have tried to follow as closely as I could the OT VWG during the past 16 months and I am not sure why these these three candidates have been chosen over other ones.
To me, there are at least two other potential candidates out there :
Since there won’t be default LMT for OpenDRT for testing, maybe it’s a good idea to bring back perceptual dechroma to OpenDRT? This was a nice option. I’d say, this was the big reason to use OpenDRT despite its downside - ‘desaturated’ shadows.
And seems like only Candidate A allows to use the whole rec709 gamut. So, ACES 2.0 most likely won’t be able to produce all display colors? As an artist, I like limitations, including this one. But as a colorist, I’m often faced with tasks from clients that require the whole gamut.
Basically because nobody in the meetings made a strong case that we should be looking at the others. I know they’ve been mentioned a handful of times here in the forum, but if we just get silence during the meetings, these things tend to fall off the table.
Candidate A was always intended to be the “Do you just prefer the existing flavour?” option, with the minimum number of changes possible. We certainly could swap it out for rgbDT, if there is agreement here (I don’t recall it being a lock one way or the other in the meeting).
Also, there is nothing specifically limiting us to only 3 candidate transforms (There is a practical upper limit, but it’s way more than 3). Assuming they all behave in a meaningfully different manner.
I could easily be wrong, but my assumption was always that @jedsmith himself always preferred OpenDRT over JzDT, otherwise OpenDRT would have simply switched to Jz as it’s working space.
I think you might have found some failings in the shaper space I’ve chosen as the input to the 3D LUTs (AP0 prims ACEScct curve).
Both OpenDRT and ZCAM DRTcan reach the corners (or rounded corners in the case of ZCAM DRT), but they both require values that are pretty extreme to get there, values that fall outside that shaper. This is paticularly clear around yellow.
Thank you for the detailed explanation!
So, precise inversion (for motion graphics elements) is impossible with ZCAM DRT at this moment? I mean, procedural version. Because of the rounded corners.
And regarding OpenDRT - I can’t reach the corners with procedural DCTL neither. Not sure .dctl implementation is updated the same time as .nk though.
For whatever it’s worth I’d choose rgbDRT for the user test over the modded ACES transform.
That is something that could be looked at if the OpenDRT candidate turns out to be the favorite and maybe offer that as another alternative for later user testing.
This seems to be possible with latest OpenDRT through inverse but from forward direction, it’ll be very difficult. With ZCAM DRT it’s the highligh desat that prevents getting to the yellow corners easily from forward direction. Disable that and it’s not difficult then. Maybe something to look at later.
I cannot attend the meetings anymore and I hope this group will look at rgbDRT. I personally think it did not get the attention it deserves by the VWG. I know that time and resources are limited, but I feel there was something simple and promising here.
I have a hard time seeing the logic here. This group has agreed on fixing the known issues of the ACES Output Transforms (btw, issues that were described very preciselyin the aces chat on slack back in 2016…). So how could this be a potential candidate ? Furthermore, unlike the other candidates, I was not able to find any prototype for it. Can we actually test it ?
OpenDRT looks quite similar to TCAM and I think having JzDT out there would give more options to artists and colorists.
Not exactly.
It’s specifically the “smooth cusps” control that prevents you from hitting that yellow corner. This was added based a suggestions from @bottosson, basically to stop a kink, or folded edge, from forming near the corner of the target gamut. Without it you get a sort of echo of the hard corner protruding into the compressed in data.
Now like everything else, this is a trade off worth discussing.
Is the smoothness of the compressed data worth the trade off of not being able hit the absolute corner?
Do we currently have the right value? Have a play around with the “smooth cusps” control to try out different options. 0 is a hard corner, 1.0 is very rounded.
Is the pinching in the data visible in real imagery? Or is this more of a problem just with charts?
It is a little curious that it currently effects Yellow and Cyan much more strongly/earlier than Magenta or the primaries. Perhaps is needs some bias controls of some sort?
I also think JzDT should be added as a candidate.
But I don’t understand why per-channel DRTs (modified ACES 1.x DRT or rgbDRT) should be included at all.
I agree. I think I suggested in the March 23 meeting that if we are to include a simple RGB lookup that I wouldn’t use AP1 primaries. Some suggested establishing some other primaries - joking they’d probably end up somewhere near Alexa WG - but no one (including me) suggested a different set of primaries other than Jed and I think his work.
Sounds like we might want to nail this decision down in tomorrow’s meeting.
I think it’s a good idea to include one. In past experience, whenever we’ve shifted over completely to a more “mathematically pure” approach like OpenDRT, it works great for most stuff - until it doesn’t. When we dev’d it last time around we put a ton of extra code and modules in to mitigate some of those weirdnesses once they were encountered, but when it broke, it broke bad. I still think it was workable but some users are very sensitive to behavior that is different from what they’re used to - and a lot of popular renderings are simple and familiar.
I think it’s important to include both as fundamentally different algorithms to see what different groups of people actually prefer in a larger test group - and after more years to adapt to changes in taste.
