Isotropix Forums

Correct me if I'm wrong, when I set the scene color space to Acescg under preferences, do I still need to convert the hdri and the base color to aces texture using a [color space] in the material editor? I'm asking because when I do, it gives me a very dark base color, so I was wondering if I was double converting?

Hello Karen,

If you have already pre-converted your assets, load them as ACEScg in your map_file or streamed_map color-space attribute. If not, the rule of thumb is the following:

• Utility – sRGB – Texture: for your LDR (low dynamic range) aka 8bit textures: Color (Albedo/Diffuse), Specular etc. Note: PNG, JPEG, TIFF, Targa (even 16 bit ones) have a pre-baked "gamma" (transfer function) and will use this IDT and not "Utility - Linear - sRGB".

• Utility – Linear – sRGB: for HDR (high dynamic range) images like HDRIs IBL and all files with a linear transfer function within the sRGB gamut. Also valid for 16 bit EXR or TIFF files for instance.

• Utility – Raw: for scalar maps that need to be linearized when rendering such as: roughness, displacement, normal maps etc…

• Render in ACEScg and use OUTPUT - ACES sRGB, assuming that your monitor is in sRGB. If not, find out what your monitor is set to and use the appropriate ODT.

Best

Utility – Linear – sRGB: for HDR (high dynamic range) images like HDRIs IBL and all files with a linear transfer function within the sRGB gamut. Also valid for 16 bit EXR or TIFF files for instance.

Why do you need to change the IBL to srgb surely you would loose all the lighting info? I can understand wanting to do it for the BG matte sphere if rendering in tonemapped srgb but still not sure thats correct.

Hello @RayCaster,

HDRIs are almost always exported and processed using the sRGB gamut. You'll need to use the Linear-sRGB IDT so the transform (via matrix or 3D LUT) to ACEScg is accurate.

See below the differences if you are not doing any (utility) transforms, you get an incorrect result. This does apply to EXR Linear-sRGB color maps as well. Only scalar/data maps can be used directly (RAW which would result the same if you select ACEScg too as they do not contain any color data).



PS: If the GIF is not working, download it or middle-mouse-button click on it. It's not a still image.
Edit: I recommend you to have a read at the pretty in-depth covering of ACES for rendering, by Chris Brejon: https://chrisbrejon.com/cg-cinematography/chapter-1-5-academy-color-encoding-system-aces/.

Best.

I wonder does ACES solve any rendering issues in Clarisse ? I understand the purpose of some standardization and matching real cameras in final compositing and also "archiving" wide gamut for future "uber" monitors but still wonder if it really helps to solve some problems with rendering?

I render backgrounds for games where sRGB is a standard. Every comparison picture I saw is just kind of posteffect LUT or tonemapping appied . A bit more contrast, like slightly more linear, a bit closer to what games looked like before gamma correction era, perfectly reachable without ACES in a word .

So should I bother with ACES if I don't work for movie wide gamut pipeline?

I think you need to be more specific in regard to what issues or problems you are referring to for others to tell if using ACES will solve them or not. Depending on who you ask, you will get quite different answers to the question what is great or special about it, as adopts various techniques and concepts, like scene-linearity, wide gamut, gamut transforms and tone-mapping. None of these are particularly new and have been used for a while in various ways depending on the individual needs. What is special about aces is that in combines these into something like an out-of-the-box package ready for everyone to use.

Like in any aspects of life, these one-size-fits-all approaches have their advantages and disadvantages. It‘s great to have all input and output transforms in one place, but if you only use 5 from the 100+ colorspaces available, that aspect becomes more of a burden than a benefit, since you have to select the one entry you need in a long list and you get an ocio configuration that occupies 2GB in size instead of the 5MB you actually need. Same with tone-mapping, it’s great to have a ready-to-use solution available, but if you are used to create you own output transforms for specific needs - like more or less contrast, high key or low key - or use the ones from camera-manufacturers or DI, there isn’t really a benefit.

At the end of the day, it depends on what you are trying to achieve. If you only work with sources in sRGB gamut anyways, there is no point in blowing them up to a wide gamut working space. If you are used to color-correct your renders, it might be more useful for you to learn how to write an OCIO config yourself to integrate these color transforms into the viewport instead of relying on the aces rrt an additionally to only put the colorspaces in there that you really need.

Thanks t_b_s. About issues. I meant basically all those examples ACES vs Standard I saw in internet trying to explain a virtue of super wide gamut "scene referenced" etc colors and problems ACES solves. Every time I saw those examples I wonder why I never had such problems , even in old Mental ray . Or they easily avoidable with regular tone mapping

I am perfectly fine with Filmic look transform Blender does for example .
https://www.dropbox.com/s/7cw3wcewib3ne ... s.jpg?dl=0

kirkr22 wrote:Thanks t_b_s. About issues. I meant basically all those examples ACES vs Standard I saw in internet trying to explain a virtue of super wide gamut "scene referenced" etc colors and problems ACES solves. Every time I saw those examples I wonder why I never had such problems , even in old Mental ray . Or they easily avoidable with regular tone mapping

I am perfectly fine with Filmic look transform Blender does for example .
https://www.dropbox.com/s/7cw3wcewib3ne ... s.jpg?dl=0

it's a screen from real time Eevee render. Primary colors.

Besides the fact that nobody in right mind would use primary colors as textures they are still nothing like that super over-saturated example Chris Brejon shows in his paper as "before ACES" . in his "we are getting much more photoreal with ACES" example in the end.
I'm struggling to recreate same insanely over-saturated something in Clarisse too and anyway if I would it's still easily avoidable.
And every my ACES approach results in some reddish/violet shifting.

I still don't get, what these problem are that "aces solves" but you never had. What's important to understand is that the "standard" color-management configurations, like nuke-default, Clarisse's default and filmic blender* are gamut-agnostic. That means they neither use a wide gamut nor a small gamut, they do no translate between gamuts whatsoever. Which means that the gamut of the system is determined by the device you use to look at the images, which probably uses sRGB/rec709 gamut or is limited to sRGB by the OS. Which gives you the impression you are working in sRGB gamut while you are actually not, it's just the way how you look at it.

If you are working with sRGB source imagery for an sRGB output device, no one would expect that you run into problems with gamut transforms, since you don't need to apply them. Meanwhile every film camera out there shoots to some non-sRGB gamut of its own, that you want to look at on an sRGB/rec709 device and propably want to mix with imagery from other sources, so working in that field you run into problems with gamut all the time if you don't have a system to handle it. Which can (but don't have to) be aces.

* filmic blender added some output transforms including gamut translations at some point, so this is only partiallly true for the latest versions

t_b_s wrote:I still don't get, what these problem are that "aces solves" but you never had. What's important to understand is that the "standard" color-management configurations, like nuke-default, Clarisse's default and filmic blender* are gamut-agnostic. That means they neither use a wide gamut nor a small gamut, they do no translate between gamuts whatsoever. Which means that the gamut of the system is determined by the device you use to look at the images, which probably uses sRGB/rec709 gamut or is limited to sRGB by the OS. Which gives you the impression you are working in sRGB gamut while you are actually not, it's just the way how you look at it.

If you are working with sRGB source imagery for an sRGB output device, no one would expect that you run into problems with gamut transforms, since you don't need to apply them. Meanwhile every film camera out there shoots to some non-sRGB gamut of its own, that you want to look at on an sRGB/rec709 device and propably want to mix with imagery from other sources, so working in that field you run into problems with gamut all the time if you don't have a system to handle it. Which can (but don't have to) be aces.

* filmic blender added some output transforms including gamut translations at some point, so this is only partiallly true for the latest versions

I understand gamut agnostic as you put it and all the cameras gamut conversion necessities we in gamedev just doesn't have. But it's not a part I am curious about.

I wonder specifically about what many papers about ACES state as a way to reach more photoreal results doing more realistic GI, solving color oversturation etc. Including https://chrisbrejon.com/cg-cinematograp ... stem-aces/
link oddvisionary posted. Those are problems I am talking about.
We are kind of in a middle of discussion about implementing ACES in our game render pipeline and I am just trying to figure-out would it give us some merits or just senseless GPU atmosphere heating .

And one thing is bothering me. Every such paper demonstrates examples of "before" shows some extreme settings, weird things I never seen or get in this gamut agnostic pipeline.

So basically I'd like to see Clarisse comparison screens , ACES vs gamut agnostic as you named it demonstrating something believable. If anyone tried to make such comparison I would be appreciative for sharing