-
The documentation for colour.convert states that:
This is my code:
I assume that this should produce the same output as when changing the last line to
However, there is a dramatic difference. This is the output for 'RGB':
This is the output for 'sRGB':
EDIT: This is my environment.
|
Beta Was this translation helpful? Give feedback.
Replies: 7 comments
-
In this instance, the In the second, the I don’t believe it makes much sense to assume that the RGB triplet in the first case has a CCTF encoding applied. |
Beta Was this translation helpful? Give feedback.
-
Thank you! You're correct. Indeed, these produce the same output:
The core issue is: I understand the docs as saying that RGB is assumed to mean sRGB by default. Thus, they should produce the same results with the same inputs IMHO. |
Beta Was this translation helpful? Give feedback.
-
It gets a little ugly at the function level, however. Assuming a particular transfer function on a particular RGB encoding is problematic, and given the RGB case is an encoding model as opposed to colourspace such as sRGB, it probably would cause more grief? |
Beta Was this translation helpful? Give feedback.
-
I'm new to the colour Python package, so I can't say much with regards to the implementation/uglyness at the function level. I can only tell you what my interpretation of the docs is. The docs say that:
My understanding of that phrase is: For colour.convert, RGB and sRGB are identical. If you want an RGB colourspace other than sRGB, you have to make that explicit. In all other cases, it will implicitly assume that sRGB is meant. And therefore, it should behave exactly as if you specified sRGB explicitly. |
Beta Was this translation helpful? Give feedback.
-
Yeah. I’d disagree. RGB is a colour encoding model, so the understanding as to what state the values are encoded can be quite different. |
Beta Was this translation helpful? Give feedback.
-
Hi @rsnitsch, Thanks! As you saw the main difference pertains to encoding/decoding in that case, we should make the documentation clearer but besides that, the default IS sRGB, whether it is encoded or not is critical obviously but it does change the fact that the illuminant is D65 and the primaries are that of BT.709/sRGB. We will amend the documentation accordingly, that being said there are hints at that in the notes:
The graph code is still considered experimental as the warning implies so if you have other issues or misunderstanding, please keep them coming! |
Beta Was this translation helpful? Give feedback.
-
The documentation has been updated: https://colour.readthedocs.io/en/develop/generated/colour.convert.html#colour.convert |
Beta Was this translation helpful? Give feedback.
In this instance, the
RGB_to_XYZ
assumes acctf_encoding
ofNone
in the first.In the second, the
sRGB_to_XYZ
assumes inversely encoded sRGB EOTF values by default.I don’t believe it makes much sense to assume that the RGB triplet in the first case has a CCTF encoding applied.