Contrast LMT - Looking for Feedback

[sdyer (Scott Dyer)]

Hi all,

A group of us is looking to get broader feedback on a new “Contrast LMT” that @doug_walker has leading development of. The impetus for this LMT was some users seeking a drop-in adjustment to allow them to get the “finished” contrast of ACES 1 while still maintaining some of the other benefits of ACES 2.

To date, discussion of this work has occurred in the ACES Slack channel, with occasional updates given periodically at TSC meetings. We encourage you to join the ACES Slack channel if you have not done so already, but I’ll repost some of the key info here.

It’s worth stating clearly up front:

“this is a look, not the look”

While this Look is intended to be added to the aces-look repository, it should be thought of as any other Look, and is not intended to be a required piece of an ACES pipeline. It will, however, be a solid example of what a well-built LMT can look like.
We fully intend to provide additional example LMTs designed for specific use cases in the future. But for now, we’re limiting the scope and focus to just this one transform which will serve a specific use case. Just know there will be other options provided to allow “out-of-the-box” choices and to illustrate what is possible with Looks - but those will come in follow-on work.

Objective

This LMT is intended as a more refined replacement for the earlier sample contrast LMT that shipped with the initial ACES 2 release. That version did not hold up well in practice, so this is an attempt to provide a more refined and production-friendly version.

The goal is to get closer to the kind of “finished” contrast many grew accustomed to with ACES 1, while keeping the improved color behavior in ACES 2.

Feedback request

We’re looking for feedback on the colorfulness options to settle on the most appropriate adjustment option. The current OCIO config and DCTL provide a few options to compare, and are explained in the header comment section of the OCIO config.

The four looks provided are as follows:

1. “AP1 curve” – Tonal adjustment is applied as an RGB curve in AP1 primaries
2. “J curve” – Tonal adjustment is applied only to J, holding M and h constant
3. “J curve + M gain” – Tonal adjustment is applied to J, with a constant 22% gain in M
4. “J curve + M curve” – Tonal adjustment is applied to J, with an M gain that is a function of J

Options 1-3 are simpler but the current recommendation is option #4 the “J curve + M curve”.
All four options are mathematically straight-forward and have closed-form inverses.

Colorfulness objective: Keep saturation natural when the neutral scale is boosted, fixing the previous version’s tendency to oversaturate (especially skin tones)

After that is settled, we may issue an additional test config limited to looking only at tone scale + mid-gray options to finalize the contrast adjustment.

Tone scale objective: Add a sharper highlight rolloff for a more “finished” feel - roughly tracking ACES 1 contrast above mid-gray. Possibly adjust mid-gray placement a bit higher.

How to try it

OCIO

OCIO Config with multiple options for the Look Transform -
lmt_test1.ocio (45.5 KB)
Read the comments in the header for a description of the the options provided.

Note: The config requires OCIO 2.5.
For those without access to Flame or another app that supports OCIO 2.5, you can use OpenImageIO to process frames. Thanks to @zachlewis, it’s easy to install OIIO now via pip3 install openimageio and then use the oiiotool command-line program that it installs.

Here’s an example command to convert an ACES2065-1 OpenEXR file to an sRGB JPEG using a view with one of the look transforms from the config:

./oiiotool -i ACES_OT_VWG_SampleFrames.0074.exr --colorconfig lmt_test1.ocio --ociodisplay:from="ACES2065-1" "sRGB - Display" "ACES 2.0 - SDR 100 nits (Rec.709) - J curve + M curve" -o aces2-JcrvMcrv_0074.jpg

DCTL

Recognizing that the OCIO 2.5 requirement can be a bit of a hurdle for apps that don’t yet support it, Scott also put together a DCTL that matches the various options in Doug’s config to make it possible to test in Resolve.

What kind of feedback is helpful?

We are looking for feedback of the creative / preference variety:

• Which options feel best?
• Does it “look right” in practice?

If you have ideas for completely different technical approaches, that’s definitely welcome too, but we may spin those into separate threads so we can keep this one focused on refining this specific proposal. In fact, we’d love if anyone has interest in generating alternate LMTs to get involved, because as mentioned up top, providing more flexibility via LMTs is definitely on the roadmap.

[shebbe (Shebanjah Klaasen)]

@sdyer

The goal is to get closer to the kind of “finished” contrast many grew accustomed to with ACES 1, while keeping the improved color behavior in ACES 2.

@sdyer

Tone scale objective: Add a sharper highlight rolloff for a more “finished” feel - roughly tracking ACES 1 contrast above mid-gray. Possibly adjust mid-gray placement a bit higher.

If the overall objective is to provide a starting point more closely to ACES 1 isn’t it about the whole range rather than sharper highlights?

I checked it out very briefly and felt that it looks off when the rest of the image remains exactly the same. While ACES 1 sort of has ‘the same highlights’ it’s overall contrast feels more natural and smooth when compared to ACES 2 which now looks a bit weird with that specific boost.

@sdyer

Options 1-3 are simpler but the current recommendation is option #4 the “J curve + M curve”.
All four options are mathematically straight-forward and have closed-form inverses.

I had the same feeling that #4 is the best option if I were to pick one.
But I’d be curious to see if a broader ACES 1 contrast match is more effective.

[sdyer (Scott Dyer)]

@shebbe thanks for taking a look.

You’re right, and the highlight-only adjustment was intentional (at least for now). The plan is to validate the M adjustment options before introducing more tone scale variants, which would make the number of combinations to be evaluated overwhelming.

To focus testing, I created LMT_Test_OCIO_options.dctl to limits the options to those provided in the OCIO config.

If you want to check out with a full ACES 1 tone scale check LMT_Test_JM.dctl . It allows selecting a 1D look-up that will match the entire ACES 1 tone scale while still using the M-curve adjustment.

IMO, this is all just subjective preference. We can aim to select sensible defaults and follow on later to add contrast options (Low/Med/High) later.

I’ll defer to @doug_walker on any nuances in specific user requirements that sparked this request.

[shebbe (Shebanjah Klaasen)]

Ah thanks, I was not aware of the full context. The 1D LUT variant is indeed more what I was thinking.

I know it’s all in testing state now but I’m getting some artifacts in bright lights with the 1D LUT.

Win11/Resolve21beta/nvidia gpu

[sdyer (Scott Dyer)]

There have been some updates on this effort on the ACES Slack that I want to bring to the attention of those who may be following here. The group is preparing the final version of this transform for inclusion in an upcoming ACES release, so that it can in turn be included in OCIO 2.6.

Reposting from the Slack thread:

[Doug Walker]:
As a follow-up to my post from March 19, I’m posting an updated OCIO config file with a revised ACES 2 Look Transform proposal. As a reminder, the goal of this project is to develop an LMT that could be used with ACES 2 SDR Output Transforms that will give a similar amount of contrast and colorfulness as ACES 1. In addition, the proposed transform brightens the image by a half stop so that 18% gray falls at the same place in SDR and HDR.

This config file contains a new look “J curve 2 + M curve 2” and this look is available with the various ACES 2 displays and views. I left the earlier four looks from the previous test config as well, for comparison purposes.

As a reminder, we are planning on including the result of this project in OCIO 2.6 which ships in September.
…
I’m looking for input on both the tone reproduction curve and the level of color saturation. Because the tone scale is higher in contrast than ACES 2, it is expected that the images should have more colorfulness. The colorfulness level is more challenging to evaluate and I found it difficult to arrive at a single “J vs. M” curve that I’m fully happy with. I’m debating whether to add an additional “M vs. M” curve since the existing “J vs. M” curve applies uniformly to both high and low M values. If there is an issue with the colorfulness, it is probably more at the high end than the low end, IMHO. Feedback welcome!

Then there is also this plot and comparison to some other tone scales.

…the target use for this look transform is non-cinema viewing environments such as for general web usage and gaming. Hence a number of the comparisons here are from the gaming world.

Note: The “ACES 1 SDR Games” is representative of what is found in game engines such as Three.js and Filament. They use a polynomial approximation of ACES 1 that has a 3/4 of a stop boost in exposure. Although this is an outlier on this graph, it is not uncommon in gaming to use a tone-mapper that is this bright (even brighter than Un-tone-mapped at middle gray!). But personally I feel it is too bright and does not reserve enough of the display range for highlight detail.

Some key take-aways about the proposed LMT:

• Puts 18% gray at 15 nits (for a 100 nit white), which is brighter than ACES 1 or 2 SDR and more in line with ACES 1 or 2 HDR. But still slightly darker than Un-tone-mapped.
• Overall contrast is somewhere between ACES 1 and 2.
• Hits display white just above 16, same as ACES 1 SDR.

How to test

Using Resolve (DCTL)

Scott has updated his previous DCTL to include the newest options to make it easy to assess in Resolve.

Using OCIO

This updated OCIO Config includes the previous options plus the new one -
lmt_test2.ocio (48.8 KB)

As before, comments in the header describe the options.

Note: As before this config requires OCIO 2.5.
For those without access to Flame or another app that supports OCIO 2.5, you can use OpenImageIO to process frames, as described in the original post on this thread.

An example command to convert an ACES2065-1 OpenEXR file to an sRGB JPEG using the latest view option in the config:

./oiiotool -i ACES_OT_VWG_SampleFrames.0074.exr --colorconfig lmt_test2.ocio --ociodisplay:from="ACES2065-1" "sRGB - Display" "ACES 2.0 - SDR 100 nits (Rec.709) - J curve 2 + M curve 2" -o aces2-JcrvMcrv_0074.jpg

[ChrisBrejon (Christophe Brejon)]

Hello,

sorry for the late feedback. I hope we are still in time to develop a proper LMT for ACES 2.0. I will try to share with you all my comments in the best possible way, not only about the LUTs but also on how to share them so we get more involvement from the community.

Context

The LMTs were originally shared on March, 19th on Slack as an OCIO 2.5 Config. My honest feedback back then was that Nuke 17 “only” had OCIO 2.4 implemented. If you guys remember, during the OT VWG, many users were using Nuke (Non-Commercial) as their primary tool to work and evaluate. So if we want to include as many people as we can, I would recommend to improve this aspect. Also, if you guys remember, Alex Fry would from time to time bake the candidates as LUTs to help spreading the testing. Maybe we could do the same here…

I understand that ACES 2 is currently missing an important piece of the puzzle but without proper testing from the community, I fear that rushing this might not help anyone in the end. I can see in Doug’s latest message that he and Carol have agreed to push back the release, so thank you for taking this in account. I am not saying we should spend 4 years on this LMT but more testing is needed.

I am thinking of the millions of ACES users around the world. To give them a better starting point is a huge responsibility. The feedback I am about to share is based on 3D LUTs baked from Doug’s config. If you guys estimate that this introduces too much bias in the evaluation, please feel free to discard all my comments.

Otherwise let’s start !

Nuke Setup

I am comparing here the candidates with openDRT, JP2499 and Picture Shop High Contrast in Rec.709. I always find it useful to compare against different picture formations to fight visual adaptation.

In my screenshots I will compare ACES 2.0 (first) with the respective candidate (second). I acknowledge the fact that some of the issues encountered may not come from the LMT, but the Output Transform itself.

AP1 curve

If you look at the last row, the spheres are brighter than any other picture formation that I am using. This is what I called on Slack “aggressive path-to-white”. It is especially noticeable in the blue and red spheres.

This creates these incredibly hard “white” zones in the following render where arguably the area lights’ reflection should be way smoother. This could potentially create some issues when someone evaluates the roughness of a specular for example. Here is openDRT for comparison:

I could provide more examples if needed but the harsh transitions discard this candidate in my opinion. Let’s have a look at the next one.

J curve

The J Curve candidate has also a way too elevated contrast but also desaturates too much the colours overall, especially in the “midtones”.

Here the Lego characters appear much more desaturated than any other picture formations I am comparing with. Same with the green and red bricks looking too bright.

I will move now to the next candidate.

J curve + M Curve

This one is tricky because at first glance, it may appear that it solving some the issues mentioned previously. But as always, devil is in the details.

Here for example, if we look at the red column, as exposure is going up, we are slowly losing the shape of a sphere. Especially the last row of the red spheres, I find it especially difficult to “cognize” it properly.

There is also an interesting phenomenon happening in the yellows where the exceeding saturation in the third row creates a polarity flip where the yellow colour appears brighter than the “white” specular.

I had noticed something on dark blues as well yesterday but I cannot seem to remember what it was exactly. But let’s have a look at the next one.

J curve + M Curve Gain

I dismissed this one quickly because it has a big issue in dark blues.

It is noticeable in the Lego brick as well.

Overall I find these candidates too high in their contrast. Picture formations are a delicate thing and I feel like we are pushing too much the values here. I also tried to focus my comments on the LMTs themselves and not the actual Output Transform, but it would have been nice to improve some of these aspects as well.

Anyway I hope you find these examples useful and relevant. I like to focus on simple examples because this is easier to see where things work in that case and where things fall apart. I will do a second post with the two more recent candidates. Thanks !

[ChrisBrejon (Christophe Brejon)]

J curve2 + M Curve2

Overall I still find this candidate to have a contrast that is too high.

It is higher than any other Picture Formations I have available, including ACES 1. The red character is “singing” too much.

Here I can still observe the yellow polarity flip happening and the “bleaching” is too strong. I would recommend a softer approach.

Similar comments can be made about J curve3 + M Curve3.

Conclusion

First of all, I cannot tell for sure if what I am observing is because of the baked 3D LUTs. This is a factor that could complicate things.

Before we start iterating, maybe we should discuss what kind of control we have in OCIO to generate this LMT and how far are we wiling to go. This could help managing expectations on both sides.

My overall feedback is that all of the candidates is making the path-to-white between midtones and white way too short, more than any other picture formations I can see including ACES 1.

So I am wondering if we have taken the right approach or shall we re-visit some assumptions ? The purity attenuation is one of the trickiest thing to set and we are about to make a very important decision, so we should be careful.

Final example to show that the last candidate is brighter than ACES 1 and I think this is problematic:

[doug_walker]

Thanks for this feedback, Chris! I’m excited to be benefiting from your wealth of experience as we fine tune this look transform. It’s always interesting to read your thoughts on things.

Unfortunately, we may have wasted some of your time due to a lack of clarity about what we are actually looking for feedback on. The “AP1 curve”, “J curve”, and “J curve + M gain” looks were presented as examples of simpler approaches that don’t actually work. This was explained in the text that went out with lmt_test1.ocio and lmt_test2.ocio, but by the time I got to lmt_test3.ocio, I stopped including that lengthy background info, assuming everyone was on the same page by that point. I realize now that probably led you astray about what we wanted feedback on, so my apologies for that.

In addition, I want to address some potential confusion over terminology. In my Slack posts, when I used the term “path to white”, I was referring to the way that ACES 2 desaturates colors towards white as they get very bright. Whereas above you wrote: “all of the candidates are making the path-to-white between midtones and white way too short” and I think you are instead using that term to refer to the shape of the tone-reproduction curve for neutrals, which is something different. It seems like you are using the term “purity attenuation” to refer to the desaturation of colors as they get very bright. I’m happy to use your term for that in this thread, so we’re all referring to the same thing.

Most importantly, allow me to clarify the goal of this look transform project. The goal is to develop a mathematically simple and invertible transform to increase brightness and contrast, while still having the overall color reproduction of ACES 2.

Please note that this is not intended for use in traditional cinema or TV scenarios, it is more intended for people making stuff for the web or for games. One common bit of feedback from that group is that ACES (1 or 2) “looks too dark”. This is because the tone scale of ACES is designed for cinema-style presentation where you don’t have much full-scale white on screen. As soon as the visual field has significant amounts of white, ACES does tend to look too dark.

Scott shared one of the graphs I posted above that compares ACES to other common tone-mappers intended for web or gaming use. My proposed look transform is not as bright as most of those, but it is still brighter than either ACES 1 or 2, by design. The overall contrast is somewhere between ACES 1 and 2, by design. So the intended usage for this look may be different from what you were expecting.

The main thing I’m looking for feedback on is whether the colorfulness of the images is appropriate for the given level of contrast, including the purity attenuation aspect. In addition, I’m interested in feedback on gradability or the presence of artifacts.

Regarding your step of converting the look transforms into 3D LUTs, I’m worried about how accurate that is. Most people have a timeline of EXR files that they use to evaluate transforms like this. What I had proposed is that people use OpenImageIO or OpenColorIO command-line tools (which are easily installed via “pip”) to apply the transform. Scott shared the oiiotool command above and that will apply both the look and the ACES 2 output transform. But please note that by using the “–ociolook” rather than “–ociodisplay”, you may apply just the look and write out EXR files, if that makes it easier for use in programs such as Nuke. Would that approach work for you?

I’m confident that I can improve on the provided “J curve 3 + M curve 3” look by focusing on the purity attenuation and related colorfulness issues, so I will give that a try. Are the sphere and Lego images you used available in one of the public image sets? I will add those to my own evaluation set.

Thanks again,
Doug

[ChrisBrejon (Christophe Brejon)]

All good, no time wasted.

Between the need of a 3D bake for the LUTs and the very specific requirement of web content creation, I am not sure you even need me.

But having discussed this post with some of my colour peeps this week-end, I would like to add that:

the excitation purity is too strong in the midtones but too weak in the highlights.

I thought this is a good way to summarize my posts.

Or put differently, there is a lack of purity attenuation in the midtones and an excess of it in the highlights. And this creates these abrupt transitions that we have been observing in my examples. This is what I mean by “path-to-white”.

Yes, the spheres and Lego renders are available in the official set: ACES Output Transform Image Submissions

Thanks !

[piotrus3333 (Marcin Piotrowski)]

Just a small note: you can test this 2.5 config in both Photoshop and Blender (5.2).