We use the same GoToMeeting URL and phone number for all virtual working group 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 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
Thanks Nick for the notes. It is always very helpful to go back to the notes and check exactly what has been discussed.
One thing caught my attention during last meeting (at 17:00) :
Also the mid-slope, this has been a constant thing that the ACES RRT is too contrasty by default. Obviously that’s an aesthetic preference. Some people love the contrastiness of the RRT. But we know that it can be much more forgiving if you take just the edge of that off a little bit, and especially for people who are used to looking at other renderings that tend to have a little bit less contrast by default. […] I’m thinking that will probably a value is somewhere between where we currently are, and if we over plotted, some other favorable renderings that people tend to like (like K1S1).
What about doing something similar than the filmic blender which comes with different looks for contrast ?
Very High Contrast
High Contrast
Medium High Contrast
Very Low Contrast
Medium Low Contrast
Low Contrast
Base Contrast
Since contrast is an aesthetic preference, would that make sense ? I already asked the question here and I think this is part of what Jed’s hinting at with this thread as well. I guess it will be pretty much impossible to have everyone agree on contrast so having several looks could give us more options.
@ChrisBrejon certainly a reasonable questions to ask.
However, in my opinion, too many options is a bad idea. We already have enough to contend with by trying to accommodate different rendering intents.
RED IPP2 also provides 4 contrast options and 4 R options - but I rarely hear anybody say “I used IPP2 with low contrast and R4 Very Soft”. Instead, they just say “it’s IPP2”. So if anyone is using anything other than the default, this can cause problems.
Also, we’re not prohibiting people from adjusting contrast, just not doing it with the reference rendering. Anyone can, and always has been able to, establish an “always on” LMT that boosts or lowers contrast of the default rendering to their liking.
There have certainly been requests that whatever becomes ACES 2.0 we ship a library of “look” LUTs via LMT akin to RED’s Creative LUT Kit, ARRI’s Look Library APP, or Sony’s Cine LUTs. Doing so would service people who just want presets and also demonstrate that the base rendering does not restrict from changing the look creatively.
Back to tone scale design: We don’t want things to go unrendered, but I do believe that taking just a bit off our current tone scale midslope and highlight rolloff might help us with reducing the obviousness of some of the objectionable skews or artifacts that are accentuated through the current structure.
I think the key idea is, that we need to identify the behavior we expect from the tone mapper across different displays and use cases, and make sure that whatever model we choose meets those needs. It is easier to discuss this in a B&W context and leave color out of it for the time being. I’m working on talking more on this in a separate post…
Isn’t this impossible operating in the stimulus domain?
The stimulus will yield irregular notions of brightness (luminance and / or more refined models), hence instantly voided in terms of meaningfulness because the result is nonuniform with respect to the perceptual sensation?
EG: Red skewing to yellow, or magenta, will gravely shift the resulting brightness in a completely non-uniform manner when compared to the identical curve applied to blues, which would skew in a completely different manner and derive completely different brightness / luminance. Even with respect to near identical light mixtures, the skews will cleave toward rather different notions of brightness / luminance.
Thanks for your answer. That’s much appreciated. Yes, I am pretty fond of this idea. I’m quite sure our studio (and others) would love to have a look library to dig from.
If I’m being honest, I’m struggling a bit to grasp the scope of the VWG. I have always thought (since it was a major version update) that “every option was on the table” (as it has been said a couple of times). Or is it more like fixes and updates of the current system ?
I think it’s true that the group can consider every option on the table, but that the final delivery shouldn’t be every option on the table. We need to deliver the simplest system that fixes the issues and meets the requirements.
The benefit of a DRT that is not too aggressive is that it is easier to work under, and tweak the look with LMTs. Also, by providing many rendering options we are also showing that as a group, we are unable to decide what we think is the best which is not necessarily a great signal. It also increases management complexity.
One rendering solution, not “too aggressive”, with maybe a couple of LMTs could be a nice “demo” of the system’s possibilities. As you already know, our studio is quite fond of very saturated images, which might not be suitable for other projects (hence the proposal for different looks available, including one by default).
There is a video about RenderMan 24 and I was really pleased to see to see the following “Look” feature implemented :
I’d be happy to upload all my CG examples with a B&W version. Is there a “proper” way to desaturate an image ? Is it just saturation at 0 in Nuke ? I kinda remember there was a bit of debate when we did this sequence on Happy Feet 2 :
After some discussion, I believe the luminance weights for ACEScg in Natron are correct.
For posterity:
To calculate luminance weights for some RGB colorspace, one would calculate an RGB to XYZ matrix using XYZ Scaling as the chromatic adaptation method, and then take the middle row of that conversion matrix.
For example for converting ACEScg to XYZ E w/ XYZ Scaling CAT, the matrix would be
I have uploaded twenty exr files in B&W using the latest version of the saturation node from Jed with the following options :
The exr files have the following characteristics :
Encoded as ACES - ACES2065-1 with proper metadata (ACES compliant EXR).
Full HD (1920*1080) with correct metadata (dataWindow and displayWindow being the same : 0,0,1919,1079 to avoid any CTL crash).
To avoid any ambiguity, there are two suffixes (‘lin_ap0’ for the colourspace and ‘BW’ for the version).
Some of these exr are more interested than others. But I thought it would be better to convert/upload all of them to be safe. It has been a very interesting “exercise”. A couple of examples jumped out to me immediately.
The loss of tonality using ACEScg primaries on the spheres is quite interesting :
I used Jed’s Output Transform Nuke implementation. It is a perfect match to the CTL code and it is easier for me to generate frames. I hope that’s okay. I am wondering if we could use these “luminance” tests as a ground truth for tonality when we’ll switch back to their colour versions.
