4
$\begingroup$

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.

Improve this question
$\endgroup$
1
  • 1
    $\begingroup$ Btw, check out DJV if you need a free and fast-starting openEXR viewer: djv.sourceforge.net $\endgroup$
    – JtheNinja
    Dec 29, 2016 at 2:35

3 Answers 3

Reset to default
5
$\begingroup$

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.

Improve this answer
$\endgroup$
5
  • 2
    $\begingroup$ I fully understand and accept that the rendered image passes should be saved as EXR, I am only talking about non-color maps, such as normal and displacement maps. I also understand that in a pipeline, where some artists have a vague understanding of technical terms, it is easier to tell them to always use the safe option, but let's suppose that we are talking about competent people. Anyway in the end I am probably accept this answer, since you told clearly your arguments, and the essence of the questions was "what arguments are there for EXR". Thank you! $\endgroup$
    – lbalazscs
    Dec 29, 2016 at 1:52
  • $\begingroup$ @lbalazscs Have a look at depth, deep compositing, and how many other passes are stored across applications and you will get a bigger picture of the range of data values and why display referred image encodings are a poor choice. Just on data alone, there is enough merit, let alone image data. $\endgroup$
    – troy_s
    Dec 29, 2016 at 2:06
  • 2
    $\begingroup$ @troy_s asked me to add some info on which passes are negative: Normal and vector can both have negative values since they represent directions. UV can in theory as well if a mesh has negative UV coordinates. Additionally, Z, the direct/indirect passes, and emission and environment passes have no upper bound, although I don't think they go below zero. $\endgroup$
    – JtheNinja
    Dec 29, 2016 at 3:08
  • $\begingroup$ Z values have an upper and a lower bound, specified by the near and far clipping plane of the camera. $\endgroup$
    – piegames
    Dec 29, 2016 at 11:18
  • $\begingroup$ @piegames Theoretically infinite. The bounds float. Of course there are practical bit depth quantisation limits, but those shift as architecture. $\endgroup$
    – troy_s
    Dec 29, 2016 at 15:17
3
$\begingroup$

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.

Improve this answer
$\endgroup$
11
  • $\begingroup$ I already do understand what is the "non-colour data" option, but I don't understand your argument, because it is possible to store linearly encoded data in PNG pixels... You just have to use the "non-colour data" option :) $\endgroup$
    – lbalazscs
    Dec 29, 2016 at 0:55
  • $\begingroup$ Sure, but every single graphics program out there will assume that your 8-bit imagery is nonlinear, because 8 bit is not adequate for storing linear data (you get only 46 steps to store all the values under middle gray). So when you process 8 bit images in a program like Photoshop or GIMP, the default behavior will be to assume that they are non-linear and all the operations will be performed under that premise. Long story short: Editing 8-bit images will most likely screw your maps. And even if it didn't, 256 levels per channel is still insufficient precision for your maps. $\endgroup$
    – Gez
    Dec 29, 2016 at 1:01
  • $\begingroup$ That is not true, for example Substance Painter and other 3d painting programs are very much aware about the difference between linear and non-linear, and in linear mode they will store 128 steps under "middle gray". And don't forget that PNG can also be 16 bits. $\endgroup$
    – lbalazscs
    Dec 29, 2016 at 1:11
  • 2
    $\begingroup$ @lbalazscs I would add one significant show stopper against PNG, with many more in tow regarding actual image storage. The first is that it can't handle data. Why do I say that? Because data is technically unbounded and encompasses negative values and greater than 1.0 values, something that 99.5% of imaging storage containers fail miserably at. You also don't have control over integer versus float, so your quantization is destroyed. Finally, if you consider actual imaging, it can't store associated alpha which is also likely why it has zero uptake anywhere beyond the web. $\endgroup$
    – troy_s
    Dec 29, 2016 at 1:18
  • 1
    $\begingroup$ @lbalazscs: No, actually your sentence is not true: the "non-colour data" option doesn't mean it interprets the PNG data as linear. It interprets pixels as non-colour data, as the name indicates. It just ignores any colorspace information and takes the raw RGB(A) data from pixels without any colour management. Linear and non-linear are only relevant to pixels as light intensity, and that has to be color managed. $\endgroup$
    – Gez
    Dec 31, 2016 at 1:59
1
$\begingroup$

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.

Improve this answer
$\endgroup$
5
  • $\begingroup$ I don't have a specific scenario in mind, I am thinking in general about non-color maps, like normal, displacement etc. Their values are usually in the 0..1 range, so I don't think HDR helps. Although it it interesting to image arbitrarily large displacements, encoded exactly in the map. $\endgroup$
    – lbalazscs
    Dec 29, 2016 at 0:48
  • $\begingroup$ Why exactly do you think that a 16-bit floating point format file is larger than a 16-bit integer format file? $\endgroup$
    – lbalazscs
    Dec 29, 2016 at 1:06
  • 2
    $\begingroup$ HDR is a misnomer in this context. Files will be used as data containers, not as light intensity, so there's no dynamic range into play, it's rather more precision to store smoother gradients. When you use 8 bit intergers, each channel gives you only 256 steps, which means that your displacements for instance will look more like stairs than like smoot gradients. You need more precision. Period. $\endgroup$
    – Gez
    Dec 29, 2016 at 1:11
  • $\begingroup$ Not only light can have high range, but let's not argue about terminology :) And I am fully aware that 16 bits give more precision than 8, that is not the question. $\endgroup$
    – lbalazscs
    Dec 29, 2016 at 1:16
  • $\begingroup$ @lbalazscs Not sure specifically about 16-bit floating point vs 16-bit integer, but generally floatpoint files are larger because they hold more information $\endgroup$
    – Duarte Farrajota Ramos ♦
    Dec 29, 2016 at 1:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .