Baked normal map from highpoly to lowpoly is too pale unless baking to new image #54731

New Issue

Mr Zak · 2018-04-19T19:03:26+02:00

Mr Zak commented

2018-04-19 19:03:26 +02:00

System Information
Operating system: Win7

Blender Version
Broken: tested on Blender 2.79a RC2 and Blender 2.79b f4dc9f9d68

Short description of error
When baking a normal map from highpoly to lowpoly it works up to a certain moment. After some amount of rebakes to the same image (overwriting results) the baked normal map becomes very bright, has values of Hue = 0,667; Sat = 0,2646; Value = 1,0 for the background area (where there should be no normal effect). Default map has Hue = 0,667; Sat = 0,4980; Val = 1,0. So only saturation changes.
The meshes in the file attached are a stripdown version of the mesh with which I catched the bug once again.

Exact steps for others to reproduce the error
Baking-Pale-Normal-Map.blend

Open the file attached. There is Image Texture node with red background color and name "Normal-Map-Will-Be-PALE" in the Node editor window. It is active and baking will happen on the image linked to it. There are 2 example meshes selected in the viewport window - highpoly first, lowpoly last. There is resulting normal map shown in the UV Image editor.
As the selection is already present, press Bake. The resulting map should become the same as one provided (packed), too desaturated.

{F2842859}

In the Image Texture node below the red one create new image, link it to the node and bake to it. The result should turn out as usual normal map.

{F2842874}

**System Information** Operating system: Win7 **Blender Version** Broken: tested on Blender 2.79a RC2 and Blender 2.79b f4dc9f9d68b **Short description of error** When baking a normal map from highpoly to lowpoly it works up to a certain moment. After some amount of rebakes to the same image (overwriting results) the baked normal map becomes very bright, has values of Hue = 0,667; Sat = 0,2646; Value = 1,0 for the background area (where there should be no normal effect). Default map has Hue = 0,667; Sat = 0,4980; Val = 1,0. So only saturation changes. The meshes in the file attached are a stripdown version of the mesh with which I catched the bug once again. **Exact steps for others to reproduce the error** [Baking-Pale-Normal-Map.blend](https://archive.blender.org/developer/F2842885/Baking-Pale-Normal-Map.blend) 1. Open the file attached. There is Image Texture node with red background color and name "Normal-Map-Will-Be-PALE" in the Node editor window. It is active and baking will happen on the image linked to it. There are 2 example meshes selected in the viewport window - highpoly first, lowpoly last. There is resulting normal map shown in the UV Image editor. 2. As the selection is already present, press Bake. The resulting map should become the same as one provided (packed), too desaturated. ``` {F2842859} ``` 3. In the Image Texture node below the red one create new image, link it to the node and bake to it. The result should turn out as usual normal map. ``` {F2842874} ```

Mr Zak commented

2018-04-19 19:03:26 +02:00

Added subscriber: @MrZak

Philipp Oeser commented

2018-04-23 13:06:46 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2018-04-23 13:06:46 +02:00

Changed status from 'Open' to: 'Archived'

Philipp Oeser closed this issue

2018-04-23 13:06:46 +02:00

Philipp Oeser self-assigned this 2018-04-23 13:06:46 +02:00

Philipp Oeser commented

2018-04-23 13:06:46 +02:00

Make sure you set your image up as Non-Color Data.
This way blender doesnt color-manage your image (which is required for baking correct normal maps)

Also see the manual .

Dont think there is a bug here...

Make sure you set your image up as `Non-Color Data`. This way blender doesnt color-manage your image (which is required for baking correct normal maps) ![#54731.png](https://archive.blender.org/developer/F2955502/T54731.png) Also see [the manual ](https://docs.blender.org/manual/en/dev/render/post_process/color_management.html?#image-files). Dont think there is a bug here...

Mr Zak commented

2018-04-24 13:53:41 +02:00

In #54731#496278, @lichtwerk wrote:
Make sure you set your image up as Non-Color Data.

In any way - regardless of Color or Non-Color data - when I start baking normal map, especially with non-saved image or with saved one as well (up to certain amount of rebakes, often without anything happening like what is shown above) I don't get that behaviour:

or after saving image

From what I see this is an unexpected behaviour since it happens only sometimes and most often this won't happen if previewing normal map in sRGB color space as well. Or when saving image to some format with certain color space conversion the image should always be shown with changes that conversion caused if this is really something to expect. Anyway then it will happen always without any randomness.

> In #54731#496278, @lichtwerk wrote: > Make sure you set your image up as `Non-Color Data`. In any way - regardless of Color or Non-Color data - when I start baking normal map, especially with non-saved image or with saved one as well (up to certain amount of rebakes, often without anything happening like what is shown above) I don't get that behaviour: ![baking-normal-map-ok-sRGB.jpg](https://archive.blender.org/developer/F2973612/baking-normal-map-ok-sRGB.jpg) or after saving image ![baking-normal-map-ok-sRGB.jpg](https://archive.blender.org/developer/F2973639/baking-normal-map-ok-sRGB.jpg) From what I see this is an unexpected behaviour since it happens only sometimes and most often this won't happen if previewing normal map in sRGB color space as well. Or when saving image to some format with certain color space conversion the image should always be shown with changes that conversion caused if this is really something to expect. Anyway then it will happen always without any randomness.

Philipp Oeser commented

2018-04-24 15:24:36 +02:00

Hm, there might be something going on here, but I am really not able to reproduce by baking myself (tried lots of times)

So even your example file always works for me when I unpack the image, change to non-color and rebake... always.

One thing that I do find a little strange is that blender is not able to generate a preview icon (the image datablock selector in the Image Editor)... but needs more investigation...

Hm, there might be something going on here, but I am really not able to reproduce by baking myself (tried **lots** of times) So even your example file always works for me when I unpack the image, change to non-color and rebake... always. One thing that I do find a little strange is that blender is not able to generate a preview icon (the image datablock selector in the Image Editor)... but needs more investigation...

Mr Zak commented

2018-04-24 17:47:54 +02:00

But if you don't change image to Non-Color before baking?

Thing is, I haven't really changed it to Non-Color since it was working just fine without that. I always change to Non-Color in the Image Texture node with the map but it's not related here at all as this is in the Node Editor.
I wanted consistency - if data changes that much that without Non-Color colors of the image will be less saturated then it should have changed always. Or not change at all.
So as I see my example isn't generating error except for my own machine. Nice to know.

But if you don't change image to Non-Color before baking? Thing is, I haven't really changed it to Non-Color since it was working just fine without that. I always change to Non-Color in the Image Texture node with the map but it's not related here at all as this is in the Node Editor. I wanted consistency - if data changes that much that without Non-Color colors of the image will be less saturated then it should have changed always. Or not change at all. So as I see my example isn't generating error except for my own machine. Nice to know.

Philipp Oeser commented

2018-04-25 15:35:44 +02:00

Changed status from 'Archived' to: 'Open'

Philipp Oeser reopened this issue

2018-04-25 15:35:44 +02:00

Philipp Oeser commented

2018-04-25 15:35:44 +02:00

will do some further testing later, so this doesnt get lost