Advantages/disadvantages of various file formats for storing non-color texture data?

Question

We use normal maps, bump maps, and a lot of other special maps that contain non-color texture data. They are stored in image files but in linear color space (without gamma correction), and therefore we set the Color Space in the Image Texture node to Non-Color Data, as explained here: What exactly does the "Non-color data" option for image/environment textures do?

So far so good, but which is the best format? PNG seems to be popular, it can store 8 or 16 bits per channel, and unlike JPEG it does not suffer from compression artifacts since it uses lossless compression. I was satisfied with PNG, until in the comments of this question, color management expert troy_s said that he thinks EXR should be used for these files.

Since there was not enough space in the comments to go into details, I am asking this separately.

My biggest problem with EXR is that few programs can open it, and those programs start slowly, so I can't quickly check the contents outside Blender.

Answer 1

Due to comment limitations I am posting Yet Another Answer to one that is largely sufficiently explained already.

First, I would state rather vociferously that PNG is an absolutely diseased format. It has a foothold in Blender almost purely because it was set as default by someone a long, long time ago. My TL;DR is never use it in an imaging pipeline. Ever. Delivering to web? Have at you. In a pipeline? Keep it well the heck away.

With that out of the way, specifically, what are the shortcomings of display referred imaging encodes such as PNG when it comes to data? In no particular order:

• They were not designed for storing data. When we consider what data is, and its potential ranges, we can see things more clearly. Data should be viable to dip to negatives for some types of passes, as well as extend arbitrarily off into large values. Z buffer is an obvious example of the latter, and any origin 0.0 based data is a sample of the former. Examples include but are not limited to:

  • Normal (negative)
  • Vector (negative)
  • UV (negative)
  • Z (infinite)
  • Deep alpha (infinite)
  • Emission (infinite)
  • Environment (infinite)

• They almost exclusively don't play well in many other applications. Most applications are going to make unfortunate assumptions about your display referred encode. This will end up in a mangled mess. Even with applications that understand transfer functions, how many are applying them correctly? Is your application applying the sRGB two part transfer or a blind 2.2 power law? Is there some colour management happening via installed display profiles that you might miss? Even the much beloved Photoshop is an absolute dog at handling data despite storing it in the robust EXR format, including truncating 32 bit EXRs down to 16 bit.

• Quantisation. Given that many display referred formats are trapped storing integers, an imager is going to have a heck of a time expressing some ratios. 16 bits in float is a literal order of a magnitude different than 16 bit integer. Is your data format using a power law or purely linear storage approach? Those sorts of issues will end up impacting the influence quantisation has on your encoded values.

In the end summary, at some point it is very likely an experienced imager is going to ram into some mangled up data or value range that, when stored in a display referred encoding format, will cause nothing but heartache and heartburn. It is far easier to suggest that they simply start and end with EXR and avoid all problems through their entire pipeline than suggest "Use this here and that there, and be sure to do this" dark alchemy.

Answer 2

The "non-colour data" option means that colour transforms will be skipped and the RGB data will be used without any transforms. This requires of course that the image is already in the adequate format to be used. Using any 8-bit image format should be avoided for that kind of maps, because they're simply not adequate for storing linear images and the channel precision is simply not enough to store smooth gradients for bumps, normal maps, etc.

Of course, you can still use them, but quality will suffer, so it's really recommended to go for 16-bit.

In practice, the need of 16-bit will trim out a significant part of the graphics software offer. Current GIMP stable is out of the equation, so any other hobby-grade image manipulation or viewing software.

So if your problem is that you need to use a memory intensive program that takes a few seconds to load, you're out of luck because you won't find too many of them that support 16-bit and linear.

Also the list of formats shrinks: It's basically choosing between PNG (not suitable at all because you need linear), TIFF and EXR. And at any rate, you won't find significant differences between the filesize once you move to 16 bit.

With that in mind, it becomes quite clear that a half-float EXR is probably the most adequate choice, as the color-management expert troy_s pointed out. It's a de-facto standard in the CG and VFX industry, so it's no doubt the best choice for that kind of maps.

Answer 3

Without knowing exactly what you are trying to do it is impossible to give an accurate answer, without wondering too much into opinion based territory.

EXR is a High Dynamic Range format, with 16, 32 or 64 bits floating point values.

Unless you have very special precision needs, and really need that kind of range for your texture values I'd say it is overkill to use that (or any other HDR based) file formats.

It will needlessly increase file size, memory consumption and processing time, taking longer to render with no visible advantage or improved quality over other formats.

HDR formats for textures are generally used exclusively for environment maps where accurate lighting information may be desirable, and where the traditional 8 or 16 bits are not enough to hold all the possible values in the visible lighting range.