The purpose of this document is to illustrate the steps we followed to compute RED colourspaces primaries.
A convenient way to view an RGB colourspace gamut is to project it onto a chromaticity diagram such as the CIE 1931 Chromaticity Diagram where the primaries define the triangle encompassing the gamut.
The purpose of this document is to compare RGB colourspace models operations performance against spectral reference.
Various mathematical operations because of the nature of matrices and linear algebra are dependent on given RGB colourspace primaries. The same operations performed in different RGB colourspaces will yield different tristimulus values once converted back to CIE XYZ colourspace. For example multiplication, division and power operations are RGB colourspace primaries dependent while addition and subtraction are not.
The rgb_colourspace_primaries_dependency definition below demonstrates this behaviour: Two colours are selected from the colour rendition chart, they are then used as operands for different operations happening respectively in sRGB and Rec. 2020 colourspaces. The two resulting colours are then converted back to CIE XYZ colourspace and compared.
Note: A companion spreadsheet is available at the following url: http://goo.gl/akrH5m
As we are increasingly using wide gamut colourspaces (ACES RGB, Rec. 2020, ProPhoto RGB) in the VFX industry, the need for better colour analysis tools is more important than ever. Today, nothing prevents an artist to generate or pick colours outside a given volume.
We think that people working with DCC applications from Autodesk, Adobe and The Foundry need better tools to work with colour. This is especially true when we tend to work in scene referred lighting with floating point values.
We are using the ACES RGB Sony F35 still life image from this directory for our manipulation:
More images are available there: https://www.dropbox.com/sh/bwfrqgyt20gz4dp/XShJffwvXR
This still life image exhibits a lot of colours that are very hard to reproduce and is a great example for the purpose of this document.
We show here an implementation of Smits (1999) reflectance recovery method.
The spectral power distributions figures compare both the original spectral power distribution (red function) and the recovered one (green function).
The first colour patches pairs display the current original colour and its computed value with the recovered spectral power distribution and the same illuminant.
Note: There is a slight mismatch between the original colour and its computed value with the recovered spectral power distribution. We are unable yet to say if it's the result of an implementation error or something else. The perceptual difference is low and should not be an issue to judge the overall efficiency of the method.
The following colour patches pairs compare the colour as it should be if computed using the original spectral power distribution and the current illuminant with the recovered spectral power distribution and the same illuminant.
If you are interested at taking a look at the relative spectral power distribution of the illuminants in use, you can consult the following IPython Notebook.
It has pretty much always been assumed by a lot of people, including myself, that rendering engines are colourspaces agnostic, and whatever your primaries are, it should not make any differences.
An interesting thread with some VFX industry veterans about the Academy Color Encoding System has been ignited by Steve Agland.
He was describing issues while rendering in ACES RGB colourspace where the rendering equation could generate some very saturated colours, colour clipping and loss of details. Since we have started this notebook, Steve has written a post illustrating those issues, I suggest that you take a look at his notebook.
As we were discussing, Zap 'Master' Anderson pointed that he was assuming primaries wouldn't matter but that it was wrong.
The RGB basis vectors typically become non-orthogonal when transformed to XYZ, and definitely so in this case. Thus there should be no surprise that component-wise multiply does not yield a proper transform between two non-orthogonal spaces.
Installing the whole development toolchain for Colour roughly means deploying:
- Python 2.7 and Python 3.5
- Apache 2.2
- ... and too many things I just don't remember!
I decided to see how I could make that setup a bit more portable and easier to deploy.
The following guide assume that you have that you have PyCharm installed and are using macOs, although it should pretty much be platform agnostic.