Luminous efficacy

[will-ca]

Filament uses 683 in some places to convert from physical luminosity (watts) to perceptual luminous flux (lumens). 683lm/W is the peak luminous efficacy of monochromatic 555nm green light, and sometimes used as a simplification.

filament/docs/Filament.md.html

Lines 1246 to 1260 in 74b09c7

	**Notes about the radiant power unit**
	Even though commercially available light bulbs often display their brightness in lumens on the packaging, it is common to refer to the brightness of a light bulb by using its required energy in watts. The number of watts only indicates how much energy a bulb uses, not how bright it is. It is even more important to understand this difference now that more energy efficient bulbs are readily available (halogens, LEDs, etc.).
	However, since artists might be accustomed to gauging a light's brightness by its power, we should allow users to use the power unit to define the brightness of a light. The conversion is presented in equation $\ref{radiantPowerToLuminousPower}$.
	$$\begin{equation}\label{radiantPowerToLuminousPower}
	\Phi = \Phi_e \eta
	\end{equation}$$
	In equation $\ref{radiantPowerToLuminousPower}$, $\eta$ is the luminous efficacy of the light, expressed in lumens per watt. Knowing that the [maximum possible luminous efficacy](http://en.wikipedia.org/wiki/Luminous_efficacy) is 683 $\frac{lm}{W}$ we can also use luminous efficiency $V$ (also called luminous coefficient), as shown in equation $\ref{radiantPowerLuminousEfficiency}$.
	$$\begin{equation}\label{radiantPowerLuminousEfficiency}
	\Phi = \Phi_e 683 \times V
	\end{equation}$$

filament/filament/include/filament/LightManager.h

Lines 814 to 816 in 74b09c7

	void setIntensity(Instance i, float watts, float efficiency) noexcept {
	setIntensity(i, watts * 683.0f * efficiency);
	}

https://github.com/search?q=repo%3Agoogle%2Ffilament+683+NOT+language%3ACSV+NOT+language%3ASVG+NOT+language%3A%22Wavefront+Object%22+NOT+language%3AText&type=code

FYI There is an open discussion about this constant in the Blender and Khronos GLTF repositories. Apparently the correct number is 177.83, not 683, and can be calculated using the spectral distribution of the D65 standard illuminant from Rec.709 specified for GLTF.

KhronosGroup/glTF-Blender-IO#2493 (comment)

KhronosGroup/glTF#2473 (comment)

[romainguy]

Thanks @will-ca. This was something I've always wanted to revisit because of exactly what you said (683 works for monochromatic green light). That said, is 177.83 correct? Shouldn't the value be computed from the intended light color (when possible)? (which of course would be a problem since I imagine this would require spectral upsampling and there's no single answer to that in many cases)

[will-ca]

That said, is 177.83 correct? Shouldn't the value be computed from the intended light color (when possible)?

I'd raised this as an aside:

But there are also other elisions where the intensity in general does not account for color, for example the RGB channels are not normalized to the intensity in any render engine that I'm aware of.

@UX3D-haertl had this to say:

It was decided that the conversion should use a fixed factor (instead of being related to the light color).
But the reference color for conversion should be RBG (1,1,1) which sRGB defines as D65 instead of a specific green wavelength.

KhronosGroup/glTF-Blender-IO#2493 (comment)

Personally I think some level of simplification is inevitable. It appears the GLTF people have decided the appropriate amount deals with intensity only relative to the white point.

I'd monitor or ask in the linked issues for more information. I haven't personally examined the methodology behind 177.83. From KhronosGroup/glTF-Blender-IO#2493 (comment), it sounds like maybe the decision is only being made in these last couple weeks.

Then there is also the distinction that this is about GLTF, so render engines might use other models internally while still being physically accurate.

[romainguy]

Thanks. I'm not against simplifications but a 6x radio between a white and a green light is hardly a rounding error 😅 I have light meters somewhere, I should try to measure lights as the same wattage but with different color temperatures to see if it's worth worrying about it.

[will-ca]

Heh. Personally I just want any standard coefficient so implementations don't have to keep reinventing it.

I find the colour aspect isn't so bad if you think of the intensity as the "bulb", and the color as separate a tinted filter in front of it. Which I guess is actually how strongly colored lights would be created, at least before LEDs. Though not colour temperature, where the dominant factor for (electrical) wattage efficiency will probably be Planck's law...

Based on the other discussions I think a significant portion of the 6X difference from 683 to 177 is due to UV and near-IR.