Blender applies color management to AOVs, effectively destroying them #83842

New Issue

Ludvik Koutny · 2020-12-16T13:07:16+01:00

Ludvik Koutny commented

2020-12-16 13:07:16 +01:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.79

Blender Version
Broken: version: 2.91.0, branch: master (modified), commit date: 2020-11-25 11:06, hash: b50598bc78
Worked: probably never

Short description of error
Blender applies color management to AOV output, effectively destroying the data. When user uses non standard view transform, such as filmic, which is in fact default now, and then wants to output the AOVs at once using compositor, so they don't have to be manually saved from framebuffer one by one, the filmic color transform is applied to AOVs saved this way, and they end up being useless.

While regular image save dialog has an option to prevent this, called "Save As Render"

...the compositor File Output node does not have have this option, and defaults to wrong behavior out of the box, as it would likely be more often used for saving AOV passes, rather than color corrected beauty passes.

Only workaround is to disable Blender-wide color management completely, making it in turn useless, because workflow of constantly turning it off and on whenever user wants to output AOVs is just not acceptable.

Exact steps for others to reproduce the error

Open attached .blend file: ImageToMaterial.zip
Select the plane, and replace the color texture with any arbitrary texture, as I could not share the copyrighted one.
In compositing node, set the file output path to an existing destination
Press render
Compare rendered texture to original source texture
Result: Texture AOV has different color tones to the original texture due to applied color mapping
Expected: Color mapping is never ever applied to AOVs

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.79 **Blender Version** Broken: version: 2.91.0, branch: master (modified), commit date: 2020-11-25 11:06, hash: `b50598bc78` Worked: probably never **Short description of error** Blender applies color management to AOV output, effectively destroying the data. When user uses non standard view transform, such as filmic, which is in fact default now, and then wants to output the AOVs at once using compositor, so they don't have to be manually saved from framebuffer one by one, the filmic color transform is applied to AOVs saved this way, and they end up being useless. ![image.png](https://archive.blender.org/developer/F9512893/image.png) While regular image save dialog has an option to prevent this, called "Save As Render" ![image.png](https://archive.blender.org/developer/F9512895/image.png) ...the compositor File Output node does not have have this option, and defaults to wrong behavior out of the box, as it would likely be more often used for saving AOV passes, rather than color corrected beauty passes. Only workaround is to disable Blender-wide color management completely, making it in turn useless, because workflow of constantly turning it off and on whenever user wants to output AOVs is just not acceptable. **Exact steps for others to reproduce the error** 1. Open attached .blend file: [ImageToMaterial.zip](https://archive.blender.org/developer/F9512900/ImageToMaterial.zip) 2. Select the plane, and replace the color texture with any arbitrary texture, as I could not share the copyrighted one. 3. In compositing node, set the file output path to an existing destination 4. Press render 5. Compare rendered texture to original source texture Result: Texture AOV has different color tones to the original texture due to applied color mapping Expected: Color mapping is never ever applied to AOVs

Ludvik Koutny commented

2020-12-16 13:07:16 +01:00

Added subscriber: @Rawalanche

Robert Guetzkow commented

2020-12-16 13:14:00 +01:00

Added subscriber: @rjg

Robert Guetzkow commented

2020-12-16 13:14:00 +01:00

@Rawalanche as far as I'm aware the file output node doesn't have any knowledge about the source of the data you're passing into it and thus can't / doesn't treat the input from AOVs differently. You would want to use OpenEXR as output format as this stores the values as is. Besides the view transform being applied on other formats, it's generally not advisable to use PNG for AOVs, even when setting the view transform to RAW, as all values have to be mapped to integer values in the [0, 255] range. This means you will always be losing information / precision in the process when using PNG and won't get the exact same results back as the original AOV when loading the saved image into Blender or another application.

Ludvik Koutny commented

2020-12-16 13:49:18 +01:00

In #83842#1076371, @rjg wrote:
@Rawalanche as far as I'm aware the file output node doesn't have any knowledge about the source of the data you're passing into it and thus can't / doesn't treat the input from AOVs differently. You would want to use OpenEXR as output format as this stores the values as is. Besides the view transform being applied on other formats, it's generally not advisable to use PNG for AOVs, even when setting the view transform to RAW, as all values have to be mapped to integer values in the [0, 255] range. This means you will always be losing information / precision in the process when using PNG and won't get the exact same results back as the original AOV when loading the saved image into Blender or another application.

That does not apply when you use AOVs for example to generate texture sets for games, where EXR is (often incompatible and/or harder to edit in image editing software) overkill. PNG is nothing more than a data container, so there is absolutely no excuse for making assumptions of whether or not user wants to store color managed data within it. I guess that when you look at the render layers, and see "BaseColor", "Roughness" and "Normal", you can already tell what I am trying to achieve. I am trying to bypass Blender's unusable texture baking tools using AOVs, but even when trying to output those, Blender throws sticks under my feet.

Let me put it differently. Ask yourself if there is any excuse to not have the "Save As Render" switch present in the File Output compositor node, when it's present in all other places where Blender outputs texture files.

> In #83842#1076371, @rjg wrote: > @Rawalanche as far as I'm aware the file output node doesn't have any knowledge about the source of the data you're passing into it and thus can't / doesn't treat the input from AOVs differently. You would want to use OpenEXR as output format as this stores the values as is. Besides the view transform being applied on other formats, it's generally not advisable to use PNG for AOVs, even when setting the view transform to RAW, as all values have to be mapped to integer values in the [0, 255] range. This means you will always be losing information / precision in the process when using PNG and won't get the exact same results back as the original AOV when loading the saved image into Blender or another application. That does not apply when you use AOVs for example to generate texture sets for games, where EXR is (often incompatible and/or harder to edit in image editing software) overkill. PNG is nothing more than a data container, so there is absolutely no excuse for making assumptions of whether or not user wants to store color managed data within it. I guess that when you look at the render layers, and see "BaseColor", "Roughness" and "Normal", you can already tell what I am trying to achieve. I am trying to bypass Blender's unusable texture baking tools using AOVs, but even when trying to output those, Blender throws sticks under my feet. Let me put it differently. Ask yourself if there is any excuse to not have the "Save As Render" switch present in the File Output compositor node, when it's present in all other places where Blender outputs texture files.

Robert Guetzkow commented

2020-12-16 14:00:30 +01:00

@Rawalanche it's a missing feature as the node currently has no way of knowing that you don't want the view transform to be applied.

Ludvik Koutny commented

2020-12-16 14:41:42 +01:00

In #83842#1076435, @rjg wrote:
@Rawalanche it's a missing feature as the node currently has no way of knowing that you don't want the view transform to be applied.

Inability for user to prevent certain image formats from being saved with color transform walks a line between missing feature and a bug.

There's a difference between new feature as in user being able to do something they were not able to do before, and new feature as in being able to use existing feature without problems.

> In #83842#1076435, @rjg wrote: > @Rawalanche it's a missing feature as the node currently has no way of knowing that you don't want the view transform to be applied. Inability for user to prevent certain image formats from being saved with color transform walks a line between missing feature and a bug. There's a difference between new feature as in user being able to do something they were not able to do before, and new feature as in being able to use existing feature without problems.

Philipp Oeser commented

2020-12-16 15:14:07 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-12-16 15:14:07 +01:00

Note: even EXR has its issues with multiple layers, see #68239 (Cryptomatte affected by Color Space change in OpenEXR multilayer.)

Robert Guetzkow commented

2020-12-16 15:33:32 +01:00

@lichtwerk From my understanding this is a different issue, as this happens when loading an existing multi-layer image and selecting the color space that is then indiscriminately applied to all layers. The problem in this ticket is just that the file output node has no option to disable the view transform for non-color data (except for when using OpenEXR as output format).

Philipp Oeser commented

2020-12-16 15:39:36 +01:00

Yep, they are different issues, was just noting that it is always necessary to be able to specify which data is being colormanaged and which is not [but admit I was a bit off-topic here]

Brecht Van Lommel commented

2020-12-16 19:05:22 +01:00

Added subscriber: @brecht

Brecht Van Lommel commented

2020-12-16 19:05:22 +01:00

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

Brecht Van Lommel closed this issue

2020-12-16 19:05:22 +01:00

Brecht Van Lommel commented

2020-12-16 19:05:22 +01:00

I've added this issue to the list in #68926 (Color Management Improvements) now.

We recommend using OpenEXR for digital intermediates, which avoids this problem.

Also note that when saving to PNG, color management is in fact needed. It needs to write sRGB per the PNG spec, and because 8bit can not store linear colors without significant data loss. What you want in this case would be an option to skip the artistic choices like Filmic, but still convert linear to sRGB.

I've added this issue to the list in #68926 (Color Management Improvements) now. We recommend using OpenEXR for digital intermediates, which avoids this problem. Also note that when saving to PNG, color management is in fact needed. It needs to write sRGB per the PNG spec, and because 8bit can not store linear colors without significant data loss. What you want in this case would be an option to skip the artistic choices like Filmic, but still convert linear to sRGB.

Ludvik Koutny commented

2020-12-17 09:53:50 +01:00

In #83842#1076710, @brecht wrote:
I've added this issue to the list in #68926 (Color Management Improvements) now.

We recommend using OpenEXR for digital intermediates, which avoids this problem.

Also note that when saving to PNG, color management is in fact needed. It needs to write sRGB per the PNG spec, and because 8bit can not store linear colors without significant data loss. What you want in this case would be an option to skip the artistic choices like Filmic, but still convert linear to sRGB.

As I wrote, my intention for it was to output PBR texture sets. You can not make assumptions about what user wants to use certain image format for. sRGB is something most engines have direct option to remove on load. I mean most normal maps for games come in 8bit PNGs. EXRs are unacceptable for regular game textures, for many reasons. They are harder to edit in average image editing packages, some engines do not even properly support them, and they don't even display preview thumbnail in Windows file explorer, due to how exotic of a format they are, so that managing a texture libraries becomes complete hell.

Of course I want to convert linear to sRGB. Yes, PNG is dependent on that. But exactly as there is a need to write sRGB per the PNG spec, there is also nothing in the PNG specs saying other color transforms should be written too, so doing this directly, without user's choice is actually against PNG spec. Lastly, the "Save As Render" checkbox already does exactly that, it still applies sRGB to PNG, just not the transforms which are meant for view only.

What are you doing is that you are treating both image format essential standardized transform like sRGB and random, artistic, non standardized transform like Filmic (at least Blender's implementation is non standard) as the same thing, and applying them both forcibly, without user's choice. When you load 8bit file, Unreal Engine has a simple checkbox to counter sRGB transform for linear data saved in 8bit image files:

But there's nothing to remove Blender's arbitrary filmic transform.

And saying to use EXR for game image textures to solve this issue is like telling person stuck in a highway traffic they should have used a helicopter instead to avoid the problem.

This is LITERALLY just about adding the already existing "Save As Render" checkbox to the File Output compositor node. So please do not just clean this up into some old Color Management Improvements task where it will rot for several years before the task will eventually be forgotten.

> In #83842#1076710, @brecht wrote: > I've added this issue to the list in #68926 (Color Management Improvements) now. > > We recommend using OpenEXR for digital intermediates, which avoids this problem. > > Also note that when saving to PNG, color management is in fact needed. It needs to write sRGB per the PNG spec, and because 8bit can not store linear colors without significant data loss. What you want in this case would be an option to skip the artistic choices like Filmic, but still convert linear to sRGB. As I wrote, my intention for it was to output PBR texture sets. You can not make assumptions about what user wants to use certain image format for. sRGB is something most engines have direct option to remove on load. I mean most normal maps for games come in 8bit PNGs. EXRs are unacceptable for regular game textures, for many reasons. They are harder to edit in average image editing packages, some engines do not even properly support them, and they don't even display preview thumbnail in Windows file explorer, due to how exotic of a format they are, so that managing a texture libraries becomes complete hell. Of course I want to convert linear to sRGB. Yes, PNG is dependent on that. But exactly as there is a need to write sRGB per the PNG spec, there is also nothing in the PNG specs saying other color transforms should be written too, so doing this directly, without user's choice is actually against PNG spec. Lastly, the "Save As Render" checkbox already does exactly that, it still applies sRGB to PNG, just not the transforms which are meant for view only. What are you doing is that you are treating both image format essential standardized transform like sRGB and random, artistic, non standardized transform like Filmic (at least Blender's implementation is non standard) as the same thing, and applying them both forcibly, without user's choice. When you load 8bit file, Unreal Engine has a simple checkbox to counter sRGB transform for linear data saved in 8bit image files: ![image.png](https://archive.blender.org/developer/F9514621/image.png) But there's nothing to remove Blender's arbitrary filmic transform. And saying to use EXR for game image textures to solve this issue is like telling person stuck in a highway traffic they should have used a helicopter instead to avoid the problem. This is LITERALLY just about adding the already existing "Save As Render" checkbox to the File Output compositor node. So please do not just clean this up into some old Color Management Improvements task where it will rot for several years before the task will eventually be forgotten.

Robert Guetzkow commented

2020-12-17 10:03:34 +01:00

@Rawalanche We recognize that there is a need for this so it has been added to the ToDo task. It will be worked on when developers have time to look into this, just as it would with a bug report. While we understand that you consider this a very important issue that is best solved right away, we still need to organize the development and prioritize tasks.

@Rawalanche We recognize that there is a need for this so it has been added to the *ToDo* task. It will be worked on when developers have time to look into this, just as it would with a bug report. While we understand that you consider this a very important issue that is best solved right away, we still need to organize the development and prioritize tasks.

Robert Guetzkow commented

2020-12-17 10:16:30 +01:00

In the meantime, until this feature is added, I would suggest you set the View Transform to Raw and the file output format to PNG. This should give you the desired result for your intended use case with the AOVs. The current downside is that this applies globally and your render / composite will also be affected by this setting.

In the meantime, until this feature is added, I would suggest you set the *View Transform* to *Raw* and the file output format to PNG. This should give you the desired result for your intended use case with the AOVs. The current downside is that this applies globally and your render / composite will also be affected by this setting.

Ludvik Koutny commented

2020-12-17 12:33:36 +01:00

In #83842#1077086, @rjg wrote:
In the meantime, until this feature is added, I would suggest you set the View Transform to Raw and the file output format to PNG. This should give you the desired result for your intended use case with the AOVs. The current downside is that this applies globally and your render / composite will also be affected by this setting.

Yes, I am aware of the workaround, that's what I am doing, but currently, for this particular use case of baking PBR texture sets, I want to be able to do both outputting of the correct data as well as viewing what I am working on in a color managed environment at the same time. Users should not be forced to make a choice between one of these two things or have to do constant chores of turning color management off and on all over again depending of if they are about to save the output. So that's why this is important.

> In #83842#1077086, @rjg wrote: > In the meantime, until this feature is added, I would suggest you set the *View Transform* to *Raw* and the file output format to PNG. This should give you the desired result for your intended use case with the AOVs. The current downside is that this applies globally and your render / composite will also be affected by this setting. Yes, I am aware of the workaround, that's what I am doing, but currently, for this particular use case of baking PBR texture sets, I want to be able to do both outputting of the correct data as well as viewing what I am working on in a color managed environment at the same time. Users should not be forced to make a choice between one of these two things or have to do constant chores of turning color management off and on all over again depending of if they are about to save the output. So that's why this is important.

blender-admin commented

2021-01-13 11:01:44 +01:00

This issue was referenced by 27b78c9c94

This issue was referenced by 27b78c9c94baf6fa43268e851de58da96f7d7123

Martynas Žiemys commented

2021-01-22 17:13:47 +01:00

Added subscriber: @MartinZ

Martynas Žiemys commented

2021-01-22 17:13:47 +01:00

This comment was removed by @MartinZ

*This comment was removed by @MartinZ*

Brecht Van Lommel commented

2021-01-22 17:24:31 +01:00

Feel free to comment if you have a constructive suggestion for a better name and description, developer.blender.org is not the place to rant.

Martynas Žiemys commented

2021-01-22 17:32:54 +01:00

Well, I would gladly do that, but I am afraid it seems I have no way of knowing what it does exactly like most users without deep understanding how Blender's code works and ability to program in C. I am guessing it disables color transforms set in Color Management settings and outputs raw values, is this what it does? In that case why not call it "Disable color transforms" ? Or if it applies other transforms, why not say "Apply x color transforms" where x is those color transforms...

Robert Guetzkow commented

2021-01-22 18:28:27 +01:00

@MartinZ This has been partly discussed in D9921.

In D9921 #248137, @rjg wrote:
I think I would rename "Save As Render" to "Apply Color Management Settings" and have the description read "Apply the scene's color management settings such as view transform, look and exposure. If this option is disable it will still use the Standard view transform to map the data into the target color space of the image format."

This should get addressed in the near future.

@MartinZ This has been partly discussed in [D9921](https://archive.blender.org/developer/D9921). > In [D9921](https://archive.blender.org/developer/D9921)#248137, @rjg wrote: > I think I would rename "Save As Render" to "Apply Color Management Settings" and have the description read "Apply the scene's color management settings such as view transform, look and exposure. If this option is disable it will still use the Standard view transform to map the data into the target color space of the image format." This should get addressed in the near future.

Martynas Žiemys commented

2021-01-22 18:52:24 +01:00

Sounds better. Of course "Standard view transform" is just as meaningless, if the standard is not defined. This is another big issue. What is standard? Why not specify the standard just there? Is it sRGB IEC61966-2.1? Or is it any other standard? Why hide it?..

Robert Guetzkow commented

2021-01-22 19:03:21 +01:00

@MartinZ The "Standard" in this context refers to the view transform named "Standard" not a specific specification standard. Technically this would depend on the OCIO config used. For Blender without any modifications this would be sRGB as defined by the srgb.spi1d lookup table when using an sRGB display (and a different one when using a different color space for display).

If we were to make larger changes, like renaming the "Standard" view transform, this should rather be planned and addressed in context of #68926 and not just by a single patch without design task.

@MartinZ The "Standard" in this context refers to the [view transform named "Standard" ](https://docs.blender.org/manual/en/dev/render/color_management.html#render) not a specific specification standard. Technically this would depend on the OCIO config used. For Blender without any modifications this would be sRGB as defined by the `srgb.spi1d` lookup table when using an sRGB display (and a different one when using a different color space for display). If we were to make larger changes, like renaming the "Standard" view transform, this should rather be planned and addressed in context of #68926 and not just by a single patch without design task.

Brecht Van Lommel commented

2021-01-22 19:15:02 +01:00

The OpenColorIO design is have the display device and view transform as independent choices, so that you can switch display devices and keep other color management settings the same. That means "sRGB" should not be in the view transform name.

Martynas Žiemys commented

2021-01-22 19:44:07 +01:00

That makes sense. As long as it's not "Save as Render" with the current tooltip it's way better. I think "Standard" might not be the best choice for the name and it would make more sense to just call it Display Device Transform directly if it is, but what do I know. Even if it is a bit confussing and named "Standard" at least it makes a whole lot more sense than what it is right now.

Evan Wilson commented

2021-01-22 22:42:04 +01:00

Added subscriber: @EAW

Evan Wilson commented

2021-01-22 22:42:04 +01:00

Just a note: OCIO is starting a UX working group to

document a "standard" way of implementing OCIO in an application.

Hopefully it will help users of multiple programs to have a more consistent CM user experience.

Just a note: OCIO is starting a UX working group to >document a "standard" way of implementing OCIO in an application. Hopefully it will help users of multiple programs to have a more consistent CM user experience.

Ludvik Koutny commented

2021-01-23 23:43:24 +01:00

From my experience, the output without any color transform is generally referred to in the industry simply as "Linear", so that's what I would call it. "Save as Render" label indeed makes absolutely no sense. Render just means rendered picture, and rendered picture can be color managed or not, depending on how the user intends to use it.

Brecht Van Lommel referenced this issue

2023-11-13 19:44:32 +01:00

Color Management Improvements #68926

Sign in to join this conversation.