Image "Save As" and changing colorspace: invalid colorspace change #101331

New Issue

Florent Masson · 2022-09-24T16:38:07+02:00

Florent Masson commented

2022-09-24 16:38:07 +02:00

System Information
Operating system: Windows 10
Graphics card: RTX3700

Blender Version
Broken: 3.3.0 Probably caused by 5baa3ecda6.
Worked: 3.1.2

Short description of error
When saving an image, we can change the color space in the save properties.

When we do this, we can see that the Color Space for the image has been changed in the image properties, but the image itself has not changed within Blender.

Similarly in Python, we can see that this value has been changed (bpy.data.images- [x].colorspace_settings.name)

Afterwards, setting back the Color Space to 'sRGB' makes visual changes to the image and you are unable to get back the original image

The exported file is different (darker), as if a Linear -> sRGB has been made instead of the requested opposite.

Blender 3.1 does not have the option to change color space when saving the image but according to a few tests, the image is converted to sRGB before saving (ie if you have a linear encoding and save the file, the image is switched to sRGB and the exported file is the same as in blender)

Exact steps for others to reproduce the error

Open attached file
Click Image > Save As...
Change Color Space to Linear
Click Save As Image
ColorSpaceBug.blend

**System Information** Operating system: Windows 10 Graphics card: RTX3700 **Blender Version** Broken: 3.3.0 Probably caused by 5baa3ecda6. Worked: 3.1.2 **Short description of error** When saving an image, we can change the color space in the save properties. When we do this, we can see that the `Color Space` for the image has been changed in the image properties, but the image itself has not changed within Blender. Similarly in Python, we can see that this value has been changed (`bpy.data.images- [x].colorspace_settings.name`) Afterwards, setting back the `Color Space` to 'sRGB' makes visual changes to the image and you are unable to get back the original image The exported file is different (darker), as if a Linear -> sRGB has been made instead of the requested opposite. Blender 3.1 does not have the option to change color space when saving the image but according to a few tests, the image is converted to sRGB before saving (ie if you have a linear encoding and save the file, the image is switched to sRGB and the exported file is the same as in blender) **Exact steps for others to reproduce the error** - Open attached file - Click Image > Save As... - Change `Color Space` to `Linear` - Click `Save As Image` [ColorSpaceBug.blend](https://archive.blender.org/developer/F13563323/ColorSpaceBug.blend)

Florent Masson commented

2022-09-24 16:38:07 +02:00

Added subscriber: @FlorentM

Florent Masson changed title from ~~Image "Save As" and changing colorspace: colorspace is changed without change on the image~~ to Image "Save As" and changing colorspace: invalid colorspace change

2022-09-24 18:15:00 +02:00

Florent Masson commented

2022-09-25 12:44:11 +02:00

As an additional comment (I don't know where it belongs), the behavior of python API Image.save() has a breaking change.
Before, the image was automatically converted to sRGB before saving and it's not the case anymore. So probably the function should have an optional parameter where the default behavior is backwards compatible.
(This was my initial issue as I have scripts for automatically baking AO on linear images and then saving them)

As an additional comment (I don't know where it belongs), the behavior of python API Image.save() has a breaking change. Before, the image was automatically converted to sRGB before saving and it's not the case anymore. So probably the function should have an optional parameter where the default behavior is backwards compatible. (This was my initial issue as I have scripts for automatically baking AO on linear images and then saving them)

Germano Cavalcante commented

2022-09-27 04:31:25 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2022-09-27 04:31:25 +02:00

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

Germano Cavalcante commented

2022-09-27 04:31:25 +02:00

Probably caused by 5baa3ecda6.

It looks like there is an unwanted color space conversion.

Not sure if it's a bug or intentional, but it looks like a bug at first glance.

Probably caused by 5baa3ecda6. It looks like there is an unwanted color space conversion. Not sure if it's a bug or intentional, but it looks like a bug at first glance.

Pratik Borhade commented

2022-09-27 05:00:22 +02:00

Added subscribers: @brecht, @PratikPB2123

Brecht Van Lommel commented

2022-09-27 05:22:35 +02:00

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

Brecht Van Lommel commented

2022-09-27 05:22:35 +02:00

When saving an image, we can change the color space in the save properties.

When we do this, we can see that the Color Space for the image has been changed in the image properties, but the image itself has not changed within Blender.

This is by design. When setting a color space in the save dialog, it means the image will be saved in that colorspace in the file. It's not meant to change how the image looks, it's just specifying how the image is encoded in the file.

Afterwards, setting back the Color Space to 'sRGB' makes visual changes to the image and you are unable to get back the original image

This setting is the colorspace of the file on disk. So since it was saved as Linear, for Blender to read it back correctly the setting should specify the image on disk is in Linear color space.

As an additional comment (I don't know where it belongs), the behavior of python API Image.save() has a breaking change.
Before, the image was automatically converted to sRGB before saving and it's not the case anymore. So probably the function should have an optional parameter where the default behavior is backwards compatible.

I'm not exactly sure what this refers to, what the state of the image is before saving, but I believe it's an intentional change.

The image.save() method should now save the image in whatever colorspace was specified in the image settings, instead of ignoring it and guessing a colorspace.

> When saving an image, we can change the color space in the save properties. > > When we do this, we can see that the Color Space for the image has been changed in the image properties, but the image itself has not changed within Blender. This is by design. When setting a color space in the save dialog, it means the image will be saved in that colorspace in the file. It's not meant to change how the image looks, it's just specifying how the image is encoded in the file. > Afterwards, setting back the Color Space to 'sRGB' makes visual changes to the image and you are unable to get back the original image This setting is the colorspace of the file on disk. So since it was saved as Linear, for Blender to read it back correctly the setting should specify the image on disk is in Linear color space. > As an additional comment (I don't know where it belongs), the behavior of python API Image.save() has a breaking change. > Before, the image was automatically converted to sRGB before saving and it's not the case anymore. So probably the function should have an optional parameter where the default behavior is backwards compatible. I'm not exactly sure what this refers to, what the state of the image is before saving, but I believe it's an intentional change. The `image.save()` method should now save the image in whatever colorspace was specified in the image settings, instead of ignoring it and guessing a colorspace.

Florent Masson commented

2022-09-27 10:41:39 +02:00

This is by design. When setting a color space in the save dialog, it means the image will be saved in that colorspace in the file. It's not meant to change how the image looks, it's just specifying how the image is encoded in the file.

I get that, but the bug is that it DOES change the color space within blender when it shouldn't, try the use case
Before saving

After saving as 'linear'

Note the color space has changed in the image properties but the visual has not changed
When I switch it back to sRGB, the image is altered:

As an additional comment (I don't know where it belongs), the behavior of python API Image.save() has a breaking change.
Before, the image was automatically converted to sRGB before saving and it's not the case anymore. So probably the function should have an optional parameter where the default behavior is backwards compatible.

I'm not exactly sure what this refers to, what the state of the image is before saving, but I believe it's an intentional change.

The image.save() method should now save the image in whatever colorspace was specified in the image settings, instead of ignoring it and guessing a colorspace.

The use case is this: have an image in linear encoding. Use Image.save() as PNG. Before 3.3, the image was converted to sRGB before saving (I don't believe it was ignoring and guessing what it was). And the sRGB encoding stayed in blender. Now it's not converted and using the colorspace in the image settings.
I could not find anything related to the behavior change in blender 3.2 or 3.3 changelogs, either for "save as..." dialog or API function.
The previous API behavior (automatically changing image format to sRGB) was undocumented.
So it's just we had an undocumented behavior that has been changed in an uncommunicated change. It broke my scripts and I hope I'm the only one.

> This is by design. When setting a color space in the save dialog, it means the image will be saved in that colorspace in the file. It's not meant to change how the image looks, it's just specifying how the image is encoded in the file. I get that, but the bug is that it DOES change the color space within blender when it shouldn't, try the use case Before saving ![image.png](https://archive.blender.org/developer/F13579982/image.png) After saving as 'linear' ![image.png](https://archive.blender.org/developer/F13579992/image.png) Note the color space has changed in the image properties but the visual has not changed When I switch it back to sRGB, the image is altered: ![image.png](https://archive.blender.org/developer/F13579996/image.png) >> As an additional comment (I don't know where it belongs), the behavior of python API Image.save() has a breaking change. >> Before, the image was automatically converted to sRGB before saving and it's not the case anymore. So probably the function should have an optional parameter where the default behavior is backwards compatible. > > I'm not exactly sure what this refers to, what the state of the image is before saving, but I believe it's an intentional change. > > The `image.save()` method should now save the image in whatever colorspace was specified in the image settings, instead of ignoring it and guessing a colorspace. The use case is this: have an image in linear encoding. Use Image.save() as PNG. Before 3.3, the image was converted to sRGB before saving (I don't believe it was ignoring and guessing what it was). And the sRGB encoding stayed in blender. Now it's not converted and using the colorspace in the image settings. I could not find anything related to the behavior change in blender 3.2 or 3.3 changelogs, either for "save as..." dialog or API function. The previous API behavior (automatically changing image format to sRGB) was undocumented. So it's just we had an undocumented behavior that has been changed in an uncommunicated change. It broke my scripts and I hope I'm the only one.

Brecht Van Lommel commented

2022-09-27 12:40:57 +02:00

In #101331#1423330, @FlorentM wrote:
Note the color space has changed in the image properties but the visual has not changed

That is the intent. You saved the file in a different color space, so now the colorspace setting is changed to match the colorspace of the file.

When I switch it back to sRGB, the image is altered:

The file is not in sRGB colorspace, so indicating that it is will indeed give the wrong result.

> In #101331#1423330, @FlorentM wrote: > Note the color space has changed in the image properties but the visual has not changed That is the intent. You saved the file in a different color space, so now the colorspace setting is changed to match the colorspace of the file. > When I switch it back to sRGB, the image is altered: The file is not in sRGB colorspace, so indicating that it is will indeed give the wrong result.

Florent Masson commented

2022-09-27 16:28:38 +02:00

Mmmm I'm still puzzled by the behavior change. If you start from a linear image, you do get different results
ColorSpaceBug2.blend

3.3: "Save as " changing to sRGB in the save dialog

vs

3.1: "Save as" - no select box, automatically changes to sRGB

Well, maybe I do not understand well the meaning of this "Color Space" attribute in the image properties

Changing color space does not actually alters the image data buffer, and only the conversion that is applied when it's displayed?

And so, according to https://developer.blender.org/T74610, the behavior in 3.1 was actually a long-standing bug that has been fixed?

Mmmm I'm still puzzled by the behavior change. If you start from a linear image, you do get different results [ColorSpaceBug2.blend](https://archive.blender.org/developer/F13581621/ColorSpaceBug2.blend) 3.3: "Save as " changing to sRGB in the save dialog ![image.png](https://archive.blender.org/developer/F13581626/image.png) vs 3.1: "Save as" - no select box, automatically changes to sRGB ![image.png](https://archive.blender.org/developer/F13581631/image.png) Well, maybe I do not understand well the meaning of this "Color Space" attribute in the image properties ![image.png](https://archive.blender.org/developer/F13581616/image.png) Changing color space does not actually alters the image data buffer, and only the conversion that is applied when it's displayed? And so, according to https://developer.blender.org/T74610, the behavior in 3.1 was actually a long-standing bug that has been fixed?

Germano Cavalcante commented

2022-09-27 17:07:41 +02:00

I think I understood what Brencht explained and it no longer seems like a bug to me.
Let's consider an image using the sRGB color space as an example.
If you save this image as being in Linear space, it takes the entire sRGB color transform and converts it to Linear.
Thus, its Linear becomes what it used to be sRGB (the interface changes to Linear for convenience).
If you change the space before Linear to sRGB, you are transforming the color of what is already transformed. It's like applying sRGB twice.

I may have misunderstood however.

On the other question raised (image.save()) I suggest doing another report.

In the submission template and guidelines, it is informed:
If there are multiple bugs, make multiple bug reports.

I think I understood what Brencht explained and it no longer seems like a bug to me. Let's consider an image using the `sRGB` color space as an example. If you save this image as being in `Linear` space, it takes the entire `sRGB` color transform and converts it to `Linear`. Thus, its `Linear` becomes what it used to be `sRGB` (the interface changes to `Linear` for convenience). If you change the space before `Linear` to `sRGB`, you are transforming the color of what is already transformed. It's like applying `sRGB` twice. I may have misunderstood however. On the other question raised (`image.save()`) I suggest doing another report. > **In the [submission template and guidelines](https://developer.blender.org/maniphest/task/edit/form/1/), it is informed:** > If there are multiple bugs, make multiple bug reports.

Brecht Van Lommel commented

2022-09-27 17:28:42 +02:00

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

Brecht Van Lommel closed this issue

2022-09-27 17:28:42 +02:00

Brecht Van Lommel commented

2022-09-27 17:28:42 +02:00

And so, according to https://developer.blender.org/T74610, the behavior in 3.1 was actually a long-standing bug that has been fixed?

Yes. Saving an image in a different colorspace in the file should not change it visually, that was a bug.

Changing color space does not actually alters the image data buffer, and only the conversion that is applied when it's displayed?

The way to understand it is that Blender works in scene linear color space, and the colorspace settings are about converting to and from that for file I/O and display.
https://docs.blender.org/manual/en/dev/render/color_management.html

There are some caveats in the implementation, in practice conversion may be delayed or cancel out for performance/memory/precision reasons. But the meaning and visual display of the color in Blender remains the same, regardless of the color space, bit depth or compression used in the file on disk.

> And so, according to https://developer.blender.org/T74610, the behavior in 3.1 was actually a long-standing bug that has been fixed? Yes. Saving an image in a different colorspace in the file should not change it visually, that was a bug. > Changing color space does not actually alters the image data buffer, and only the conversion that is applied when it's displayed? The way to understand it is that Blender works in scene linear color space, and the colorspace settings are about converting to and from that for file I/O and display. https://docs.blender.org/manual/en/dev/render/color_management.html There are some caveats in the implementation, in practice conversion may be delayed or cancel out for performance/memory/precision reasons. But the meaning and visual display of the color in Blender remains the same, regardless of the color space, bit depth or compression used in the file on disk.

Brecht Van Lommel commented

2022-09-27 17:29:28 +02:00

The Python API change is not a bug either, but should been better documented in the release notes.

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

Image "Save As" and changing colorspace: invalid colorspace change #101331