<p>Yes, it's possible in some extreme cases for HDR lighting and tonemapping to expose banding issues in color textures. In those cases, having a higher bit depth for the textures could be useful. However, in my experience the majority of materials and ordinary lighting situations don't exhibit this problem, and most textures in a typical game are fine in 8-bit (or even less&mdash;games often use BC1 compression, which reduces them to 5-6-5-bit).</p>

<p>People use HDR render targets because a single scene can contain vastly different magnitudes of brightness, such as a dark room in which you can see through a window to a sunlit exterior 10&ndash;100 times brighter than the room. However, color textures don't have such a wide range of magnitudes. They represent reflectances, which are inherently in the [0, 1] range, and in practice few everyday materials are lower than about 2&ndash;5% reflectance. So an 8-bit image (with gamma encoding) can usually represent diffuse and specular colors with enough precision.</p>

<p>It's true that the combination of a quite dark texture with very bright lighting or an extremely overexposed camera setting can show banding in the final frame, but that would be a more unusual case.</p>

<p>A case where you probably <em>would</em> want an HDR texture is emissive materials, especially for neon signs and similar light sources. The texture would appear with its value amped up to appear as a bright light source in game, so in that case an 8-bit image could easily show banding.</p>

<p>Finally, it can still be useful to work at higher precision (e.g. 16-bit precision) if possible when capturing and creating textures, simply because it gives you more headroom to process the image without causing precision problems. For instance, if you need to adjust levels or color balance, you lose a little precision; that can introduce banding (especially if you do it multiple times) when starting from an 8-bit source image. A 16-bit source would be more resilient to such problems. However, the final texture used in the game would still probably be compressed to 8-bit.</p>

CC BY-SA 3.0
2016-05-10T00:50:33.420Z
`combination of a quite dark texture with very bright lighting or an extremely overexposed camera setting can show banding in the final frame` very good insight. But we may note that gamma encoding is here precisely to mitigate this point. If he has the problem why not try a superior gamma exponent ? that would inhibit usage of hardware sRGB samplers though.
v.oddou
CC BY-SA 3.0
2016-05-10T07:32:58.720Z
Thank you for your input. But to clarify, I'm mostly interested in this from a photo realistic rendering point of view, with ray trace renderers (like mental ray, V-Ray, Arnold, etc.) with full light simulations and global illumination, rather then for real-time game engines.
Kristoffer Helander
CC BY-SA 3.0
2016-05-10T07:39:04.373Z
@KristofferHelander Good to know, but I think what I wrote probably applies just as well to offline rendering. But I admit that I don't have much direct experience in that area.
Nathan Reed
CC BY-SA 3.0
2016-05-10T07:54:49.367Z
@NathanReed Yes, you most certainly made some really good points there :)
Kristoffer Helander
CC BY-SA 3.0
2016-05-07T06:17:59.660Z
2016-05-07T06:17:59.660Z
Nathan Reed
<p>I'd like to invite readers to read this article about <a href="http://fabiensanglard.net/quake2/quake2_software_renderer.php" rel="noreferrer">Quake 2 engine rasterization technology explained in details</a>, if they have the time.</p>

<p>If TLDR, please pay attention to this image:
<a href="https://i.sstatic.net/j4i57.jpg" rel="noreferrer"><img src="https://i.sstatic.net/j4i57.jpg" alt="enter image description here"></a></p>

<p>What we see is the <strong>Albedo</strong> channel, that's what you want to encode in 16 bits if I understand your question correctly.<br>
I'm not going to say "<em>if it could be encoded in 256 colors for games in the past, why would we need 281474976710656 (that's 281 trillion) in new games?</em>" even if I want to but that sounds like pixar's grumpy guy from Up. More constructively, if you noted in this image, <strong>everything is at the same lighting level</strong>. More particularly, the maximum intensity possible that preserves the desired saturation. (meaning in HSV space, V is maxed out)</p>

<p>The emphasis is key, we barely need any bits because albedo has no depth to encode anyway. The dynamic comes from the shading, it makes sense to work in <code>f32</code> per components within shaders, and output to <code>f16</code> render targets. But storing albedo textures in <code>f16</code> that's not only overkill, that's a severe unjustified performance hog for our precious bandwidth.</p>

CC BY-SA 3.0
2016-05-10T07:33:27.423Z
Thank you for your input. But to clarify, I'm mostly interested in this from a photo realistic rendering point of view, with ray trace renderers (like mental ray, V-Ray, Arnold, etc.) with full light simulations and global illumination, rather then for real-time game engines. I've updated my original post.
Kristoffer Helander
CC BY-SA 3.0
2016-05-10T00:42:44.313Z
2016-05-10T00:42:44.313Z
v.oddou
<p>In film production, we almost never use 8-bit textures for color/albedo, because of banding, etc. (JPEG is especially problematic since by spec, it's sRGB rather than linear values.) We either use 'half' (16 bit float) or 16-bit unsigned integer values for color/albedo textures.</p>

CC BY-SA 3.0
2016-05-10T19:27:15.013Z
Wow, thanks @LarryGritz! Considering you work for Sony Pictures Imageworks, I'll take you as a very reliable source! :)

But how do you capture these textures? Most cameras only shoot in 14bit RAW files, do you have special cameras with 16bit linear sensors? Or do you take multiple exposures for textures, just like one does for HDRI imaged based lighting? Or do you simply capture with 14bit camera RAW and saves it as "16bit"? Ow, and what file format do you use, .tiff (.tx, .tex) or .exr?
Thanks again for your input!! :)
Kristoffer Helander
CC BY-SA 3.0
2016-05-30T17:31:00.883Z
@KristofferHelander :  Converting from 14 bit capture to a 16 bit representation of the 0-1 range is easily achieved by multiplication. But most of our textures are painted, not photographed -- sometimes they are painted directly in a 16 bit format, sometimes they are painted in sRGB and then converted to 16 bit when "linearized" for use as a texture. There's no need for HDR for albedo textures.
Larry Gritz
CC BY-SA 3.0
2016-05-30T17:34:53.267Z
@KristofferHelander : For albedo textures, we tend to use TIFF with 16 bit integer data (what we call .tx is just TIFF format but tiled and with MIP-map multiresolution stored as multiple subimages within the TIFF file). For true HDR data, like environment captures, we use OpenEXR. Renderer output also tends to be OpenEXR.
Larry Gritz
CC BY-SA 3.0
2016-05-10T18:27:56.747Z
2016-05-10T18:27:56.747Z
Larry Gritz
<p>So I been thinking about this for a while and tried to google for an answer but without any success.</p>

<p>If all your textures are 8bit LDR images, like JPEGs, couldn't that potentially cause conflicts with exposure control/tone mapping when rendering. That is if you adjust the rendering exposure of your image that should expose detail in the textures that aren't really there, since they been clamped out by the low dynamic range. So wouldn't it make sense to also have the textures as HDR images, saved as .exr, in linear colour space with 16bit half-float to get a good colour representation (32bit "full" float might be overkill?). To have more detailed and correct colour values might also, I figure, have an effect on GI and how colour bleed is calculated?</p>

<p>Or is it simply not necessary since the end result of the rendering we want is probably going to be similar to the exposure level of the texture when it was photographed any way? And since camera mostly shoot in 12-14bit you would have to take multiple exposures of the texture and do all that extra work to piece them all together to one HDRI. </p>

<p><strong>Edit:</strong> <em>To clarify, I'm mostly interested in this from a photo realistic rendering point of view, with ray trace renderers (like mental ray, V-Ray, Arnold, etc.) with full light simulations and global illumination, rather then for real-time game engines.</em></p>

<texture><physically-based><pbr><diffuse>
16bit half-float linear HDR images as (diffuse/albedo) textures?
Kristoffer Helander
# 16bit half-float linear HDR images as (diffuse/albedo) textures?

(Asked by: username_0 on 2016-05-06)

So I been thinking about this for a while and tried to google for an answer but without any success.

If all your textures are 8bit LDR images, like JPEGs, couldn't that potentially cause conflicts with exposure control/tone mapping when rendering. That is if you adjust the rendering exposure of your image that should expose detail in the textures that aren't really there, since they been clamped out by the low dynamic range. So wouldn't it make sense to also have the textures as HDR images, saved as .exr, in linear colour space with 16bit half-float to get a good colour representation (32bit "full" float might be overkill?). To have more detailed and correct colour values might also, I figure, have an effect on GI and how colour bleed is calculated?

Or is it simply not necessary since the end result of the rendering we want is probably going to be similar to the exposure level of the texture when it was photographed any way? And since camera mostly shoot in 12-14bit you would have to take multiple exposures of the texture and do all that extra work to piece them all together to one HDRI.

**Edit:** *To clarify, I'm mostly interested in this from a photo realistic rendering point of view, with ray trace renderers (like mental ray, V-Ray, Arnold, etc.) with full light simulations and global illumination, rather then for real-time game engines.*

**Tags:** texture, physically-based, pbr, diffuse


---

## 3 answers

### Answer by username_3 on 2016-05-10. Score: 9 | Accepted answer

In film production, we almost never use 8-bit textures for color/albedo, because of banding, etc. (JPEG is especially problematic since by spec, it's sRGB rather than linear values.) We either use 'half' (16 bit float) or 16-bit unsigned integer values for color/albedo textures.

> **Comments:**
> **username_0**: Wow, thanks @username_3! Considering you work for Sony Pictures Imageworks, I'll take you as a very reliable source! :)  But how do you capture these textures? Most cameras only shoot in 14bit RAW files, do you have special cameras with 16bit linear sensors? Or do you take multiple exposures for textures, just like one does for HDRI imaged based lighting? Or do you simply capture with 14bit camera RAW and saves it as "16bit"? Ow, and what file format do you use, .tiff (.tx, .tex) or .exr? Thanks again for your input!! :)  
> **username_3**: @username_0 :  Converting from 14 bit capture to a 16 bit representation of the 0-1 range is easily achieved by multiplication. But most of our textures are painted, not photographed -- sometimes they are painted directly in a 16 bit format, sometimes they are painted in sRGB and then converted to 16 bit when "linearized" for use as a texture. There's no need for HDR for albedo textures.  
> **username_3**: @username_0 : For albedo textures, we tend to use TIFF with 16 bit integer data (what we call .tx is just TIFF format but tiled and with MIP-map multiresolution stored as multiple subimages within the TIFF file). For true HDR data, like environment captures, we use OpenEXR. Renderer output also tends to be OpenEXR.  

---

### Answer by username_1 on 2016-05-07. Score: 8

Yes, it's possible in some extreme cases for HDR lighting and tonemapping to expose banding issues in color textures. In those cases, having a higher bit depth for the textures could be useful. However, in my experience the majority of materials and ordinary lighting situations don't exhibit this problem, and most textures in a typical game are fine in 8-bit (or even less—games often use BC1 compression, which reduces them to 5-6-5-bit).

People use HDR render targets because a single scene can contain vastly different magnitudes of brightness, such as a dark room in which you can see through a window to a sunlit exterior 10–100 times brighter than the room. However, color textures don't have such a wide range of magnitudes. They represent reflectances, which are inherently in the [0, 1] range, and in practice few everyday materials are lower than about 2–5% reflectance. So an 8-bit image (with gamma encoding) can usually represent diffuse and specular colors with enough precision.

It's true that the combination of a quite dark texture with very bright lighting or an extremely overexposed camera setting can show banding in the final frame, but that would be a more unusual case.

A case where you probably *would* want an HDR texture is emissive materials, especially for neon signs and similar light sources. The texture would appear with its value amped up to appear as a bright light source in game, so in that case an 8-bit image could easily show banding.

Finally, it can still be useful to work at higher precision (e.g. 16-bit precision) if possible when capturing and creating textures, simply because it gives you more headroom to process the image without causing precision problems. For instance, if you need to adjust levels or color balance, you lose a little precision; that can introduce banding (especially if you do it multiple times) when starting from an 8-bit source image. A 16-bit source would be more resilient to such problems. However, the final texture used in the game would still probably be compressed to 8-bit.

> **Comments:**
> **username_2**: `combination of a quite dark texture with very bright lighting or an extremely overexposed camera setting can show banding in the final frame` very good insight. But we may note that gamma encoding is here precisely to mitigate this point. If he has the problem why not try a superior gamma exponent ? that would inhibit usage of hardware sRGB samplers though.  
> **username_0**: Thank you for your input. But to clarify, I'm mostly interested in this from a photo realistic rendering point of view, with ray trace renderers (like mental ray, V-Ray, Arnold, etc.) with full light simulations and global illumination, rather then for real-time game engines.  
> **username_1**: @username_0 Good to know, but I think what I wrote probably applies just as well to offline rendering. But I admit that I don't have much direct experience in that area.  
> **username_0**: @username_1 Yes, you most certainly made some really good points there :)  

---

### Answer by username_2 on 2016-05-10. Score: 5

I'd like to invite readers to read this article about [Quake 2 engine rasterization technology explained in details](http://fabiensanglard.net/quake2/quake2_software_renderer.php), if they have the time.

If TLDR, please pay attention to this image:
[![enter image description here](https://i.sstatic.net/j4i57.jpg)](https://i.sstatic.net/j4i57.jpg)

What we see is the **Albedo** channel, that's what you want to encode in 16 bits if I understand your question correctly.  
I'm not going to say "*if it could be encoded in 256 colors for games in the past, why would we need 281474976710656 (that's 281 trillion) in new games?*" even if I want to but that sounds like pixar's grumpy guy from Up. More constructively, if you noted in this image, **everything is at the same lighting level**. More particularly, the maximum intensity possible that preserves the desired saturation. (meaning in HSV space, V is maxed out)

The emphasis is key, we barely need any bits because albedo has no depth to encode anyway. The dynamic comes from the shading, it makes sense to work in `f32` per components within shaders, and output to `f16` render targets. But storing albedo textures in `f16` that's not only overkill, that's a severe unjustified performance hog for our precious bandwidth.

> **Comments:**
> **username_0**: Thank you for your input. But to clarify, I'm mostly interested in this from a photo realistic rendering point of view, with ray trace renderers (like mental ray, V-Ray, Arnold, etc.) with full light simulations and global illumination, rather then for real-time game engines. I've updated my original post.  

---

