8 Bit Images Marked as Filmic sRGB in Image Editor's Right Click Inspection Discrepancy with Compositor Straight output #98623

New Issue

Zijun Zhou · 2022-06-06T07:53:42+02:00

Zijun Zhou commented

2022-06-06 07:53:42 +02:00

System Information
Operating system: Windows-10-10.0.22000-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3050 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.15

Blender Version
Broken: version: 3.3.0 Alpha, branch: master, commit date: 2022-06-04 16:39, hash: e230ccaf8c
Worked: None

Short description of error
I guess this is somehow related to this: #94421 but since the original report's steps did not mention this, I am opening a new report.

Here is an image marked as Filmic sRGB, what happens here is that the closed domain (0 to 1) image is being inverse Filmic into Open Domain (0 to infinity, but actually to about 16 because of Filmic dynamic range.) But when you load it up in Image Editor and right click to inspect the data, you will see although you can view the image properly, the data shown on the lower left corner is still maximum 1.

But Compositor Straight Output is properly 0 to about 16:

If you save it as 16 bit PNG it works as expected:

Exact steps for others to reproduce the error

Download this file and load it:
JPG Marked as Filmic sRGB Right Click Inspection Bug.blend
Right click on the sweeps and see how the values at the lower left are stuck below 1
Go to the compositor, load the image in the image node and ctrl shift LMB to use viewer node, go back to image editor and load the viewer node in it.
Right click on the sweeps and see how the values at the lower left are now 0 to about 16.

**System Information** Operating system: Windows-10-10.0.22000-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3050 Laptop GPU/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 512.15 **Blender Version** Broken: version: 3.3.0 Alpha, branch: master, commit date: 2022-06-04 16:39, hash: `e230ccaf8c` Worked: None **Short description of error** I guess this is somehow related to this: #94421 but since the original report's steps did not mention this, I am opening a new report. Here is an image marked as Filmic sRGB, what happens here is that the closed domain (0 to 1) image is being inverse Filmic into Open Domain (0 to infinity, but actually to about 16 because of Filmic dynamic range.) But when you load it up in Image Editor and right click to inspect the data, you will see although you can view the image properly, the data shown on the lower left corner is still maximum 1. ![image.png](https://archive.blender.org/developer/F13134581/image.png) But Compositor Straight Output is properly 0 to about 16: ![image.png](https://archive.blender.org/developer/F13249805/image.png) If you save it as 16 bit PNG it works as expected: ![image.png](https://archive.blender.org/developer/F13134588/image.png) **Exact steps for others to reproduce the error** 1. Download this file and load it: [JPG Marked as Filmic sRGB Right Click Inspection Bug.blend](https://archive.blender.org/developer/F13134586/JPG_Marked_as_Filmic_sRGB_Right_Click_Inspection_Bug.blend) 2. Right click on the sweeps and see how the values at the lower left are stuck below 1 3. Go to the compositor, load the image in the image node and ctrl shift LMB to use viewer node, go back to image editor and load the viewer node in it. 4. Right click on the sweeps and see how the values at the lower left are now 0 to about 16.

Zijun Zhou commented

2022-06-06 07:53:42 +02:00

Added subscriber: @Eary

Zijun Zhou commented

2022-06-06 07:54:59 +02:00

If I remember correctly Blender's Color Management is under Render & Cycles module.

If I remember correctly Blender's Color Management is under `Render & Cycles` module.

Steffen Dünner commented

2022-06-06 13:18:50 +02:00

Added subscriber: @SteffenD

Germano Cavalcante commented

2022-06-06 21:20:55 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2022-06-06 21:20:55 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Germano Cavalcante commented

2022-06-06 21:20:55 +02:00

I may be misunderstanding but if I'm not mistaken the value indicated in the second image is not the value converted to sRGB. It is the original Linear value.
The value in sRGB would be the one after the "CM" label (I think it's CM from Color Management).
So I'm not seeing a bug there.

The third image shows values that extrapolate the limits [0.0, 1.0]. It's as if the first two images are clamped and the third is not.
I saved to 16-bit PNG but I can't replicate this problem.

Can you give us more clear instructions on how to reproduce this problem?

I may be misunderstanding but if I'm not mistaken the value indicated in the second image is not the value converted to sRGB. It is the original Linear value. The value in sRGB would be the one after the "CM" label (I think it's CM from Color Management). So I'm not seeing a bug there. The third image shows values that extrapolate the limits [0.0, 1.0]. It's as if the first two images are clamped and the third is not. I saved to 16-bit PNG but I can't replicate this problem. Can you give us more clear instructions on how to reproduce this problem?

Steffen Dünner commented

2022-06-06 21:41:34 +02:00

If you load this 8-bit JPEG into the Compositor (with Filmic sRGB as color space), you're getting values up to 16.x again.

I guess the Image Editor clamps the values to 1.0 if it reads "Byte" images which normally only ever go up to 1.0 while the Compositor always uses float for its processing all the time.

If you load this 8-bit JPEG into the Compositor (with Filmic sRGB as color space), you're getting values up to 16.x again. ![image.png](https://archive.blender.org/developer/F13135456/image.png) I guess the Image Editor clamps the values to 1.0 if it reads "Byte" images which normally only ever go up to 1.0 while the Compositor always uses float for its processing all the time.

Zijun Zhou commented

2022-06-06 22:02:25 +02:00

In #98623#1369450, @mano-wii wrote:
The value in sRGB would be the one after the "CM" label (I think it's CM from Color Management).

The one in CM is the value after view transform, not the open domain linear value within the software.

In #98623#1369450, @mano-wii wrote:
I may be misunderstanding but if I'm not mistaken the value indicated in the second image is not the value converted to sRGB. It is the original Linear value.

It is closed domain (0 to 1) sRGB, the second image is there to compare with the first one, if you mark the image to be different colorspace, the values on the left side would change, but Filmic sRGB shows the same values as sRGB, which mean it is bugged.

Blender uses OCIO's scene linear workflow, which means you mark it as Filmic sRGB, the texture will be transformed from closed domain Filmic sRGB encoding to the open domain working space upon import, it means the reverse Filmic transform will be applied. In this case the closed domain Filmic sRGB image should be transformed with inverse Filmic into Open Domain (0 to infinity, though because of Filmic's dynamic range limits, it is actually 0 to about 16)

Therefore the value shown at the lower left corner should already be the value mapped to open domain. As you can see the third image with 16 bit PNG works properly.

In #98623#1369450, @mano-wii wrote:
I may be misunderstanding but if I'm not mistaken the value indicated in the second image is not the value converted to sRGB. It is the original Linear value.

It is important to note that not everything can be expressed under the umbrella term of Linear, for example the closed domain state and the open domain state are ignored if you just call it linear.

The original image was encoded by Filmic sRGB encoding (transform open domain data into forming a closed domain image), designed to be decoded by the sRGB transfer function (closed domain values will remain closed domain). It is important to realize that you can have Open Domain Linear as well as Closed Domain Linear. The data flowing in the compositor that are larger than 1, those are open domain. The values under CM section? Those are closed domain image values.

> In #98623#1369450, @mano-wii wrote: > The value in sRGB would be the one after the "CM" label (I think it's CM from Color Management). The one in CM is the value after view transform, not the open domain linear value within the software. > In #98623#1369450, @mano-wii wrote: > I may be misunderstanding but if I'm not mistaken the value indicated in the second image is not the value converted to sRGB. It is the original Linear value. It is closed domain (0 to 1) sRGB, the second image is there to compare with the first one, if you mark the image to be different colorspace, the values on the left side would change, but Filmic sRGB shows the same values as sRGB, which mean it is bugged. Blender uses OCIO's scene linear workflow, which means you mark it as Filmic sRGB, the texture will be transformed from closed domain Filmic sRGB encoding to the open domain working space upon import, it means the reverse Filmic transform will be applied. In this case the closed domain Filmic sRGB image should be transformed with inverse Filmic into Open Domain (0 to infinity, though because of Filmic's dynamic range limits, it is actually 0 to about 16) Therefore the value shown at the lower left corner should already be the value mapped to open domain. As you can see the third image with 16 bit PNG works properly. > In #98623#1369450, @mano-wii wrote: > I may be misunderstanding but if I'm not mistaken the value indicated in the second image is not the value converted to sRGB. It is the original Linear value. It is important to note that not everything can be expressed under the umbrella term of `Linear`, for example the closed domain state and the open domain state are ignored if you just call it `linear`. The original image was encoded by Filmic sRGB encoding (transform open domain data into forming a closed domain image), designed to be decoded by the sRGB transfer function (closed domain values will remain closed domain). It is important to realize that you can have Open Domain Linear as well as Closed Domain Linear. The data flowing in the compositor that are larger than 1, those are open domain. The values under CM section? Those are closed domain image values.

Zijun Zhou changed title from ~~8 Bit Images Marked as Filmic sRGB in Image Editor's Right Click Inspection Still Shows Data As If It is sRGB~~ to 8 Bit Images Marked as Filmic sRGB in Image Editor's Right Click Inspection Discrepancy with Compositor Straight output

2022-07-02 18:23:36 +02:00

Zijun Zhou commented

2022-07-02 18:24:16 +02:00

Changed the report description to make it easier to understand, need to at least get this report comfirmed.

Germano Cavalcante commented

2022-08-17 20:11:20 +02:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Omar Emara commented

2022-08-18 10:57:56 +02:00

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

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

8 Bit Images Marked as Filmic sRGB in Image Editor's Right Click Inspection Discrepancy with Compositor Straight output #98623