16bit half-float linear HDR images as (diffuse/albedo) textures?

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.

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.

• 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 May 10 '16 at 19:27
• @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 May 30 '16 at 17:31
• @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 May 30 '16 at 17:34

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.

• 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 May 10 '16 at 0:50
• 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 May 10 '16 at 7:32
• @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 May 10 '16 at 7:39
• @NathanReed Yes, you most certainly made some really good points there :) – Kristoffer Helander May 10 '16 at 7:54

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.