Limitations with version 2.83 and up to 2.90.3 alpha
Today (12th of May 2020) I filed a bug or limitation when working with 8-Bit textures in Blender that need a colorspace transform. So I added some notes of other limitations I ran into in the last weeks and months while exploring Blender & ACES:
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.
First test of the “TooDee ColorBars” for ACES with FCPX
After a long time I added a new entry about FCPX. Before I reached here I was checking out first the color processing pipeline of FCPX in the default “Standard Rec.709” library and also the Rec.709 output in a Wide Gamut HDR library.
The next article is finished. It belongs to “Part 2” of the ColorChecker series. This is a deeper comparison of five different ways I tried to get the “best” HDRI result using different tools to process the RAW images.
I am “afraid” I have to continue doing more tests. Read it here and find out why.