# Blender 2.8 image texture node and color space

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)?

• I've run a few quick tests by setting up two Image Texture nodes fed by the same image and passing through a Vector Subtract node. By varying each of the Image Texture Color Space settings this can be used to compare the different modes. 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. – Rich Sedman Jul 24 at 6:10
• You can find some informations in the (updated) 2.80 manual about Color Management – Bithur Jul 24 at 7:53
• @RichSedman I just have noticed when using .exr environment texture it automatically uses Linear type color space, Raw has same as well as non color while sRGB is a lot lot darker and others are making colors appear a lot different or would be mostly black, Using Linear ACES has some cool effect on env, I don't know what maybe oversaturation it is hard to tell because env was whole 'gray' vibe, it is some old industrial hall. – Black Cloud Jul 26 at 19:24
• It’s not “oversaturation”, but a broken transform. That ACES transform isn’t ACES, and needs to be removed. It’s confusing garbage at this point. The TL;DR is use the select box to inform the software how your buffer / file encoding is encoded. If it isn’t encoded as per the selection, don’t use it. – troy_s Jul 27 at 16:37

In short:

• Use "non-color" for inputs that are supposed to be spatial (3D) vectors or simple factor values.
• Use one of the others (depending on your needs) for what is effectively a color.

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.

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.

• Thanks for the detailed answer - that's a really good explanation of the different settings and just what I was looking for. – Rich Sedman Jul 30 at 6:47

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.

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.

1. Both colour and non-colour data could cover arbitrary ranges of numerical code values.
2. Both colour and non-colour data could be nonlinearly or linearly encoded

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.

• Ok, but then when do we use other types, I thought maybe we should use xyz color space, it makes sense, at least to me. Mind sharing thread that you think is duplicate? – Black Cloud Jul 9 at 11:53
• The colour space describes the encoding of the image. The image isn’t likely encoded as XYZ, and frankly, I have no idea why the developers insist on cluttering up the configuration with edge-case transforms. – troy_s Jul 9 at 16:58
• Well they are trying to make it more appealing to industry standards I guess, and someone might need to use that. So we should stick to sRGB and non-color if we don't have some special snowflake image to be used? – Black Cloud Jul 9 at 22:03
• There are plenty of encodings out there that a typical person might run into. The reason XYZ prevails is simply cluelessness really. – troy_s Jul 10 at 1:02

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.