Colormanagement issue with UV/Image Editor and 32 bit float textures #28193

New Issue

Tobias Oelgarte · 2011-08-09T13:51:26+02:00

Tobias Oelgarte commented

2011-08-09 13:51:26 +02:00

%%%For 32 bit textures the colormanagement has an issue. Initially the image is displayed in linear color space inside the uv/image editor. This means that what you see is equal to what is stored. (Black = 0.0, Gray = 0.5, White = 1.0) But as soon you save the image and reload it the image will be displayed inside non linear color space. (Black = 0.0, Gray = 0.737, White > 1.0 [out of displayed bounds]). But the stored values are still the same. (0.0, 0.5, 1.0)

In case you draw a displacement map everything looks distorted (Curve-Option for display does not help). Additionally you will have a drastic performance decrease while painting (fluid -> ugly/jumpy) and the colorpicker will use the the non linear colors, which makes accurate painting impossible.

Thats it about the things i noticed. Now the steps to reproduce it in a current version:

Open a new file. Make sure "colormanagement" is enabled inside the render-tab.
Create a new image inside the UV/Image Editor with "32 bit float" enabled.
Draw a white line (1.0) and a gray line (0.5). Rest should be black as the default. At the display it will be [255,255,255] and [127,127,127].
Save the image in OpenEXR format.
Reload the image
View the same image and notice that it is displayed with non linear colors. Internally still (0.0, 0.5, 1.0).

Now you should notice that the image isn't displayed linear anymore. The gray will be a lot brighter and the white is even out of the current display region. From now on there is no simple way to get back to the linear view (A) and the drawing performance will decrease (drastically on my system) (B).

(A) Switching between colormanagement (check or unchecked inside "Render"-Tab) enabled or disabled will not change anything. It is still displayed as managed. Especially if you draw displacement/bump maps this is very painful, since they are used in linear space for modifiers. They still see (0.0, 0.5, 1.0) but you will draw in (0.0, 0.737, >1.0). There should at least be an option to disable color management for such tasks. Currently nothing will do the job. The only workaround i found was to disable colormanagement, save the file and reload it, to get back to linear behavior and normal speed.

(B) As soon this mode is "ON" (intentionally or not) the performance suffers strongly. My guess is that the colors of the brush will be converted from non linear to linear, then applied to the linear stored image and after that the image is converted back to non linear values displayed inside the viewport (without any hardware acceleration). Maybe it should convert the image to non linear and perform the drawing without conversion, while converting it back for saving. At least there should be an option for linear mode without the performance issues.

I hope this can be fixed easily, since it's a really hard life to do linear things in a non linear space. :-)%%%

%%%For 32 bit textures the colormanagement has an issue. Initially the image is displayed in linear color space inside the uv/image editor. This means that what you see is equal to what is stored. (Black = 0.0, Gray = 0.5, White = 1.0) But as soon you save the image and reload it the image will be displayed inside non linear color space. (Black = 0.0, Gray = 0.737, White > 1.0 [out of displayed bounds]). But the stored values are still the same. (0.0, 0.5, 1.0) In case you draw a displacement map everything looks distorted (Curve-Option for display does not help). Additionally you will have a drastic performance decrease while painting (fluid -> ugly/jumpy) and the colorpicker will use the the non linear colors, which makes accurate painting impossible. Thats it about the things i noticed. Now the steps to reproduce it in a current version: 1. Open a new file. Make sure "colormanagement" is enabled inside the render-tab. 2. Create a new image inside the UV/Image Editor with "32 bit float" enabled. 3. Draw a white line (1.0) and a gray line (0.5). Rest should be black as the default. At the display it will be [255,255,255] and [127,127,127]. 4. Save the image in OpenEXR format. 5. Reload the image 6. View the same image and notice that it is displayed with non linear colors. Internally still (0.0, 0.5, 1.0). Now you should notice that the image isn't displayed linear anymore. The gray will be a lot brighter and the white is even out of the current display region. From now on there is no simple way to get back to the linear view (A) and the drawing performance will decrease (drastically on my system) (B). (A) Switching between colormanagement (check or unchecked inside "Render"-Tab) enabled or disabled will not change anything. It is still displayed as managed. Especially if you draw displacement/bump maps this is very painful, since they are used in linear space for modifiers. They still see (0.0, 0.5, 1.0) but you will draw in (0.0, 0.737, >1.0). There should at least be an option to disable color management for such tasks. Currently nothing will do the job. The only workaround i found was to disable colormanagement, save the file and reload it, to get back to linear behavior and normal speed. (B) As soon this mode is "ON" (intentionally or not) the performance suffers strongly. My guess is that the colors of the brush will be converted from non linear to linear, then applied to the linear stored image and after that the image is converted back to non linear values displayed inside the viewport (without any hardware acceleration). Maybe it should convert the image to non linear and perform the drawing without conversion, while converting it back for saving. At least there should be an option for linear mode without the performance issues. I hope this can be fixed easily, since it's a really hard life to do linear things in a non linear space. :-)%%%

Tobias Oelgarte commented

2011-08-09 13:51:26 +02:00

Changed status to: 'Open'

Antonis Ryakiotakis commented

2011-11-29 19:36:42 +01:00

%%%Hi, this is a very simple issue that I made a rejected fix for a while back. Actually setting the linear profile flag to imbuf whenever we allocate a float buffer will solve the issue since the exr saving code will take the flag and do the correct operation. I don't know if this approach is correct though.%%%

Antonis Ryakiotakis commented

2011-11-29 19:45:15 +01:00

%%%About the performance drop: This happens because loading from exr actually sets the aforementioned flag and makes color management conversion code to kick in. There is quite some debateon how to solve this involving a different representation of colors internally and open color io integration among others. We'll have to wait and see where the consensus takes this.%%%

Antonis Ryakiotakis commented

2011-12-11 18:30:02 +01:00

%%%Attached the initial patch for this issue. It can be viewed in Backward Relations tab%%%

Sergey Sharybin commented

2012-04-03 15:29:22 +02:00

%%%There were some fixes made in this area recently, will look into this report later.%%%

Troy Sobotka commented

2012-04-15 22:07:24 +02:00

%%%Three points:

This seems similar to a bug I've posted here http://projects.blender.org/tracker/?func=detail&aid=27986&group_id=9&atid=498. Not 100% certain.
The sRGB linearization was originally a repeating function call to plenty of exponent and multiplies per pixel. It is now a 1D LUT which should result in ~50% performance gain during drawing operations at last test.
The current viewport GL code in source/blender/editors/space_image/image_draw.c(546) can be made to draw directly from float buffers, but is disabled (with a comment regarding legacy ATI cards.) Should this code path be enabled, I'd suspect we could see a performance gain. At last test, it seemed to be fine.

%%%

%%%Three points: 1) This seems similar to a bug I've posted here http://projects.blender.org/tracker/?func=detail&aid=27986&group_id=9&atid=498. Not 100% certain. 2) The sRGB linearization was originally a repeating function call to plenty of exponent and multiplies per pixel. It is now a 1D LUT which should result in ~50% performance gain during drawing operations at last test. 3) The current viewport GL code in source/blender/editors/space_image/image_draw.c(546) can be made to draw directly from float buffers, but is disabled (with a comment regarding legacy ATI cards.) Should this code path be enabled, I'd suspect we could see a performance gain. At last test, it seemed to be fine. %%%

Sergey Sharybin commented

2012-05-27 16:41:57 +02:00

%%%Actually that was caused by incorrect profile set for new image. I believe that this was fixed in svn rev47054.
So thanks for the report, will close it now.%%%

%%%Actually that was caused by incorrect profile set for new image. I believe that this was fixed in svn rev47054. So thanks for the report, will close it now.%%%

Sergey Sharybin commented

2012-05-27 16:41:57 +02:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2012-05-27 16:41:57 +02:00

Tobias Oelgarte commented

2012-05-28 00:43:31 +02:00

%%%Still not really fixed. The values are displayed correctly, but the internally used values are wrong. If i paint with gray (0.5) then it is displayed as #7f7f7f which is correct and the color picker also works that way. But it corresponds to the value 0.24. It is extremely hard to draw and view bump/displacement maps that way. gray is only a fourth as high as white. Ideally it should be half as high.

Displayed: 0, 0.5, 1.0, ...
Values: 0, 0.24, 1.0, ...

Just draw a line with r=g=b=0,5 inside the editor, leave the paint mode and do a left click on the line. You will see that the colors do not match the values. No color management for bumpmap editing please. It just sucks and is unusable. %%%

%%%Still not really fixed. The values are displayed correctly, but the internally used values are wrong. If i paint with gray (0.5) then it is displayed as #7f7f7f which is correct and the color picker also works that way. But it corresponds to the value 0.24. It is extremely hard to draw and view bump/displacement maps that way. gray is only a fourth as high as white. Ideally it should be half as high. Displayed: 0, 0.5, 1.0, ... Values: 0, 0.24, 1.0, ... Just draw a line with r=g=b=0,5 inside the editor, leave the paint mode and do a left click on the line. You will see that the colors do not match the values. No color management for bumpmap editing please. It just sucks and is unusable. %%%

Sergey Sharybin commented

2012-05-28 12:28:05 +02:00

%%%Well, that's kind of different issue which is more about clear separation of file/working/display color profiles. We're workingion this in ocio branch (http://wiki.blender.org/index.php/Dev:Source/Image/OpenColorIO).
For now wouldn't consider inconsistent of drawing bump maps as a bug, it's more a TODO which hopefully would be resolved by global color profiles refactoring.%%%

%%%Well, that's kind of different issue which is more about clear separation of file/working/display color profiles. We're workingion this in ocio branch (http://wiki.blender.org/index.php/Dev:Source/Image/OpenColorIO). For now wouldn't consider inconsistent of drawing bump maps as a bug, it's more a TODO which hopefully would be resolved by global color profiles refactoring.%%%

Tobias Oelgarte commented

2012-05-28 21:26:21 +02:00

%%%It is entirely useless at the moment. You just can't draw bumpmaps inside the image editor (8 bit = nice, 32 bit = OMG). They are entirely distorted (value vice). This is somehow sad, because it is the easiest thing to do. A simple 1:1 mapping without this annoying (not in itself, but at the moment [last year until now]) color management. :(%%%

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Colormanagement issue with UV/Image Editor and 32 bit float textures #28193