Why does the spectral conversion in the automatic colour conversion graph uses different defaults than the low-level API?

[ema2159]

Description

When using the color graph conversion, if one of the intermediate steps passes through the sd_to_XYZ conversion, the results will be different than when using the function directly, when using default arguments.

This happens because in this line, the default illuminant is set to "D65" whereas here and here, it is set to "E".

This inconsistency leads to confusion.

I am not sure if it is a design decision, but in my opinion, the defaults of the conversions along the path should remain the same unless modified.

[KelSolaar]

Hi @ema2159,

Thank you, this is a great question and this is by design, the Automatic Conversion Graph is mostly used to help people figuring out complex colour transformations. We (I) chose some defaults that would make things easier for novice user with the objective of delivering for the sRGB colourspace. This is for example the case for all the CAMs that implement defaults for sRGB viewing conditions. A common use case in that context would be the conversion of a colour checker reflectances to sRGB, this requires using D65 illuminant during the spectral integration, hence the D65 default.

On the contrary, experts because they know what they are doing tend to want the integration to work in the general case first, i.e. irradiance, hence E and then pass an illuminant when dealing with reflectance, absorptance, etc...

I agree with you that it is confusing, I'm not sure that we should change the behaviour though but I do agree that we should make that clear for users. Maybe issuing a warning would help here.

Cheers,

Thomas

[ema2159]

Greetings @KelSolaar,

Thank you for your quick reply and explanation. Indeed. I was using the color conversion methods to get the color coordinates of an illuminant from its spectral distribution. I was getting different results than a colleague, who was computing it manually. Upon further inspection, I figured out the error, but it took a while and it would've gone unnoticed had I not compared the results with my colleague.

It's important to mention that it is actually pointed out in the documentation, though it is not as explicit as it could be, so I missed it even though I read it several times.

Issuing a warning could be an option, though not sure if enabling some level of verbosity when using the method would be required to display it. I would personally stick to the defaults of each function when possible and require the illuminant to be specified when the underlying function called in the graph needs it, and if not, throw an error, propagating the illuminant to the nodes in the graph only if it was specified at some previous point in the conversion. This is mainly for the sake of consistency since one would expect the following function calls to be equivalent:

# 1:
xyY_coords = colour.convert(
    color_sd,
    "Spectral Distribution",
    "CIE xyY",
)
# 2:
xyY_coords = XYZ_to_xyY(sd_to_XYZ(color_sd))

Keeping it as it is, makes the API of the library inconsistent, which may lead to confusion and errors such as mine.

Regards,

Emmanuel

[KelSolaar]

This is kind of growing on me, so I will probably change that to use E as the low-level API. Simple fact that you tripped over is a good argument anyway for changing it.

[tjdcs]

Apologies, I did not mean to mark discarded!