Emission units

[anderslanglands]

In the emissive section it says "emissive properties are specified in photometric units", but then doesn't say what units they're actually specified in. Assuming this means nits, this should be specified.

[portsmouth]

Agree we should be more specific about that in section 2.4 "Emission model" (which is supposed to be a discussion of how emission fits into the slab formalism, before we get to the specifics of the layer structure and parametrization).

We just say:

Each slab also has an emission distribution function (EDF), though it corresponds by default to no emission at all. Emissive properties are expressed in photometric units, since reference values are widely available. Thus the EDF is a directional luminance function Le. One can imagine the luminance emitted homogeneously from the slab interior (by some unspecified physical process).

The "thus" doesn't really follow I guess, since there are different kinds of photometric quantities/units, not just luminance/nits. Also we didn't really define what an emission distribution function is supposed to mean -- presumably mathematically it gives the photometric luminance (in nits) at the surface point, as a function of direction.

Note we do specify that the emission_luminosity parameter has units of nits, in section 3.7 "Emission" about the specific emission parametrization in the uber-shader.

But I think this needs rationalization in the earlier text.

[portsmouth]

We also say:

The emission_luminance parameter controls the luminance the emissive layer would have when emission_color is set to (1, 1, 1) and in the absence of coat and fuzz. The emission_color acts as a multiplier, thus the resulting luminance may be less than the input parameter, or even zero if the color multiplier is set to (0, 0, 0).

I'm not sure I fully understand how this translates into the process to obtain the RGB emission radiance in the renderer's color space, i.e. what do we compute inside the renderer given:

• a surface point with emission_luminance and emission_color parameters
• the assumed color space of the colors in the spec
• the working color space of the renderer

Currently e.g. in Arnold, we just take the given emission_luminance * emission_color as the RGB radiance in the working color space, but that can't be right since it should differ depending on both the renderer working color space and the color space used in the spec (ACEScg by default).

I assume the luminance specifies the Y coordinate of the XYZ tristimulus. So perhaps we then construct XYZ (how exactly?), map that to the spec color space RGB and apply the tint color (which is also in the spec color space), then map that to the working color space RGB' ?

@anderslanglands or @AdrienHerubel, do you know the details of how this should work?

[anderslanglands]

Leaving aside the colour space part of the question (see my reply on the metadata thread) for now, this is similar to the discussion we had on the UsdLux channel recently. Basically the units for light transport in an RGB renderer don’t really make any sense :) my preferred way to handle it is just to call “pure white” emission nits and multiply color tints on after that. All lights therefore are implicitly emitting the spectrum corresponding to the rendering colour space white point, normalised to 1 nit. Under this interpretation then it really is just emission_luminance * emission_color and a spectral renderer (using uplifting) would give the same result.

…

On Mon, 28 Aug 2023 at 05:47, Jamie Portsmouth ***@***.***> wrote: We also say: The emission_luminance parameter controls the luminance the emissive layer would have when emission_color is set to (1, 1, 1) and in the absence of coat and fuzz. The emission_color acts as a multiplier, thus the resulting luminance may be less than the input parameter, or even zero if the color multiplier is set to (0, 0, 0). I'm not sure I fully understand how this translates into the process to obtain the RGB emission radiance in the renderer's color space, i.e. what do we compute inside the renderer given: - a surface point with emission_luminance and emission_color parameters - the assumed color space of the colors in the spec - the working color space of the renderer Currently e.g. in Arnold, we just take the given emission_luminance * emission_color as the RGB radiance in the working color space, but that can't be right since it should differ depending on both the renderer working color space and the color space used in the spec (ACEScg by default). I assume the luminance specifies the Y coordinate of the XYZ tristimulus. So perhaps we then construct XYZ (how exactly?), map that to the spec color space RGB and apply the tint color (which is also in the spec color space), then map that to the working color space RGB' ? @anderslanglands <https://github.com/anderslanglands> or @AdrienHerubel <https://github.com/AdrienHerubel>, do you know the details of how this should work? — Reply to this email directly, view it on GitHub <#85 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOYQXOJ4G3KGLYZTJ3YAEDXXOB4BANCNFSM6AAAAAA3ZFDDKA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[portsmouth]

All lights therefore are implicitly emitting the spectrum corresponding to the
rendering colour space white point, normalised to 1 nit.

Does this mean that the emission spectrum depends on whatever the renderer working color space is then? That can be anything in principle, so it seems like that would make it (technically) undefined what the surface is emitting.

[anderslanglands]

It's definitely defined, but it's defined to be dependent on the rendering space.

[portsmouth]

So if I understand the proposed process correctly:

• assume the surface is emitting a spectrum "corresponding to the rendering colour space white point", normalized so that the total luminance is emission_luminance nits. This will correspond to some RGB1 in the renderer working color space. (What is that exactly? Maybe it just means (L, L, L) in the working color space, where L = emission_luminance, assuming the renderer radiance units are nits?).
• map the emission_color from the shader color space (ACEScg by default) to the working color space, producing RGB2.
• Multiply RGB1 * RGB2 to get the final luminance.

That sounds reasonable.. If the working RGB color spaces are different, i'm not even sure it's necessarily technically possible to ensure the photometric luminance is exactly the same (is it?). So maybe this is the best we can do.

I do think it would be beneficial to explain this in detail in the spec though.

[portsmouth]

@KelSolaar do you have any thoughts on this? My point was mostly that I am not entirely clear what the exact process should be to map the emission_luminance (in nits) and emission_color to the RGB values inside the renderer, given assumed color spaces of model and renderer. Is what we say in the spec unambiguous enough to make sense of this? (I may be overthinking the issue, but I'd like to make it as clear as it could be).

[anderslanglands]

Yes, it's just (L,L,L) * RGB2

[anderslanglands]

For the spec you could say something like "exitant radiance in an RGB renderer should be computed as emission_luminance * emission_color to make it really explicit.

I have a slightly wordier version in the doc comments of lightAPI.h here: PixarAnimationStudios/OpenUSD@f70949a

[portsmouth]

Thanks @anderslanglands! I will attempt to make a PR clarifying it, and point you to it for review.

[KelSolaar]

Can we even talk about radiance with a RGB renderer?

Everything has already been integrated by the colour matching functions and is happening in the Standard Human Observer space. All the values are weighted by its sensitivity to light so it is very much the photometric domain and not the radiometric one.

[anderslanglands]

I’ve been using “RGB luminance” as a shorthand but I’ve not found a term I like either.

…

On Fri, 23 Feb 2024 at 11:25, Thomas Mansencal ***@***.***> wrote: Can we even talk about *radiance* with a RGB renderer? Everything has already been integrated by the colour matching functions and is happening in the Standard Human Observer space. All the values are weighted by its sensitivity to light so it is very much the photometric domain and not the radiometric one. — Reply to this email directly, view it on GitHub <#85 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAOYQXMUKAG2V2AXQJXDJ2LYVDUKFAVCNFSM6AAAAAA3ZFDDKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRRHA3TANJUHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[KelSolaar]

It has the benefit of at least pushing the terminology into the photometry realm, maybe more emphasis should be made about the difference between radiometry and photometry and explain where and how the "conversion" happens.

[anderslanglands]

In the UsdLux proposal I linked above I give a brief overview of that in the "Quantities and Units" section. @portsmouth you could crib that if you like?

The other terms I've used you can see there: "integrated radiance" and "tristimulus weight"