Jump to content
  • Advertisement
Sign in to follow this  
Alundra

ACES and dynamic range

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement

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 this post


Link to post
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 this post


Link to post
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).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!