Wednesday, March 10, 2021
11:00am - 12:00pm Pacific Time (UTC-7:00pm)
Please join us for the next meeting of this virtual working group (VWG). Future meeting dates for this month include:
3/17/21
3/24/21
3/31/21
Dropbox Paper link for this group:
We will be using the same GoToMeeting url and phone numbers as in previous groups.
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 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. United States: +1 (669) 224-3319 Access Code: 241-798-885
Picking up on a discussion from last night’s meeting, can somebody clarify something for me?
I don’t know Unreal Engine. Am I understanding correctly that it uses a modified version of ACES which includes a trim (inversion of the blue highlight fix?) in display linear, just before the final display encoding step? So the discussion of matching UE4 was related to replicating the appearance of this with a standard ACES implementation? Essentially if you can add the same post rendering modification that UE4 does, it’s easy to match it. It’s much harder (indeed impossible for multiple targets) to create a scene-referred adjustment that achieves exactly the same result.
BUT beyond that, there are few things that make things easier for live event productions, if the client ends up post-RRT/ODT/SSTS with a hard time to push some colours, e.g. yellow, it is certainly much easier to do that in display-referred state and provide a small surgery node to insert above the stack. It is relatively easy to do in UE4.
It is of course perfectly possible to do in most grading systems as well. While the standard ACES setup in Baselight/Resolve has the Output Transform applied at a system level, it is possible to apply it in the stack/node tree instead, and thereby “roll your own” custom ACES based pipeline with additional post OT tweaks. You diverge from the standard at your own risk, but if you just need to get something up on a single display, without the requirement to replicate it elsewhere, you can do what it takes to get that done.
@Thomas_Mansencal In our version that we did, we initially supported making the blue highlight fix lerp ration changeable per shot just like Unreal did but I removed it since artists didn’t understand what it was and just didn’t care about it. As a fun anecdote, we also had a red modifier scale too which went the way of the dodo even quicker. Anyway, this will be gone soon on our side since I’m updating to ACES 1.3.
I don’t think UE4 provides extra surgery nodes post-RRT/ODT/SSTS aside from this inverse blue fix. They do however get out of (kinda) ACES in their SDR codepath to support their legacy LUT blending before they apply the tonemap curve. I call it kinda ACES because their SDR codepath doesn’t use the real ACES curve while their HDR path does.
To any Unreal dev who reads this, I’m sorry if I’m harsh but I really believe that keeping that amount of legacy is a hindrance.
Is it then safe to assume that the ACES workflow will just work out of the box in UE5 without jumping through these hoops ?
Based on all your threads, I think I have a handle on how to set this up but with UE5 around the corner I was wishing for this to be more artist friendly to implement at smaller studios.