Change Details

**Blender Version** Broken: 3.0 and older Worked: none 1. ACES 2065-1 textures/images show a color shift with the default OCIO config and colorspace set to "Linear ACES". 2. OCIO configs that use ocio builtin transforms and define the aces_interchange colorspace as ACES 2065-1 show opposite color shift with "sky texture". I noticed this problem since a few versions of Blender and it also persists in 3.0. I took a look at it myself and I think I found the source of the issue. The xyz_to_aces transform uses a matrix from xyz-d60 to ACES, but is assumed to be xyz-E to ACES. Subsequently a E to D65 white point adaptation is applied, which causes a color shift. Compare xyz_to_aces.spimtx from the default OCIO config to the [[ https://github.com/colour-science/OpenColorIO-Configs/blob/master/aces_1.2/config.ocio | ACES 1.2 config ]] (line 2431) xyz-d60 to ACES transform. This [[ http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html | source ]] lists methods for whitepoint adaptation and it can be seen that in fact an D65 to E transform is used by the default OCIO config. The same error is made in Blender code when converting from the aces_interchange to xyz-d65 e.g. for the sky texture, as documented in this [[ https://developer.blender.org/rCad4b6c40f1fa584f425937838b8aaf66f9ad1168 | commit ]]. This double error cancels itself out with the default config (sky texture xyz is wrongly converted to aces and then the inverted error from aces to scene linear), which means the sky texture works correctly with the default config. Though it interprets ACES 2065-1 textures/images wrongly and if the colorspace is defined correctly with a different config, this results in a wrong sky texture. This Blendfile contains color checkers for ACES 2065-1 and Linear Rec.709 (confusingly named srgb) that can illustrate the color shift. The config, I made myself, using the builtin-transforms from OCIO and therefore doesn't need external LUTs. It shows correct behavior with the color checkers, but produces a color shift of the sky texture. You can of course also use the official ACES 1.2 OCIO config, which is linked above, but this requires the download of their provided LUTs aswell. {F12837691} {F12837705} Possible fix: Change the white point adaptation in default OCIO config and Blender code from xyz-D65-to-E to xyz-D65-to-D60. The Bradford adaptation seems to be the most commonly used nowadays.

**Blender Version** Broken: 3.0 and older Worked: none 1. `ACES 2065-1` textures/images show a color shift with the default OCIO config and colorspace set to "Linear ACES". 2. OCIO configs that use ocio builtin transforms and define the aces_interchange colorspace as `ACES 2065-1` show opposite color shift with "sky texture". I noticed this problem since a few versions of Blender and it also persists in 3.0. I took a look at it myself and I think I found the source of the issue. The `xyz_to_aces` transform uses a matrix from `xyz`-`d60` to `ACES`, but is assumed to be `xyz-E` to `ACES`. Subsequently a `E` to `D65` white point adaptation is applied, which causes a color shift. Compare `xyz_to_aces.spimtx` from the default OCIO config to the [[ https://github.com/colour-science/OpenColorIO-Configs/blob/master/aces_1.2/config.ocio | ACES 1.2 config ]] (line 2431) `xyz`-`d60` to `ACES` transform. This [[ http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html | source ]] lists methods for whitepoint adaptation and it can be seen that in fact an `D65` to `E` transform is used by the default OCIO config. The same error is made in Blender code when converting from the `aces_interchange` to `xyz`-`d65` e.g. for the sky texture, as documented in this [[ https://developer.blender.org/rCad4b6c40f1fa584f425937838b8aaf66f9ad1168 | commit ]]. This double error cancels itself out with the default config (sky texture `xyz` is wrongly converted to aces and then the inverted error from aces to scene linear), which means the sky texture works correctly with the default config. Though it interprets `ACES 2065-1` textures/images wrongly and if the colorspace is defined correctly with a different config, this results in a wrong sky texture. This Blendfile contains color checkers for `ACES 2065-1` and `Linear Rec.709` (confusingly named srgb) that can illustrate the color shift. The config, I made myself, using the builtin-transforms from OCIO and therefore doesn't need external LUTs. It shows correct behavior with the color checkers, but produces a color shift of the sky texture. You can of course also use the official ACES 1.2 OCIO config, which is linked above, but this requires the download of their provided LUTs aswell. {F12837691} {F12837705} Possible fix: Change the white point adaptation in default OCIO config and Blender code from xyz-D65-to-E to xyz-D65-to-D60. The Bradford adaptation seems to be the most commonly used nowadays.

**Blender Version** Broken: 3.0 and older Worked: none 1. `ACES 2065-1` textures/images show a color shift with the default OCIO config and colorspace set to "Linear ACES". 2. OCIO configs that use ocio builtin transforms and define the aces_interchange colorspace as `ACES 2065-1` show opposite color shift with "sky texture". I noticed this problem since a few versions of Blender and it also persists in 3.0. I took a look at it myself and I think I found the source of the issue. The `xyz_to_aces` transform uses a matrix from xyz-d60`xyz`-`d60` to `ACES`, but is assumed to be `xyz-E` to `ACES. `. Subsequently a E`E` to D65`D65` white point adaptation is applied, which causes a color shift. Compare `xyz_to_aces.spimtx` from the default OCIO config to the [[ https://github.com/colour-science/OpenColorIO-Configs/blob/master/aces_1.2/config.ocio | ACES 1.2 config ]] (line 2431) xyz-d60`xyz`-`d60` to `ACES` transform. This [[ http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html | source ]] lists methods for whitepoint adaptation and it can be seen that in fact an D65`D65` to E`E` transform is used by the default OCIO config. The same error is made in Blender code when converting from the `aces_interchange` to xyz-d65 e`xyz`-`d65` e.g. for the sky texture, as documented in this [[ https://developer.blender.org/rCad4b6c40f1fa584f425937838b8aaf66f9ad1168 | commit ]]. This double error cancels itself out with the default config (sky texture xyz`xyz` is wrongly converted to aces and then the inverted error from aces to scene linear), which means the sky texture works correctly with the default config. Though it interprets `ACES 2065-1` textures/images wrongly and if the colorspace is defined correctly with a different config, this results in a wrong sky texture. This Blendfile contains color checkers for `ACES 2065-1` and `Linear Rec.709` (confusingly named srgb) that can illustrate the color shift. The config, I made myself, using the builtin-transforms from OCIO and therefore doesn't need external LUTs. It shows correct behavior with the color checkers, but produces a color shift of the sky texture. You can of course also use the official ACES 1.2 OCIO config, which is linked above, but this requires the download of their provided LUTs aswell. {F12837691} {F12837705} Possible fix: Change the white point adaptation in default OCIO config and Blender code from xyz-D65-to-E to xyz-D65-to-D60. The Bradford adaptation seems to be the most commonly used nowadays.