As of release of Blender 2.8 version the Image texture node has changed, before we had only "Color Data" and "Non color data". Now we have that drop down menu titled "Color space" and various types to choose from.
My question is when we use which type of color data (do we still use "Non color" for normal maps, roughness etc or do we choose one of new ones)?
In short:
More details:
I've dig a bit into Blender code and into OpenColorIO (OCIO) documentation and my (very young and superficial) understanding is the following.
Blender uses a processor component to handle image data. This processor can be based on OCIO or be a 'fall back' one if OCIO is not present (I don't know why it could be absent... maybe to allow Blender to run on some low level hardware?).
The main goal of OCIO is to allow to transform image data into device rendered image data which fits the best to human eyes perspective as (for instance) our perception of light intensity is not linear (so intensity can be coded or manipulated linearly, as it is, but rendered differently). But more globally, OCIO can process image data transformation 'the way you want'.
OpenColorIO is a set of libraries (programs) that are provided OCIO organisation and these libraries are open source.
From that, when an image is processed (in our case for texture nodes) it is given to OCIO to do it. And OCIO is based on a configuration that can be found in 'Your installation path\2.8\2.80\datafiles\colormanagement'.
In this directory, we can find a file called 'config.ocio' (describing the possible configurations) and two subdirectories 'filmic' and 'lut' (containing data tables used by these configurations).
LUT stands for 'look up table'. For image calibration it has been defined by Academy Color Encoding Specification (ACES). Linear ACES is one of the possible option for the texture node.
Filmic is another calibration approach. The best is to read this answer from troy_s to know more.
The general principle of OCIO configuration seems to be giving a range to the input data and apply a transformation table to it. Transformations can be direct or reverse.
Concretely, what about 'XYZ', 'sRGB', 'Raw', 'Non-color', 'Linear ACES', 'Linear' and 'Filmic-Log'?
XYZ
'XYZ' is not 3D vector (x, y, z).
CIE XYZ is a calibration and its result is analogous to the LMS color space which corresponds to the cones response of the human eyes. Y is the luminance. Z is nearly the blue. X is a mixing factor. The response value for them is defined in the OCIO configuration.
This is a transformed data.
sRGB
Stands for Standard RGB and is the "default color space for byte image" as defined in 'config.ocio'. It also has a transformation table defined in it.
This is a transformed data.
Raw
'Raw' is the image encoded data as it is. There is no transformations for it.
This is not a transformed data.
Non-color
This is similar to 'raw' from the calculation point of view. But it is semantically different as it is for things we know to be 'non color'. The comment in config.ocio says "color space used for images which contains non-color data (i,e, normal maps)".
This is not a transformed data.
Linear ACES
It is transformed by OCIO. The configuration is linear (as said in it name) and is done from a table giving parameters of this operation for each color channel.
This is a transformed data.
Linear
Correspond to Rec. 709 (Full Range) and is commented as 'Blender native linear space'.
This is a transformed data.
Filmic-Log
Again please refer to this answer. It is commented as 'Log based filmic shaper with 16.5 stops of latitude, and 25 stops of dynamic range'.
This is a transformed data.
A link to OCIO configuration in the Blender repository.
Note:
When using an image texture node, the color space information is given by or set to the image texture itself. This is not a node property. So that, if you set the color space in one material, this will affect all the others that are using the same texture.
I believe this is a duplicate, but likely bears answering.
If the thing in question refers to a colour, it should be an appropriate colour based transform. Data, such as depth, height, etc. should be a non-colour transform, which currently in Blender is only a single transform.
Think of the colour transform selector as a means for you, the pixel pusher, to describe to the software how your file is encoded and what it’s purpose is. It relies on the person guiding the software to understand how the encoding is formatted. Is it encoded nonlinearly with sRGB’s OETF and primaries and requires it to be linearised? Is the encoding an EXR and the image buffer requires changing the light emissions from the encoded state to your working reference light assumptions?
That box is how one describes the file encoding to the software.
Updating answer to specifically address Rich’s question:
Initial tests seem to indicate that 'Raw' and 'Non-color' are identical but each of the others produce different output. I can't find any up to date documentation but I'd be very interested to learn the differences between these modes.
Once you realize that the entire pipeline is dealing with data, it becomes more clear. We can further break down data into two distinct classes, being colour and non-colour.
So what’s the difference?
Identifying a block of code values as non-colour data means that the data will remain untransformed from the buffer encoding, typically suited for treating data "as is". If the code values represent a colour, in all instances the code values must be subject to a complex transform chain and be flagged as colour data.
So what is the difference between “raw” and “non-colour”?
Within Blender, if you open up the default configuration, you’ll see that both “Raw” and “Non-Color” are in fact both isdata: true definitions. As such, they are identical, and more fuel for when I say that the default configuration is still a dumpster fire. Brecht has done some good work recently cleaning it up, but it has a long ways to go. Here are the stanzas in question, with the relevant sections isolated for clarity:
- !<ColorSpace>
name: Non-Color
[...]
bitdepth: 32f
isdata: true
allocation: uniform
allocationvars: [0, 1]
- !<ColorSpace>
name: Raw
[...]
bitdepth: 32f
isdata: true
allocation: uniform
allocationvars: [0, 1]
See? Both are identical!
In this case, the patchwork nature of the configuration has led to duplication. Sometimes this can be helpful for clarity. In this case, with the newer and more appropriate colour transform work being exposed, it has become somewhat less clear and more confusing.
These new options are the result of Blender's keeping up to date. One example thereof is ACES, which, as Wikipedia says
supports both high dynamic range (HDR) and wide color gamut (WCG).
So it's used i.a. for HDR images that are quite common now.
Non-color means the same it did.
Acording to the manual, filmic log is used when you want to export the image to a color grading program. It might also be useful when color grading on blender. I did notice that it enhances the colors dramatically, which would be useful when trying to seperate them. you want to use sRGB for diffuse image textures, and non-Color for bump maps. The other uses are mainly used in the scene color space.
