Why does a conversion using the "colour.RGB_to_RGB" definition with the same input and output colourspaces changes the input value?

[MrLixm]

Description

Hello,

I have found a weird behaviour with the colour.RGB_to_RGB() function (probably happening to others too).
When the input colorspaces and output colorspaces are similar, what should be a "no op" is actually not one and we can observe a slight difference between the source and result array.
I assume the difference is some floating point arithmetic issues but still I don't think we should get a different result ?

Should a "no-op" check be added that if input_colourspace==output_colourspace and apply_cctf_decoding==apply_cctf_encoding then just return RGB.copy() ?

Code for Reproduction

import colour
import numpy
from numpy.testing import assert_array_equal

source = numpy.array([1 / 3, 1.26, -0.213])
colorspace = colour.models.RGB_COLOURSPACES["sRGB"]
result = colour.RGB_to_RGB(
    RGB=source,
    input_colourspace=colorspace,
    output_colourspace=colorspace,
    apply_cctf_decoding=True,
    apply_cctf_encoding=True,
)
assert_array_equal(result, source)

Exception Message

AssertionError: 
Arrays are not equal

Mismatched elements: 3 / 3 (100%)
Max absolute difference: 0.00026099902984499934
Max relative difference: 0.0012253475579577435
 x: array([ 0.333331,  1.260023, -0.212739])
 y: array([ 0.333333,  1.26    , -0.213   ])

Environment Information

===============================================================================
*                                                                             *
*   Interpreter :                                                             *
*       python : 3.9.13 (tags/v3.9.13:6de2ca5, May 17 2022, 16:36:42) [MSC    *
*   v.1929 64 bit (AMD64)]                                                    *
*                                                                             *
*   colour-science.org :                                                      *
*       colour : 0.4.1                                                        *
*                                                                             *
*   Runtime :                                                                 *
*       imageio : 2.26.0                                                      *
*       numpy : 1.24.2                                                        *
*       PyOpenColorIO : 2.1.0                                                 *
*       scipy : 1.10.1                                                        *
*       OpenImageIO : 2.2.18                                                  *
*                                                                             *
===============================================================================

[KelSolaar]

Hi @MrLixm,

As crazy as it might sound, this is "by-design", some standards, e.g. IEC 61966-2-1:1999, define the RGB to XYZ and XYZ to RGB matrices rounded at 4 digits, thus it cannot roundtrip properly. There is actually a long explanation at the top of the RGB_Colourspace class: https://colour.readthedocs.io/en/develop/generated/colour.RGB_Colourspace.html#colour.RGB_Colourspace

See also #282 for some discussion around that, there might be some more in the depth of Slack.

Cheers,

Thomas

[KelSolaar]

Some more information: You can also take a look at how many Google Search hits you get from the sRGB matrices as an example to see how widespread their usage is: https://www.google.com/search?q=srgb+0.4124 (About 2,170 results), https://www.google.com/search?q=srgb+3.2406(About 1,070 results)

People tend to use them directly rather than deriving them from the primaries. So if you want to do interchange with other software, it is probably better to use the rounded matrices and for internal processing to use the derived ones. Note that in the case of sRGB, the discrepancies are "swallowed" by the conversion to 8-bit integer which is why 4 places were enough when the standard was created.

[MrLixm]

Thanks for the answer. This explains the value difference, but I'm still wondering why don't you apply a "no operation" detection. Putting sRGB aside wouldn't that make sense to avoid running calculations that are not needed because the input and output are exactly the same ?
Or is it something you consider should be handled upstream, by the developer calling the function ?

[KelSolaar]

Yes, we do not do that because: As you found out, it is actually not a no-op, because of how the colourspaces are designed, even though the intent is that it should be. It is actually very useful for us to find out where there could be design flaws. This also applies to transfer functions and we pointed out quite a few precision issues to vendors, e.g. graft point for piece-wise functions, etc…

Also, If we were to optimise for that direct case, people would get different result if they were doing RGB to XYZ and then XYX to RGB discretely. Then we would be screwed, premature optimisation is the root of all evil! :)