Hello, I have differences between 19.5 and 20 with the color temperature of the lights. If you put a light at 10,000 kelvin, the resulting blue is different between the two versions. I have the same OCIO set on both.
Could someone check it or tell me what I might be doing wrong?
Thanks in advance

Indeed, they are quite different. Seems broken in 20.0 as the color stops changing above around 10000K and gets brighter and brighter as temperature approaches 500K with Karma CPU.

Would you log a bug?

Hi. Actually this is intentional change in 20.0. Previously it was using internal UT_Color implementation but now uses a more standard normalized blackbody implementation that matches other 3rd party renderers (namely PRMan), is OCIO colour managed, and maximum temperature clamped to match usd spec.

dlee
and maximum temperature clamped to match usd spec.

Really, the max temp in the spec is 10k? That's not even blue yet. 27k is a more reasonable upper bound, although there are physical black bodies that are in the millions of Kelvin in existence, but X- and gamma rays are probably not in the cards for Karma.

The behavior at the red end is suspect. I wouldn't expect the color to blow out so much. This says the lower bound should be 1000
https://openusd.org/release/api/class_usd_lux_light_a_p_i.html#ad990b3360a3c172c5340ce4e7af463a6 [openusd.org]
Where do you find a reference implementation of the blackbody spectra?

dlee
OCIO colour managed

How? does it require an XYZ to RGB transform be defined in the config? What if you have a 1.0 config that doesn't have one? Is it using hardcoded keywords to look for ACEScg or sRGB in the scene_linear role? Does the white point take into account the white point of the color space? ie ACEScg at D60 vs sRGB at D65?

Hello, forgive me for insisting, the problem with the lights is related to hue. If you use an HDR image for light there is a noticeable change, without touching the color temperature. There is no continuity between the lights of 19.5 and 20 hue

jsmack
Where do you find a reference implementation of the blackbody spectra?

It's the same Planckian Locus approximation that MaterialX uses, though I think we ended up going with the same implementation as MDL's because MaterialX's has much higher lower bound temperature.

jsmack
How? does it require an XYZ to RGB transform be defined in the config? What if you have a 1.0 config that doesn't have one? Is it using hardcoded keywords to look for ACEScg or sRGB in the scene_linear role? Does the white point take into account the white point of the color space? ie ACEScg at D60 vs sRGB at D65?

No need to define XYZ to RGB in OCIO - we internally transform into rec709 space first (not gamut clamped) then convert to whichever role defined as scene linear. No special consideration for whitepoints needed.

atv3d
Hello, forgive me for insisting, the problem with the lights is related to hue. If you use an HDR image for light there is a noticeable change, without touching the color temperature. There is no continuity between the lights of 19.5 and 20 hue

Ah, is this for XPU? The fact that light color is not being multiplied color temperature output was a bug which was addressed in 20.0.