Blender OCIO ACES 1.2 Texture ColorTransform ignored - works in Compositor #76680

New Issue

Daniel Brylka · 2020-05-12T13:57:55+02:00

Daniel Brylka commented

2020-05-12 13:57:55 +02:00

MBP 15" (2018)
Operating system: MACOS 10.5.4 Catalina
Graphics card: Radeon Pro 560X
Blender Version

Broken: Version 2.82a, 2.83 beta and 2.90 alpha (12th of May2020)

Short description of error
I setup up Blender according my little how-to on my website
https://www.toodee.de/?page_id=1720
The ACES IDT sRGB texture is taking off the sRGB (gamma), linearizes the texture and maps the sRGB gamut into the ACEScg gamut.
A JPG/PNG 8-Bit Texture File with a value of 1 will map it to 1.0 in scene linear.
To see a texture in ACES like it looked like in Photoshop for example you need to use the inverse RRT&ODT view transform. The IDT you choose is then Output_sRGB. This maps a texture value of 1 to 16.xxx in scene linear.
I am aware that this is the wrong method to use textures in ACES - this is a regular mistake when working with ACES and I wanted to write an article about it on my website and clarify the problem.

The Blender Compositor is actually working as expected. In the demo scene I use the texture two times with different IDTs (sRGB-Texture and OutPut sRGB - for comparison I also added the same texture as an EXR file.
Please check the Compositor and plug one or the other image to the gain 10% color correction to show the high scene linear values.

In the Shading tab I have the image texture window sized big and select the different image texture (2x JPG with two IDTs selected and one EXR file) - use right click to sample the texture values in the image view.
Only the EXR file shows actually higher values than one. Both JPG textures with the two IDTs selected are clipping at 1.0.
Blender_282_OCIO_Texture_ColorTransform_bug.blend.zip

MBP 15" (2018) Operating system: MACOS 10.5.4 Catalina Graphics card: Radeon Pro 560X **Blender Version** Broken: Version 2.82a, 2.83 beta and 2.90 alpha (12th of May2020) **Short description of error** I setup up Blender according my little how-to on my website https://www.toodee.de/?page_id=1720 The ACES IDT sRGB texture is taking off the sRGB (gamma), linearizes the texture and maps the sRGB gamut into the ACEScg gamut. A JPG/PNG 8-Bit Texture File with a value of 1 will map it to 1.0 in scene linear. To see a texture in ACES like it looked like in Photoshop for example you need to use the inverse RRT&ODT view transform. The IDT you choose is then Output_sRGB. This maps a texture value of 1 to 16.xxx in scene linear. I am aware that this is the wrong method to use textures in ACES - this is a regular mistake when working with ACES and I wanted to write an article about it on my website and clarify the problem. The Blender Compositor is actually working as expected. In the demo scene I use the texture two times with different IDTs (sRGB-Texture and OutPut sRGB - for comparison I also added the same texture as an EXR file. Please check the Compositor and plug one or the other image to the gain 10% color correction to show the high scene linear values. In the Shading tab I have the image texture window sized big and select the different image texture (2x JPG with two IDTs selected and one EXR file) - use right click to sample the texture values in the image view. Only the EXR file shows actually higher values than one. Both JPG textures with the two IDTs selected are clipping at 1.0. [Blender_282_OCIO_Texture_ColorTransform_bug.blend.zip](https://archive.blender.org/developer/F8530557/Blender_282_OCIO_Texture_ColorTransform_bug.blend.zip)

Daniel Brylka commented

2020-05-12 13:57:55 +02:00

Added subscriber: @DanielBrylka

Evan Wilson commented

2020-05-12 14:37:31 +02:00

Added subscribers: @troy_s, @EAW

Evan Wilson commented

2020-05-12 14:37:31 +02:00

Checking. @troy_s requesting you eyes on this since you know the most about where Blender currently fails to use OCIO for color management.

Brecht Van Lommel commented

2020-05-12 14:52:40 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2020-05-12 14:52:40 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Brecht Van Lommel commented

2020-05-12 14:52:40 +02:00

This is a known issue. Textures in Blender will be stored in 8bit memory if the source file is 8bit, to keep memory usage predictable.

We can implement a way to detect transforms like this where this does not work well and values higher than 1.0 need to be represented, and switch to half float then.

This is a known issue. Textures in Blender will be stored in 8bit memory if the source file is 8bit, to keep memory usage predictable. We can implement a way to detect transforms like this where this does not work well and values higher than 1.0 need to be represented, and switch to half float then.

Troy Sobotka commented

2020-05-12 18:29:28 +02:00

Only thing I'd add to @brecht's comment is that 8 bit textures are always woeful.

Why? Because they are compressed according to exactly one "idealized" emission from a display. That is, if you take that assumption into a path tracing / light transport system, that assumption falls apart. Change exposure by a single stop and you've pushed the result into the middle of a posterized set of values according to the compression.

There are two classes of imagery here:

Normalized albedo, representing portions of a whole from 0% to 100% and the meaning is derived from that "whole" range.
Emissions, from extremely low to extremely large values, where meaning is derived from the ratios between values.

Lower bit depth can represent both, with proper pixel management handling, but will always be subject to the issues noted above regarding 8 bit.

Only thing I'd add to @brecht's comment is that 8 bit textures are *always* woeful. Why? Because they are compressed according to exactly one "idealized" emission from a display. That is, if you take that assumption into a path tracing / light transport system, that assumption falls apart. Change exposure by a single stop and you've pushed the result into the middle of a posterized set of values according to the compression. There are two classes of imagery here: 1. Normalized albedo, representing portions of a whole from 0% to 100% and the meaning is derived from that "whole" range. 2. Emissions, from extremely low to extremely large values, where meaning is derived from the ratios between values. Lower bit depth can represent both, with proper pixel management handling, but will always be subject to the issues noted above regarding 8 bit.

Daniel Brylka commented

2020-05-12 19:56:40 +02:00

I guess colorspace transforms should to be handled in floating point precision anyways?

Troy Sobotka commented

2020-05-13 17:11:47 +02:00

They do and are. I believe the issue here is GPU concerns.

It might be wise to assert that the transforms work properly, even if at an inappropriate depth, than not. This issue would appear only to individuals and pipes that are aware how to negotiate it and what causes it.

They do and are. I believe the issue here is GPU concerns. It might be wise to assert that the transforms work properly, even if at an inappropriate depth, than not. This issue would appear only to individuals and pipes that are aware how to negotiate it and what causes it.

Pauan commented

2021-09-29 21:56:51 +02:00

Added subscriber: @pauanyu_blender

Pauan commented

2021-09-29 21:56:51 +02:00

I think I just ran into this issue... but I want to confirm if it's the same.

I imported this image file into Blender:

I am using ACES 1.2 from this repository, and I set the image color space to Output - sRGB.

The texture should look identical to the original image, and I confirmed that it is identical in ociodisplay.

However, in Blender it looks terrible, there is a lot of clipping and saturation problems:

I run into this problem with quite a few images, it seems to happen especially with lighter skin tones.

I attached a .blend test file. Is this problem caused by the 8-bit clipping, or is it something else?

P.S. I am aware that you are normally supposed to import textures with Utility - sRGB - Texture, however in some rare cases it is correct to use Output - sRGB.

ACES Test.blend

I think I just ran into this issue... but I want to confirm if it's the same. I imported this image file into Blender: ![Expected.jpg](https://archive.blender.org/developer/F10677146/Expected.jpg) I am using ACES 1.2 [from this repository](https://github.com/colour-science/OpenColorIO-Configs), and I set the image color space to `Output - sRGB`. The texture *should* look identical to the original image, and I confirmed that it *is* identical in `ociodisplay`. However, in Blender it looks terrible, there is a lot of clipping and saturation problems: ![Result.png](https://archive.blender.org/developer/F10677134/Result.png) I run into this problem with quite a few images, it seems to happen especially with lighter skin tones. I attached a `.blend` test file. Is this problem caused by the 8-bit clipping, or is it something else? P.S. I am aware that you are normally supposed to import textures with `Utility - sRGB - Texture`, however in some rare cases it is correct to use `Output - sRGB`. [ACES Test.blend](https://archive.blender.org/developer/F10677160/ACES_Test.blend)

Daniel Brylka commented

2021-09-30 09:42:14 +02:00

I just tried your file out in Blender 3.00 alpha with ACES 1.2 from the same origin and the I can confirm that it still the same issue.

An 8-Bit JPG file shows this behavior, regardless of its image content.

You can work around this issue by converting your 8-Bit JPG file to a 16-Bit Tiff for example.
Blender seems to recognize the 16-bit file and the color transforms work as expected.
Still these kinds of color transforms should happen in floating point precision.

I just tried your file out in Blender 3.00 alpha with ACES 1.2 from the same origin and the I can confirm that it still the same issue. An 8-Bit JPG file shows this behavior, regardless of its image content. You can work around this issue by converting your 8-Bit JPG file to a 16-Bit Tiff for example. Blender seems to recognize the 16-bit file and the color transforms work as expected. Still these kinds of color transforms should happen in floating point precision. ![snap3.jpg](https://archive.blender.org/developer/F10687416/snap3.jpg) ![snap2.jpg](https://archive.blender.org/developer/F10687415/snap2.jpg) ![snap1.jpg](https://archive.blender.org/developer/F10687414/snap1.jpg)

Pauan commented

2021-09-30 10:29:18 +02:00

@DanielBrylka Thanks, I also confirmed that using EXR textures works in Blender 2.93.2, so it is the same 8-bit clipping bug.

Pauan commented

2021-09-30 16:22:25 +02:00

I did some more experiments. Blender supports 7 different image formats which are 16-bit.

Using EXR doesn't work very well because you must convert the image from gamma to linear, so it only works if the image is already EXR to begin with.

I think the best option is to use 16-bit PNG. This gives identical results as TIFF, but with far smaller file sizes.

It's very easy to use GIMP to convert an existing image into 16-bit PNG:

Open the image in GIMP
Select Image -> Precision -> 16 bit integer
Leave the Gamma as Perceptual gamma (sRGB)
Click Convert
File -> Export As... and save the image as .png

This is a decent workaround until this bug is fixed.

I did some more experiments. Blender supports [7 different image formats which are 16-bit](https://docs.blender.org/manual/en/latest/files/media/image_formats.html). Using EXR doesn't work very well because you must convert the image from gamma to linear, so it only works if the image is already EXR to begin with. I think the best option is to use 16-bit PNG. This gives identical results as TIFF, but with *far* smaller file sizes. It's very easy to use GIMP to convert an existing image into 16-bit PNG: 1. Open the image in GIMP 2. Select `Image` -> `Precision` -> `16 bit integer` 3. Leave the `Gamma` as `Perceptual gamma (sRGB)` 4. Click `Convert` 5. `File` -> `Export As...` and save the image as `.png` This is a decent workaround until this bug is fixed.

Daniel Brylka commented

2021-09-30 18:04:14 +02:00

Hi Pauan,

please check this link about TIFF vs. PNG.
https://twitter.com/andrewpprice/status/1440498403633291274?s=12

TIFF should be the better option for the work around until the issue is fixed.
Autodesk Flame has an image processing node where you can change the bit-depth of every source.
A simple checkbox in the texture image node in Blender could promote an 8-bit buffer to float if you click on it.

Hi Pauan, please check this link about TIFF vs. PNG. https://twitter.com/andrewpprice/status/1440498403633291274?s=12 TIFF should be the better option for the work around until the issue is fixed. Autodesk Flame has an image processing node where you can change the bit-depth of every source. A simple checkbox in the texture image node in Blender could promote an 8-bit buffer to float if you click on it.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Blender OCIO ACES 1.2 Texture ColorTransform ignored - works in Compositor #76680