Hi Terje,
In all honesty, I don't know exactly either.
What I did here was simply rendering it with and without OCIO (Project settings -> Colour Settings) and save the renders to .BMP.
That's what you have seen here.
What I do understand though is that when you enable OCIO:
1) Display space = colour space the render view uses to display your render. Since >99% of the people use sRGB monitors this is logically the default.
2) Rendering space = scene linear = for as long as we have used TG we noticed that colours are being represented as numbers, usually ranging from 0...1.
These are linearized colour values and is what the renderer uses internally to perform calculations with. More on this a bit later.
3) Shader parameters = Rec709 = the colour space to which TG's renderer is 'tuned' to, so to say. Internally TG does not really care about colour spaces, it just calculates with linearized light values, regardless which colour space they are in. However, as soon as a render is complete you need to view/output it in a certain colour space and Matt chose to use the Rec709 colour space which is very similar to sRGB.
Many of the shader parameters, like in the atmosphere for example, are chosen to work nicely when viewing Rec709/sRGB.
4) 8-bit textures = the colour space the renderer assumes when reading textures from image map shaders etc. These RGB values will be linearized (as usual) and transformed to the colour rendering space.
So what's different, then? Well that's the hard part to really properly understand.
I once read somewhere that there are probably -literally- about one handful of people on this planet who fully understand colour spaces front to end and inside out.
So no shame to anyone for not not having a clue, it's hopelessly complicated.
The simplest explanation I can give you and this takes a LOT of shortcuts is the following:
1) CIE 1931 color space is the standard spectrally defined reference colour space for human vision:
https://en.wikipedia.org/wiki/CIE_1931_color_spaceSpectrally refers to colours being described as a certain wavelength or combination of wavelengths. Almost all renderers are non-spectral, instead they work with 'primaries'. Base numbers which represent pure red, green or blue.
A purely spectral renderer does not use this concept of 3 stimulus colours, but tries to describe each colour as a wavelength description.
The big however is: each colour can be spectrally defined in infinite number of ways. Mixing in a shorter wavelength can be compensated by mixing in a longer wavelength and the resulting visible colour is still the same. The number of possible mixtures is infinite.
This is tough to calculate with, hence we use sRGB etc.
So, with the exception of Manuka and Mitsuba, renderers do not perform colour calculations with spectra, instead they use colour coordinates on a colour diagram.
The CIE 1931 colour space diagram, also refered to as XYZ often, encodes all colours visible to humans and is based on spectral measurements. It's device independent.
In this diagram X and Z define the chromaticity and Y the luminance. Each colour and its brightness have a position in this 3D colour volume.
White and grey have the same chromaticity, but different luminance. Their X and Z values are the same, but they are different on the vertical Y scale.
This model is additive/linear.
2) TG also uses linearized light values internally and is the number you see next to your chosen colour.
Each colour channel has a value which all combined represent the position on the colour diagram. For TG this colour diagram is not reference XYZ, but Rec709, which is eerily similar to sRGB. For ease, let's say TG uses sRGB.
3) sRGB, after linearization can be expresssed as values in this XYZ diagram. For example:
Pure white = 255, 255, 255 = 1 in sRGB Linear.
In XYZ this is 95, 100, 109
4) ACES values (already linear) can also be expressed as XYZ.
5) Thus, sRGB -> ACES conversion is possible.
6) However...when converting a sRGB colour to XYZ and convert this XYZ value to ACES then the resulting colour is slightly different.
This is due to 2 things:
- Different primaries
- Different white-point (illumination colour)
Primaries are the coordinates in XYZ which represent the 'base' for Red, Green and Blue.
For sRGB these XYZ positions are different compared to ACES.
For sRGB:
https://en.wikipedia.org/wiki/SRGB#Specification_of_the_transformationFor ACES:
https://en.wikipedia.org/wiki/Academy_Color_Encoding_System#ACEScgAs you can see the matrices are quite different, which means that similar colours map different in XYZ.
Or, from an sRGB perspective; an sRGB colour converted to XYZ results in a different RGB in ACES.
Similar to white balance in photography, it matters which colour light has in how the observer perceives a given colour.
For sRGB this is called D50 and for ACES D60('ish...there's no consensus I believe).
In the spectral diagrams the neutral greys follow a specific curve.
For sRGB and ACES the white-points are on a slightly different position in XYZ.
This means:
Matching colours shifts the white-point.
Matching the white point (the neutrals) shifts the colours.
Concretely for rendering:
When bouncing light around the renderer calculates with linear colour values, like adding or multiplication of colour values.
The renderer doesn't care about colours. It just uses numbers and those values are eventually assigned to a colour space to give colour to your render.
Imagine we bounce around neutral light with linearized light values for sRGB being all equal. For instance: 0.1, 0.1, 0.1.
With each colour multiplication each channel gets the same proportional treatment. No color channel decreases faster/slower than the other. Saturation is not affected in this sRGB scenario.
However, in ACES this value might actually not be neutral at all. With each bounce one or two colour channels's values may decrease faster than the other, leading to relatively more saturation in one or two of the other channels.
This effect is potentially even more pronounced when rendering in true ACES. Meaning that we use ACES defined primaries for R, G and B.
At the moment TG still renders with Rec709 primaries, converts those linear in ACES, performs colour calculations in this space and the render view transforms the ACES output to sRGB.
The benefits we see are mostly from this colour space conversion in conjunction with the "view transform".
With ACES primaries (ACES-AP1 = ACEScg), which have different XYZ values compared to Rec709/sRGB primaries, the renderer will be able to describe a much much wider gamut of colours.
The downside to ACES is that it's primaries are close to the XYZ boundaries and wrongfully chosen primaries can lead to imaginary colours being created or that the colour response of the profile is too different from the equipment we use to view our work.
Switching to ACES is therefore not super-straightforward and perhaps other primaries than ACES(-AP1) might be a better option.
I hope some is a bit more clear now and I hope I haven't been totally wrong here.
