About the default normalised primary matrix (NPM) when both primaries/whitepoint and the NPM are published.

[KelSolaar]

This is somehow a continuation of #697 and was brought again by the DaVinci Wide Gamut whitepaper that defines both the NPM (and its inverse) and the primaries/whitepoint used to derive it.

To give more context, I will simply paste the header of our colour.RGB_Colourspace class:

    Colour science literature related to *RGB* colourspaces and encodings
    defines their dataset using different degree of precision or rounding.
    While instances where a whitepoint is being defined with a value
    different than its canonical agreed one are rare, it is however very
    common to have normalised primary matrices rounded at different
    decimals. This can yield large discrepancies in computations.

    Such an occurrence is the *V-Gamut* colourspace white paper, that defines
    the *V-Gamut* to *ITU-R BT.709* conversion matrix as follows::

        [[ 1.806576 -0.695697 -0.110879]
         [-0.170090  1.305955 -0.135865]
         [-0.025206 -0.154468  1.179674]]

    Computing this matrix using *ITU-R BT.709* colourspace derived normalised
    primary matrix yields::

        [[ 1.8065736 -0.6956981 -0.1108786]
         [-0.1700890  1.3059548 -0.1358648]
         [-0.0252057 -0.1544678  1.1796737]]

    The latter matrix is almost equals with the former, however performing the
    same computation using *IEC 61966-2-1:1999* *sRGB* colourspace normalised
    primary matrix introduces severe disparities::

        [[ 1.8063853 -0.6956147 -0.1109453]
         [-0.1699311  1.3058387 -0.1358616]
         [-0.0251630 -0.1544899  1.1797117]]

    In order to provide support for both literature defined dataset and
    accurate computations enabling transformations without loss of precision,
    the :class:`colour.RGB_Colourspace` class provides two sets of
    transformation matrices:

        -   Instantiation transformation matrices
        -   Derived transformation matrices

    Upon instantiation, the :class:`colour.RGB_Colourspace` class stores the
    given ``matrix_RGB_to_XYZ`` and ``matrix_XYZ_to_RGB`` arguments and also
    computes their derived counterpart using the ``primaries`` and
    ``whitepoint`` arguments.

    Whether the initialisation or derived matrices are used in subsequent
    computations is dependent on the
    :attr:`colour.RGB_Colourspace.use_derived_matrix_RGB_to_XYZ` and
    :attr:`colour.RGB_Colourspace.use_derived_matrix_XYZ_to_RGB` attribute
    values.

To make a muddy situation muddier and for even more context, a mini-thread occurred on Twitter where @rodbogart and I disagreed.
While, I agree with Rod that, fundamentally, the primaries and whitepoint are unambiguous, a Google Search informs us that the problem is not that trivial. Indeed, people implementing colourspace transformations in actual software will, in the majority, tend to use readily available matrices and not re-derive them or have them derived at runtime. The simple fact that @nick-shaw and I are talking about it again today, highlights the conundrum!

With that in mind, the current default is to use the given normalised primary matrix (and/or its inverse) over the derived one at instantiation time. We were discussing with @nick-shaw if there is not a case for actually selecting the derived matrices over the given ones for some cherry-picked RGB colourspaces, for example, DaVinci WG RGB.

[nick-shaw]

We were discussing with @nick-shaw if there is not a case for actually selecting the derived matrices over the given ones for some cherry-picked RGB colourspaces, for example, DaVinci WG RGB.

I was not suggesting there was any particular reason to do this with DaVinci WG. It was only that it was the space I was reviewing when the thought occurred to me.