<p>A bump map should <strong>not</strong> be linearised from sRGB, in theory.</p>

<p>A diffuse map or photo contains colour data, which must be encoded in a colour space. Colour spaces consist of two things, a colour gamut (what kind of red is red, what kind of green is green, what kind of blue is blue and what kind of white is white) and a transfer functions (how do you allocate the limited bits, often called gamma). Without a colour space, we would not know how to interpret the data. Choosing to then simply interpret it as sRGB would just be an assumption, that could be wrong.</p>

<p>Bump maps, roughness maps, normal maps, etc. do not contain colour data, but rather geometric data, and therefor <strong>do not have a colour space</strong> and no transfer function. So, the data is already linear. Another way of thinking about it, is that a transfer function is about more efficiently allocating the limited bits. Our eyes see more detail in dark areas than bright areas, so we want more of the, often, 8 bits to be for the darker areas. However, with a bump map we want the bits to be spaced out evenly. So, a transfer function wouldn't be a good idea.</p>

<p>In some cases, a transfer function might be useful with a bump map. Maybe you have a lot of detail in a small range (between 0.0 and 0.4) but occasionally a spike to 1.0 that prevents you from scaling that small range up. You might want to have more precision in that small range and less precision in the spike because of the detail in the small range. This is perfect for a transfer function. There would still be no colour gamut, just a transfer function. Although, this doesn't happen often.</p>

<p>In some other cases, the artist or the program might have added a transfer function without realising it or thinking that since it was an image saved as, for example, a JPEG, it would have needed the transfer function. In these cases, you must apply the inverse of the transfer function to get the original values back.</p>

<p>In short, you should always assume, unless stated otherwise, that bump maps, roughness maps, normal maps, etc. are geometric data stored in the image file as-is and not using a transfer function. Most software that generate these maps will save them in linear.</p>

<p><em>Two irrelevant side notes:</em>
<em>In my simple explanation of colour spaces, I assumed that we are talking about three different values for red, green and blue. However, colour data can also be encoded in different ways and you have different colour spaces to reflect that. Examples are YCbCr or YUV, CMYK, LAB and XYZ.</em></p>

<p><em>People often talk about linear as if it is a colour space, however what you are just doing, when linearising, is applying the inverse transfer function. The colour gamut is still there. You still need to know what kind of red red is. If you would be linearising sRGB or Rec.709, you would be talking about (scene-)linear sRGB. But, most people will understand you anyways.</em></p>

CC BY-SA 4.0
2020-04-28T21:43:16.303Z
2020-04-28T21:43:16.303Z
bram0101
<p>We can not answer this question. This is important, and you need to get this info from the artist (or vice versa you need to give this info to the artist before he begins) It entirely depends on what kind of assumptions were made when the artist was working with the image.</p>

<ol>
<li>Was the artist working by numbers</li>
<li>Was the artist working by eye</li>
<li>Was the artist working with a sculpting application</li>
<li>Was the data built from a photograph</li>
</ol>

<p>You would be right if the artist worked by number. But if the artist was working by eye, which is incredibly hard, then you would be a bit off. sRGB does not entirely match human brightness sense so you should really fiddle a bit with the exponent if this was the case. But you might as well skip this. For sculpting and baking the image is most likely to be linear already to begin with, although the profile might not reflect this. And for the photograph case depends heavily on the method.</p>

<p>Safest bet is to do no conversion at all. But it is not really defined so strictly. Kind of the entire world of image manipulation has skipped how to tag images that arent you know display images but pure data. Who knows how it is encoded.</p>

CC BY-SA 4.0
2020-04-28T20:42:40.107Z
2020-04-29T07:38:37.813Z
2020-04-29T07:38:37.813Z
joojaa
<p>By a bumpmap, I mean the black and white height map, not the rgb normal map style one. If I were to convert a bumpmap to a normal map then I don't think I should linearize the values because if an artist creates two pixels, one looking twice as bright to them, and therefore high, let's say at 0.2 and 0.4 values in sRGB, this is how they should be read and what the normals should be based on, right?</p>

<p>Converting them from sRGB to linear would mean that what looked liked two pixels with a height difference of 2 times (0.2 and 0.4) would get read as (0.03 and 0.13), if I got the calculation right. </p>

<gamma>
Does a bumpmap need to be linearized from sRGB when being read?
Zebrafish
# Does a bumpmap need to be linearized from sRGB when being read?

(Asked by: username_0 on 2020-04-28)

By a bumpmap, I mean the black and white height map, not the rgb normal map style one. If I were to convert a bumpmap to a normal map then I don't think I should linearize the values because if an artist creates two pixels, one looking twice as bright to them, and therefore high, let's say at 0.2 and 0.4 values in sRGB, this is how they should be read and what the normals should be based on, right?

Converting them from sRGB to linear would mean that what looked liked two pixels with a height difference of 2 times (0.2 and 0.4) would get read as (0.03 and 0.13), if I got the calculation right.

**Tags:** gamma


---

## 2 answers

### Answer by username_1 on 2020-04-28. Score: 1

A bump map should **not** be linearised from sRGB, in theory.

A diffuse map or photo contains colour data, which must be encoded in a colour space. Colour spaces consist of two things, a colour gamut (what kind of red is red, what kind of green is green, what kind of blue is blue and what kind of white is white) and a transfer functions (how do you allocate the limited bits, often called gamma). Without a colour space, we would not know how to interpret the data. Choosing to then simply interpret it as sRGB would just be an assumption, that could be wrong.

Bump maps, roughness maps, normal maps, etc. do not contain colour data, but rather geometric data, and therefor **do not have a colour space** and no transfer function. So, the data is already linear. Another way of thinking about it, is that a transfer function is about more efficiently allocating the limited bits. Our eyes see more detail in dark areas than bright areas, so we want more of the, often, 8 bits to be for the darker areas. However, with a bump map we want the bits to be spaced out evenly. So, a transfer function wouldn't be a good idea.

In some cases, a transfer function might be useful with a bump map. Maybe you have a lot of detail in a small range (between 0.0 and 0.4) but occasionally a spike to 1.0 that prevents you from scaling that small range up. You might want to have more precision in that small range and less precision in the spike because of the detail in the small range. This is perfect for a transfer function. There would still be no colour gamut, just a transfer function. Although, this doesn't happen often.

In some other cases, the artist or the program might have added a transfer function without realising it or thinking that since it was an image saved as, for example, a JPEG, it would have needed the transfer function. In these cases, you must apply the inverse of the transfer function to get the original values back.

In short, you should always assume, unless stated otherwise, that bump maps, roughness maps, normal maps, etc. are geometric data stored in the image file as-is and not using a transfer function. Most software that generate these maps will save them in linear.

*Two irrelevant side notes:*
*In my simple explanation of colour spaces, I assumed that we are talking about three different values for red, green and blue. However, colour data can also be encoded in different ways and you have different colour spaces to reflect that. Examples are YCbCr or YUV, CMYK, LAB and XYZ.*

*People often talk about linear as if it is a colour space, however what you are just doing, when linearising, is applying the inverse transfer function. The colour gamut is still there. You still need to know what kind of red red is. If you would be linearising sRGB or Rec.709, you would be talking about (scene-)linear sRGB. But, most people will understand you anyways.*


---

### Answer by username_2 on 2020-04-28. Score: 1

We can not answer this question. This is important, and you need to get this info from the artist (or vice versa you need to give this info to the artist before he begins) It entirely depends on what kind of assumptions were made when the artist was working with the image.

1. Was the artist working by numbers
2. Was the artist working by eye
3. Was the artist working with a sculpting application
4. Was the data built from a photograph

You would be right if the artist worked by number. But if the artist was working by eye, which is incredibly hard, then you would be a bit off. sRGB does not entirely match human brightness sense so you should really fiddle a bit with the exponent if this was the case. But you might as well skip this. For sculpting and baking the image is most likely to be linear already to begin with, although the profile might not reflect this. And for the photograph case depends heavily on the method.

Safest bet is to do no conversion at all. But it is not really defined so strictly. Kind of the entire world of image manipulation has skipped how to tag images that arent you know display images but pure data. Who knows how it is encoded.


---

