Inconsistent color space baking to float and byte images #94446

New Issue

Cristiano · 2021-12-28T20:03:07+01:00

Cristiano commented

2021-12-28 20:03:07 +01:00

System Information
Operating system: Windows-10-10.0.17763-SP0 64 Bits
Graphics card: AMD Radeon(TM) Vega 8 Graphics ATI Technologies Inc. 4.5.14742 Core Profile Context 21.8.2 27.20.22025.1006

Blender Version
Broken: version: 2.93.6, branch: master, commit date: 2021-11-16 14:54, hash: c842a90e2f
Worked: ---

Short description of error
In blender we can create an image with 32 bit resolution (See image):

The new 32bit image can be used for baking in order to obtain a normal map.
This map works perfectly until saved in PNG (16bit or 8bit).
Interestingly you can bake directly on a 16bit image and the resulting image works even if it is saved in 8bit.

Here is a file where I put different pixel resolution combinations on textures saved in PNG:
TesteNormal.blend

Exact steps for others to reproduce the error
1 - Bake a normal map image with 32 bit option enabled. (see the pic "sample3.jpg")

   A simple cube can be used, no need to add any detail.

2 - Save the image as PNG in 8 bit or 16 bit.
3 - Create a material and connect the saved baked normal map image to the normal map node.

   Change color space option to "non-color"

4 - Observe the object becomes dark in rendered mode in Eevee or Cycles.

Teste_Normal_Textures.blend

**System Information** Operating system: Windows-10-10.0.17763-SP0 64 Bits Graphics card: AMD Radeon(TM) Vega 8 Graphics ATI Technologies Inc. 4.5.14742 Core Profile Context 21.8.2 27.20.22025.1006 **Blender Version** Broken: version: 2.93.6, branch: master, commit date: 2021-11-16 14:54, hash: `c842a90e2f` Worked: --- **Short description of error** In blender we can create an image with 32 bit resolution (See image): ![sample3.jpg](https://archive.blender.org/developer/F12779576/sample3.jpg) The new 32bit image can be used for baking in order to obtain a normal map. This map works perfectly until saved in PNG (16bit or 8bit). Interestingly you can bake directly on a 16bit image and the resulting image works even if it is saved in 8bit. Here is a file where I put different pixel resolution combinations on textures saved in PNG: [TesteNormal.blend](https://archive.blender.org/developer/F12779572/TesteNormal.blend) ![sample2.jpg](https://archive.blender.org/developer/F12779567/sample2.jpg) ![sample.jpg](https://archive.blender.org/developer/F12779566/sample.jpg) **Exact steps for others to reproduce the error** 1 - Bake a normal map image with 32 bit option enabled. (see the pic "sample3.jpg") ``` A simple cube can be used, no need to add any detail. ``` 2 - Save the image as PNG in 8 bit or 16 bit. 3 - Create a material and connect the saved baked normal map image to the normal map node. ``` Change color space option to "non-color" ``` 4 - Observe the object becomes dark in rendered mode in Eevee or Cycles. [Teste_Normal_Textures.blend](https://archive.blender.org/developer/F12786903/Teste_Normal_Textures.blend)

Cristiano commented

2021-12-28 20:03:07 +01:00

Added subscriber: @CristianoSimao

Cristiano changed title from ~~32 Bit Nomal Map Generated inside Blender produces Dark materials.~~ to 32 Bit Normal Map Generated inside Blender produces Dark materials.

2021-12-28 20:04:29 +01:00

Germano Cavalcante commented

2021-12-31 15:35:36 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2021-12-31 15:35:36 +01:00

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

Germano Cavalcante commented

2021-12-31 15:35:37 +01:00

I can't replicate from scratch.
Could you test baking with the latest daily build? https://builder.blender.org/download/daily/
Also, could you test with an image format that supports 32bit (like OpenEXR Float Full)?
So we can define if the problem is in the baking system or in the PNG image codec.

I can't replicate from scratch. Could you test baking with the latest daily build? https://builder.blender.org/download/daily/ Also, could you test with an image format that supports 32bit (like OpenEXR Float Full)? So we can define if the problem is in the baking system or in the PNG image codec.

Cristiano commented

2021-12-31 17:51:57 +01:00

Thanks Germano for your response.
In Blender 2.93.6 the normal map image baked and saved as 32 bit OpenEXR with Float Full work Ok. (see the pic)

In Blender 3.0 the same problem occurs, EXR 32 bit OK and PNG bad.

In Blender 2.93.8 the same thing.

Thanks Germano for your response. In Blender 2.93.6 the normal map image baked and saved as 32 bit OpenEXR with Float Full work Ok. (see the pic) ![testExr.jpg](https://archive.blender.org/developer/F12783405/testExr.jpg) In Blender 3.0 the same problem occurs, EXR 32 bit OK and PNG bad. ![testExr2.jpg](https://archive.blender.org/developer/F12783419/testExr2.jpg) In Blender 2.93.8 the same thing. ![testExr3.jpg](https://archive.blender.org/developer/F12783429/testExr3.jpg)

Germano Cavalcante commented

2022-01-03 14:53:50 +01:00

The problem seems to be in the code of writing PNG image.
Apparently it doesn't correctly convert a 32-bit image to 16-bit.
But I'm not sure if this is a Blender issue or a Format limitation.

I've found a ToDo comment code that seems to be related. https://developer.blender.org/diffusion/B/browse/master/source/blender/imbuf/intern/png.c$23

\todo Save floats as 16 bits per channel, currently readonly.

Could you provide the OpenEXR image? So I can edit the description of the report and simplify the steps to reproduce the problem.

The problem seems to be in the code of writing PNG image. Apparently it doesn't correctly convert a 32-bit image to 16-bit. But I'm not sure if this is a Blender issue or a Format limitation. I've found a ToDo comment code that seems to be related. https://developer.blender.org/diffusion/B/browse/master/source/blender/imbuf/intern/png.c$23 > * \todo Save floats as 16 bits per channel, currently readonly. --- Could you provide the OpenEXR image? So I can edit the description of the report and simplify the steps to reproduce the problem.

Cristiano commented

2022-01-03 15:14:01 +01:00

Yes here are the OpenEXR image.

And here the bad PNG.
32 bit saved as 16 bit PNG

And here 32 bit saved as 8 bit PNG

Yes here are the OpenEXR image. ![NewTest.exr](https://archive.blender.org/developer/F12786777/NewTest.exr) And here the bad PNG. 32 bit saved as 16 bit PNG ![T_1k_32bit_e16.png](https://archive.blender.org/developer/F12786785/T_1k_32bit_e16.png) And here 32 bit saved as 8 bit PNG ![T_1k_32bit_e8.png](https://archive.blender.org/developer/F12786784/T_1k_32bit_e8.png)

Germano Cavalcante commented

2022-01-03 16:34:32 +01:00

I saved the exr image to PNG (16 bit) format, the resulting image worked (I haven't been able to replicate the problem yet).
Does the OpenEXR to PNG conversion work?

I saved the exr image to PNG (16 bit) format, the resulting image worked (I haven't been able to replicate the problem yet). Does the OpenEXR to PNG conversion work?

Cristiano commented

2022-01-03 18:00:40 +01:00

I am not saying anything about saved images converted inside Blender.
I am saying the problem is in the first internal image generated in Blender with the 32bit checkbox marked when you bake the normal map, when you will save and select PNG format, the resulting image is saved probably with some error in format and when you open this image the color result is dark (wrong)

Steps.
1 - Generate any normal map with 32 bit checkbox enabled. (No need any detail in the model, a simple cube can be used)

    This image is saved in some internal buffer inside Blender, if you close Blender this image will be lost. So you need save the image in some file.

2 - Click in the image menu, select "save as"

3 - Choose PNG file format.

4 - Click save.

5 - Create a new blender file or other model or other material and try use this saved PNG image in your material in normal map node.

6 - Result is a dark material.

I am not saying anything about saved images converted inside Blender. I am saying the problem is in the first internal image generated in Blender with the 32bit checkbox marked when you bake the normal map, when you will save and select PNG format, the resulting image is saved probably with some error in format and when you open this image the color result is dark (wrong) Steps. 1 - Generate any normal map with 32 bit checkbox enabled. (No need any detail in the model, a simple cube can be used) ``` This image is saved in some internal buffer inside Blender, if you close Blender this image will be lost. So you need save the image in some file. ``` 2 - Click in the image menu, select "save as" 3 - Choose PNG file format. 4 - Click save. 5 - Create a new blender file or other model or other material and try use this saved PNG image in your material in normal map node. 6 - Result is a dark material.

Germano Cavalcante commented

2022-01-21 23:02:25 +01:00

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

Philipp Oeser commented

2022-01-24 13:54:32 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-01-24 13:54:32 +01:00

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

Philipp Oeser commented

2022-01-24 13:54:32 +01:00

This should not be the case if you do the following (and to me it is not clear if you did that prior to baking):

For the selected Image Texture node that should be baked to:

create a new Image (32 bit option enabled, you did that)
in the Image Texture node, change Color Space from Linear (default) to Non-Color (this is where I am not sure if you did that)
save it as 8bit (or 16bit)
if I then open these and use them with Non-Color colorspace as normal map, these seem to work fine, no?

See #52334 (32 bit Float normal map are baked in sRGB instead of Linear) / e786ea6419

@CristianoSimao: please let us know if this works for you.

This should not be the case if you do the following (and to me it is not clear if you did that prior to baking): For the selected Image Texture node that should be baked to: - create a new Image (32 bit option enabled, you did that) - in the `Image Texture` node, change `Color Space` from `Linear` (default) to `Non-Color` (this is where I am not sure if you did that) - save it as 8bit (or 16bit) - if I then open these and use them with `Non-Color` colorspace as normal map, these seem to work fine, no? See #52334 (32 bit Float normal map are baked in sRGB instead of Linear) / e786ea6419 @CristianoSimao: please let us know if this works for you.

Cristiano commented

2022-01-24 14:19:59 +01:00

Hello Philipp.
I have changed the Color space to Non-Color only after the image is saved, as you can see in my first post in the step 3. And the problem appears.

Now following your steps I changed the color space to Non-Color before the image is saved, and then I saved as 16 bit PNG and all work OK, no more problem with this shadow colors.

But this is strange, for the other image formats this step is not necessary as you can see in my other posts.
Now I think you discover the place in the code where conversion formats uses wrong parameters.

Obs: I tested this in Blender 2.93.6

Hello Philipp. I have changed the Color space to Non-Color only after the image is saved, as you can see in my first post in the step 3. And the problem appears. Now following your steps I changed the color space to Non-Color **before** the image is saved, and then I saved as 16 bit PNG and all work OK, no more problem with this shadow colors. But this is strange, for the other image formats this step is not necessary as you can see in my other posts. Now I think you discover the place in the code where conversion formats uses wrong parameters. Obs: I tested this in Blender 2.93.6

Philipp Oeser commented

2022-01-24 15:40:38 +01:00

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

Philipp Oeser closed this issue

2022-01-24 15:40:38 +01:00

Philipp Oeser commented

2022-01-24 15:40:38 +01:00

In #94446#1293950, @CristianoSimao wrote:
Now following your steps I changed the color space to Non-Color before the image is saved, and then I saved as 16 bit PNG and all work OK, no more problem with this shadow colors.

Good!

But this is strange, for the other image formats this step is not necessary as you can see in my other posts.

With "image formats" you mean starting off with o non-32bit generated image?
If you havent touched the colorspace prior to baking there (these default to sRGB) and saving these happens to sRGB as well, there is no colorspace conversion, which I assume makes this unnecessary in your case.
I would assume if non-32bit generated images are set to anything else than sRGB prior to baking, similar issues (unwanted colorspace conversion) would take place there as well.
When saving to EXR, this saves in linear (same as the default for 32bit generated images, so also no colorspace conversion there).

So to avoid any colorspace conversion when saving baked normalmaps in 32bit generated images to lower bitdepths, the solution is to set colorspace to Non-Color prior to baking.
This does not look like a bug to me, will archive (but of course feel free to comment again if issues persist or if this is a misunderstanding on my side).

> In #94446#1293950, @CristianoSimao wrote: > Now following your steps I changed the color space to Non-Color **before** the image is saved, and then I saved as 16 bit PNG and all work OK, no more problem with this shadow colors. Good! > But this is strange, for the other image formats this step is not necessary as you can see in my other posts. With "image formats" you mean starting off with o non-32bit generated image? If you havent touched the colorspace prior to baking there (these default to sRGB) and saving these happens to sRGB as well, there is no colorspace conversion, which I assume makes this unnecessary in your case. I would assume if non-32bit generated images are set to anything else than sRGB prior to baking, similar issues (unwanted colorspace conversion) would take place there as well. When saving to EXR, this saves in linear (same as the default for 32bit generated images, so also no colorspace conversion there). So to avoid any colorspace conversion when saving baked normalmaps in 32bit generated images to lower bitdepths, the solution is to set colorspace to `Non-Color` prior to baking. This does not look like a bug to me, will archive (but of course feel free to comment again if issues persist or if this is a misunderstanding on my side).

Cristiano commented

2022-01-24 15:58:35 +01:00

  - With "image formats" you mean starting off with o non-32bit generated image? ---

Yes.

I think this is a bug, because if changing to Non-Color before baking is the right way this should be a obligatory step also for non 32 bit normal maps also.
If you will archive this post I can not do anything, but some other day other people will see this and report as a bug exactly because no one expect a simple thing that work will need a different pipeline only for changing a image file format.

- With "image formats" you mean starting off with o non-32bit generated image? --- Yes. I think this is a bug, because if changing to Non-Color before baking is the right way this should be a obligatory step also for non 32 bit normal maps also. If you will archive this post I can not do anything, but some other day other people will see this and report as a bug exactly because no one expect a simple thing that work will need a different pipeline only for changing a image file format.

Philipp Oeser commented

2022-01-24 16:54:35 +01:00

Changed status from 'Archived' to: 'Needs Developer To Reproduce'

Philipp Oeser reopened this issue

2022-01-24 16:54:35 +01:00

Philipp Oeser commented

2022-01-24 16:54:35 +01:00

Added subscribers: @Sergey, @brecht

Philipp Oeser commented

2022-01-24 16:54:35 +01:00

In #94446#1293988, @CristianoSimao wrote:
I think this is a bug, because if changing to Non-Color before baking is the right way this should be a obligatory step also for non 32 bit normal maps also.

In #94446#1293975, @lichtwerk wrote:

In #94446#1293950, @CristianoSimao wrote:
Now following your steps I changed the color space to Non-Color before the image is saved, and then I saved as 16 bit PNG and all work OK, no more problem with this shadow colors.

Good!

But this is strange, for the other image formats this step is not necessary as you can see in my other posts.

With "image formats" you mean starting off with o non-32bit generated image?
If you havent touched the colorspace prior to baking there (these default to sRGB) and saving these happens to sRGB as well, there is no colorspace conversion, which I assume makes this unnecessary in your case.
I would assume if non-32bit generated images are set to anything else than sRGB prior to baking, similar issues (unwanted colorspace conversion) would take place there as well.
When saving to EXR, this saves in linear (same as the default for 32bit generated images, so also no colorspace conversion there).

So to avoid any colorspace conversion when saving baked normalmaps in 32bit generated images to lower bitdepths, the solution is to set colorspace to Non-Color prior to baking.
This does not look like a bug to me, will archive (but of course feel free to comment again if issues persist or if this is a misunderstanding on my side).

@Sergey, @brecht, since you worked on #52334 (32 bit Float normal map are baked in sRGB instead of Linear) / e786ea6419 (and I am a bit on shaky ground), can you confirm my findings?

> In #94446#1293988, @CristianoSimao wrote: > I think this is a bug, because if changing to Non-Color before baking is the right way this should be a obligatory step also for non 32 bit normal maps also. > In #94446#1293975, @lichtwerk wrote: >> In #94446#1293950, @CristianoSimao wrote: >> Now following your steps I changed the color space to Non-Color **before** the image is saved, and then I saved as 16 bit PNG and all work OK, no more problem with this shadow colors. > Good! > >> But this is strange, for the other image formats this step is not necessary as you can see in my other posts. > With "image formats" you mean starting off with o non-32bit generated image? > If you havent touched the colorspace prior to baking there (these default to sRGB) and saving these happens to sRGB as well, there is no colorspace conversion, which I assume makes this unnecessary in your case. > I would assume if non-32bit generated images are set to anything else than sRGB prior to baking, similar issues (unwanted colorspace conversion) would take place there as well. > When saving to EXR, this saves in linear (same as the default for 32bit generated images, so also no colorspace conversion there). > > So to avoid any colorspace conversion when saving baked normalmaps in 32bit generated images to lower bitdepths, the solution is to set colorspace to `Non-Color` prior to baking. > This does not look like a bug to me, will archive (but of course feel free to comment again if issues persist or if this is a misunderstanding on my side). @Sergey, @brecht, since you worked on #52334 (32 bit Float normal map are baked in sRGB instead of Linear) / e786ea6419 (and I am a bit on shaky ground), can you confirm my findings?

Brecht Van Lommel commented

2022-01-24 19:16:50 +01:00

It's a known issue in the design. We don't apply any color space transform for baking.

For float it's not needed since the image data is already assumed to be scene linear, and we convert to whatever is needed by the image file on save.
For bytes what we'd technically have to is convert to whatever color space is specified. However this does then mean you have specify the color space before you bake, since any conversion afterwards is going to lose too much precision. So we allow it to be changed right before saving.

We may change this at some point along with bigger changes to the baking workflow, but for now it can break existing scripts or workflows.

It's a known issue in the design. We don't apply any color space transform for baking. * For float it's not needed since the image data is already assumed to be scene linear, and we convert to whatever is needed by the image file on save. * For bytes what we'd technically have to is convert to whatever color space is specified. However this does then mean you have specify the color space before you bake, since any conversion afterwards is going to lose too much precision. So we allow it to be changed right before saving. We may change this at some point along with bigger changes to the baking workflow, but for now it can break existing scripts or workflows.

Brecht Van Lommel changed title from ~~32 Bit Normal Map Generated inside Blender produces Dark materials.~~ to Inconsistent color space baking to float and byte images

2022-01-24 19:17:17 +01:00

Brecht Van Lommel commented

2022-01-24 19:17:31 +01:00

Changed status from 'Needs Developer To Reproduce' to: 'Confirmed'

yonghao lv commented

2022-05-12 01:04:18 +02:00

Added subscriber: @1029910278

yonghao lv commented

2022-05-12 01:04:18 +02:00

We may change this at some point along with bigger changes to the baking workflow, but for now it can break existing scripts or workflows.

found this problem when creating my own baking script. Among the bake addon I brought, I find out that most of them didn't know and fix this problem when bake 32bit and export to png.
This should be mention to the float_buffer property's tip or fix

> We may change this at some point along with bigger changes to the baking workflow, but for now it can break existing scripts or workflows. found this problem when creating my own baking script. Among the bake addon I brought, I find out that most of them didn't know and fix this problem when bake 32bit and export to png. This should be mention to the float_buffer property's tip or fix

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Inconsistent color space baking to float and byte images #94446