with version 2.82a and up to 2.90 alpha
Recently I had more time to try things out in Blender and I got new contacts via Email asking me questions about Blender & ACES. I am happy to help but I am actually not a 3D Artist so my ability to help is limited. As a result I present some notes of pitfalls that I fell into when trying out Blender & ACES. I found some problems and limitations that occur in the release mentioned above.
Here is the quick list of the limitations I ran into:
- All color images should be EXR files in the colorspace ACEScg – in this way they don’t need any colorspace transform inside Blender.
- Colorspace transforms in Textures (Input – Generic – sRGB Texture) will result in imprecise or sometimes wrong results when the image texture is a 8-Bit file! (the transforms should happen in floating point precision)
- Non-Color image texture files e.g. bump or normal maps need to have the color space set to “raw” (no gamut or gamma mapping) – then there is not problem when using JPG/PNG files
- Blender misses an option to select the OCIO file in the preferences – at the moment you must set the OCIO environment variable before starting Blender.
- The list of colorspaces are not sorted in categories like it is in Nuke for example. The list is so large and long you need a giant screen to see them all and be able to select one with is at the end of the list – as a workaround you can temporally scale down the Resolution Scale smaller than 1.0 in the Interface/Display Preferences.
- Be aware that you are working in a far bigger gamut of ACEScg – I wrote an article called Understanding Gamut with ACES and Blender about this topic.
At the time when I started to explore Blender & ACES there was no color transform available for any images inside Blender. That’s why all the examples that I worked on this website have one thing in common – every HDRI and image texture I converted with Affinity Photo or Nuke to the ACEScg colorspace before I load them into Blender as EXR files.
This way of working removes the need to care and think about color space conversions in Blender. Everything is already in the working space ACEScg and with floating point precision.
There is a general limitation in Blender with 8-Bit images. To keep the memory footprint small they are kept in 8-Bit. I filed a bug report and this is a known issue and will be addressed hopefully in the future.
Imagine you solved a camera from a photo with fspy that you exported as a JPG with the view transform “Output sRGB”. The imported backplate will look wrong an no matter what colorspace as the IDT you set for the backplate in Blender in the camera options. You should select Out_sRGB when your RRT&ODT is sRGB. A value of 1.0 in the backplate would raise to a scene linear light value of 16.xxx. As the buffer is kept at 8-Bit all values are clamped at a value of 1.0. (Sadly even the usage of a EXR backplate in ACEScg is not supported at the moment.)
The 8-Bit limit is also true for textures! Image data after a colorspace transform can’t be stored in 8-Bit. So you should avoid any other textures than EXR files when working in Blender & ACES until this is solved. Check the following images – the Compositor module handles this well – the Texture module not.
Blackbody Shader is limited to sRGB primaries – and workaround for ACES
- ACES-1.2 Colourimetric Displays Edition by Troy James Sobotka (I was pointed to this link that lists limitations when Blender is set to ACES. Among other problems I read about the problem with the Blackbody Shader when using ACES and I tried that out below.
For an upcoming article I was testing out the blackbody shader in Blender 2.90 alpha with standard sRGB, Filmic and ACES.
I setup a small Blender scene with a simple model of three “LED” lightbulbs with a blackbody shader of 2700K plugged into an Emission shader that multiplies the color value by 100.
The HDRI I used was one of the Ricoh Theta-S “good ones” that I tested here (far down on the page) before.
Then I loaded the Blender scene again but this time into an ACES environment and adjusted only the color space of the color checker texture and the pre converted HDRI (ACEScg). The blackbody shader I didn’t touch.
As a workaround I rendered in the Blender standard sRGB scene the 2700K blackbody shader on a cube with an emission shader only. In Nuke I converted the render to ACEScg and exported a constant texture with the converted 2700K color value in ACEScg. Now apart from the different tone mapping between Filmic and the ACES RRT&ODT the results are identical. Hopefully in a future version of Blender the Blackbody shader will be colorspace aware. This workaround is tedious.