Y*683 != luminous flux ?

[frankkjensen]

Hi,

When I calculate Y with using colour.sd_to_XYZ(sd), and multiply it with the luminous coefficient = 683 lm/W, I do not get the same as when using colour.luminous_flux(sd).
I have tried a few different things (see the attached file) like comparing the spectrometer read out and calculating XYZ in Excel, and it seems like I always get different XYZ values than colour.sd_to_XYZ(sd).
What am I doing wrong?

Also colour.SD_TO_XYZ_METHODS have 'ASTM E308' and 'astm2015' both refer to <function sd_to_XYZ_ASTME308 at 0x000002C049D13910>
Is this on purpose?

I am using colour-science 0.4.1.
I am completely new to colour-science (and also fairly new to python), so please bear with me :-)

-Frank
Y_vs_luminous_flux.zip

[tjdcs]

Try k=6.83

This is an issue with v0.4.1 the sd_to_XYZ definition assumes that the sd is a reflectance factor function in the range of 0-100. So it normalizes by /100

0.4.2 will work as expected

[KelSolaar]

k=1 uses 1 as normalisation factor where k=None will compute a k factor as function of the illuminant so that an hypothetical object with 100% reflectance will have a luminance Y of 100.

[frankkjensen]

Thanks.
I do think it is a bit dangerous/misleading behavior. I know that it is written in the API documentation, but to be honest I didn't actually understand it until you wrote the above answer. In the documentation it says "For reflecting or transmitting object colours, k is chosen so that Y=100 for objects...". Coming from a world of lights and not reflecting/transmitting objects, I was thinking "I don't need to chose a k, I just need the basic spectrum to XYZ calculation". But if I leave k unspecified, it will chose a k (!= 1) for me, assuming that I am looking at reflecting/transmitting spectra and not just the basic stimuli of the eye. In my opinion the function should be as basic a possible, when not specifying "extra features". But I guess it depends on where you are coming from...

Anyway, thanks again! Also for the all the great work you guys are doing!

-Frank

[KelSolaar]

@frankkjensen : This is actually quite standard practice in colorimetry, if computing reflectance, transmittance or absorptance, k needs to be calculated as a function of the illuminant, thus k should not be passed as argument.

If computing irradiance, typically, either k=683 is used for absolute values or it does not matter, e.g. computing chromaticity coordinates, and any value is fine.

The signature of the definition and the docs are rather clear on that point and I’m not sure to understand the expectation that by not passing k it should equate to 1?

What use cases do you have that require k to be one and what does the values represent then?

[tjdcs]

Thanks for chiming in @KelSolaar

Also I'm going to add in that I've done extensive work using both relative and absolute colorimetry. The default behavior when k=None is a common use case for color scientists. Maybe not in the lighting world where you are trying to compute lux or something. But in that case k=683 and knowing your measurement geometry should be fine?

(also, pedantically, for absolute colorimetry k is only approximately = 683. Details here

[frankkjensen]

As I wrote, I think it depends on where you are coming from. I have never worked with colorimetry of reflective/transmissive samples using standard illuminants. I have worked with various filters, but here I have always had the absolute spectrum of a specific light source.
So I am used to simply multiplying an absolute spectrum with the CMFs, summing them up to get XYZ and multiplying with 683.
But in my simply/naive workflow substituting "multiplying an absolute spectrum with the CMFs and summing them up to get XYZ" with sd_to_XYZ without specifying k would give me the wrong absolute value.
I agree that it is written in the documentation, but here I misunderstood the wording "k is chosen so that Y=100". I was assuming that it was up to the user to "choose" k. Reading on "k must be put equal to... 683", I was thinking, yeah I know that, I will just do that myself if I need the luminous flux, making me to leave k unspecified and getting the wrong result :-)

Anyway, I know how it works now. I don't know if anyone else is as stupid as me :-)

-Frank