• 10
• 10
• 12
• 12
• 14

# ACES and dynamic range

This topic is 369 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi,

ACES looks to be the best tonemapping nowadays. Using uncharted film tonemapping you had to normalize using a range value which is the max value :

float3 CurrentColor = FilmicTonemap( Color );
float3 WhiteScale = FilmicTonemap( float3( Range, Range, Range ) );
float3 FinalColor = CurrentColor / WhiteScale;

Is it the same for ACES or you can simply send the HDR on it and no range is needed to be specified ?

Thanks

Edited by Alundra

##### Share on other sites

ACES is becoming more popular in games, and definitely has some advantages. But "best" is a matter of opinion.

There is no adjustable white point for the ACES RRT, or for the sRGB monitor ODT that's commonly paired with it. The ODT will ultimately map everything to [0, 1] in sRGB color space, so you can throw whatever you want at it in terms of HDR intensities. There's a shoulder in the curve to avoid clipping, but you're still going to need to expose properly to get good results.

##### Share on other sites

Is the full ACES still overkill or the approx is still the way to go ?

##### Share on other sites

I think the approx is cool, but it only approximates the general curve of the output, none of the other "features" (like red adjustment, etc).

If you properly integrate something like OpenColorIO, you can spit out a simple LUT for the entire ODT/RRT transform and get great results for pretty cheap (you should pre-expose and map your HDR input into 12-bit ACESproxy space though so you have a proper range for your LUT input, since it's bounded).

You can also do this with a shader. I wrote an example on Shadertoy that performs the ODT/RRT transforms on an LUT, you can try pulling it and baking out the LUT from the first shader. FYI, if you do this you should probably store your LUT in something better than an 8bit texture. The professional apps use either 10 or 12 bit usually, occasionally in 16 bit float. 16^3 might not be enough for the ACES transform (I recall having issues at that res), so I'd suggest at least 32^3 or 64^3 if you can afford it.

I'd suggest the OpenColorIO route for generating your LUT though since it saves you a ton of work in the long run (just send OCIO some array of colors and a transform name and it'll spit out the result with all the proper LUTs applied with it), and it's much, much cleaner than carrying around a bunch of ACES code.

Edited by Styves

##### Share on other sites

There is no adjustable white point for the ACES RRT, or for the sRGB monitor ODT that's commonly paired with it. The ODT will ultimately map everything to [0, 1] in sRGB color space, so you can throw whatever you want at it in terms of HDR intensities. There's a shoulder in the curve to avoid clipping, but you're still going to need to expose properly to get good results.

Can you explain what you mean by "expose properly", please? Does that mean the average luminance of the area of interest (or the entire image) should be 0.18? E.g. an auto-exposure post effect should have a key value of 0.18? In my research of ACES so far, I've had little success finding info on what the intended values for the scene are meant to be, before it enters RRT/ODT. The 2065 encoding document says that a 18% reflective gray card should have a value of 0.18, but it also states that any deviations are meant to be preserved as "artistic intent". Is average luminance of 0.18 supposed to "look reasonable" after RRT/ODT outside of specific artistic intent to make the image look over/under-exposed? Also, do you know of any official resource describing RRT/ODT other than the reference code in the repository? The official documentation page has docs on encodings, IDTs and LMTs, but not RRT/ODT (http://www.oscars.org/science-technology/aces/aces-documentation).