Light intensities and matching Cycles

Use this forum for general user support and related questions.
Forum rules
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
Post Reply
chafouin
Posts: 120
Joined: Wed Jan 24, 2018 9:35 pm
Location: Los Angeles

Light intensities and matching Cycles

Post by chafouin »

Hey everyone,

I have been studying light units, intensities and such in order to provide a tutorial for artists. I also want to convert my LightPack to LuxCore and I'm trying to correctly match lighting intensities.

I am a bit confused by the default 17 lm/W luminous efficacy in BlendLuxCore.
I was wondering if it was a typo, as the only information I could find about white light luminous efficacy was from a comment in Cycles IES code:

Code: Select all

//The D65 standard illuminant has a Luminous efficacy of 177.83
or in LuxCore:

Code: Select all

// Scale should be set to 179.0: the value of 179 lm/w is the standard luminous
// efficacy of equal energy white light that is defined and used by Radiance. It
// can be used here to produce the same output of Radiance.
// More information here: http://www.radiance-online.org/pipermail/radiance-general/2006-April/003616.html
From tests I did comparing Cycles with LuxCore, I found that:

- Cycles and Lux lights match each other (except spotlights) with identical Power, and Efficacy and Gain of 1.

- Without tonemapper, LuxCore Sun is approximatively a Cycles sun light with a Strength of 90 000. 90 000 is pretty close to the Sun illuminance of 98 000 lux, so this would somewhat validate that LuxCore outputs absolute irradiance in Lux.

- Cycles Sun unit is in Watts/m2 (according to Brecht), not lux (lumen/m2), so Cycles Sun should be set around 1050 (according to Wikipedia). Which means that if you want to match local lights between Cycles and LuxCore, you need to use an efficacy of 90 000/1050 = 85,7 lm/W. Which isn't 179 lm/W, but at least not as far as 17 lm/W.
Johnson Martin did some interesting math at some point to find out the Sun strength in Cycles should be set to 441 W/m2, which would give 204,1 lm/W.
Unfortunately his webpage isn't enable anymore. https://www.blendernation.com/2017/06/1 ... ss-cycles/

- Could it be that the 17 lm/W is a value taken from Wikipedia about Lighting Efficiency (or Overall Luminous Efficacy), which takes in account the luminous efficacy of radiation and the wall-plug efficacy? https://en.wikipedia.org/wiki/Luminous_ ... efficiency
If so, isn't it incorrect, as there is no notion of electrical consumption in CGI and Power should only be about luminous efficacy of radiation?

- I read the code Dade shared about the Power and Efficacy being divided by the color.Y value. viewtopic.php?t=942

Code: Select all

emittedFactor = gain * color * (power * efficency / color.Y());
The code when using Gain only (setting Power and Efficacy to 0):

Code: Select all

emittedFactor = gain * color;
I am a bit confused because I would assume that it should be the Gain that would have to be divided by color.Y.
In fact, Power is radiant flux which is not weighted by the luminous efficiency function. So it is expected that a green light feels brighter when using Power. If you divide the (Power*Efficiency) by color.Y, doesn't it mean that you are weighting it by the color luminance?

- That being said, I did some tests comparing using Gain instead of Power and Efficacy, and couldn't notice any difference depending on the colors. The difference are that the Spotlights are very slightly darker, and area lights are much darker. Point lights stay identical.
Image
Image

Is the color luminance weighting not working?

I hope someone can shed a light on these questions :)
Thanks!
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Light intensities and matching Cycles

Post by Dade »

Looking at the code, I assume I put the color.Y() there to normalize the color when using power and efficiency: (1, 1, 1) and (0.5, 0.5, 0.5) will produce exactly the same result. It makes sense, it is there to avoid an "hidden" form of gain control: you want to have the intensity of the light source controlled only by the power and efficiency.

Note: there is another factor for mesh light sources, the mesh area. The total emitted light is divided by the mesh area so if you scale the mesh, the total emitted light is constant. From your description, I have the feeling Cycles doesn't do that.

Old Lux had only color, power and efficiency while SLG had only gain and color control. I had to support both, for various reasons, so the result is what you see.

However they are supposed to be used separately:

- or you use color, power and efficiency (simulation way);
- or you use gain and color ("artistic" way);
Support LuxCoreRender project with salts and bounties
chafouin
Posts: 120
Joined: Wed Jan 24, 2018 9:35 pm
Location: Los Angeles

Re: Light intensities and matching Cycles

Post by chafouin »

Thanks for the quick reply.

I understand now why you used the color.Y() divide. However, it doesn't work as you described it: when using power and efficiency, a light with a color of (0.5,0.5,0.5) looks darker than a light with (1,1,1).

Also, if color.Y() corresponds to the XYZ color coordinates, then it should compensate for loss of brightness depending on the wavelength (color) of the light, shouldn't it?

red.Y = 21.26
green.Y = 71.52
blue.Y = 7.22

Code: Select all

emittedFactor = gain * color * (power * efficency / color.Y());
With a light of 1 W, 1 lm/W and Gain set to 1:

redEmittedFactor = 1 * red * (1 * 1 / 21.26) = 0,047 * red
greenEmittedFactor = 1 * green * (1 * 1 / 71.52) = 0.014 * green
blueEmittedFactor = 1 * blue * (1 * 1 / 7.22) = 0,139 * blue

But if you look at my previous screenshot, pointlights look identical when using Power and Efficacy to when using only Gain of 1.

Is color.Y() not the Y coordinate of the color, or is my reasoning completely wrong?

Another detail but I might be splitting hairs here: in the code you are using the variable named "efficency", and not efficacy.

And you are right about the area lights in Cycles, their units is in Watts, and not in Watts/m2, which makes them look darker as the light grows bigger. In LuxCore they keep the same brightness, which means that the unit is in Watts/m2, it would be nice to mention it in the tooltip.

Thanks a lot!
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Light intensities and matching Cycles

Post by Dade »

chafouin wrote: Mon Dec 09, 2019 1:16 am Also, if color.Y() corresponds to the XYZ color coordinates, then it should compensate for loss of brightness depending on the wavelength (color) of the light, shouldn't it?
Yes, ".Y()" is the color luminance (like in XYZ color space): https://github.com/LuxCoreRender/LuxCor ... lor.h#L285

And, yes it should compensate for loss of brightness depending on the wavelength (i.e. the color "normalization" I was talking in my previous post).
chafouin wrote: Mon Dec 09, 2019 1:16 am red.Y = 21.26
green.Y = 71.52
blue.Y = 7.22
Nope, it is a scale factor between [0, 1] so your values are multiplied by 100 (see the linked code above):

Code: Select all

red.Y = 0.2126...
green.Y = 0.7152...
blue.Y = 0.0722...
chafouin wrote: Mon Dec 09, 2019 1:16 am But if you look at my previous screenshot, pointlights look identical when using Power and Efficacy to when using only Gain of 1.
Yes, it is the expected behavior and once you factor the missing "x100" factor, it should make sense.
Support LuxCoreRender project with salts and bounties
chafouin
Posts: 120
Joined: Wed Jan 24, 2018 9:35 pm
Location: Los Angeles

Re: Light intensities and matching Cycles

Post by chafouin »

The 100 factor doesn't change the brightness ratio between colored lights.
In my previous render, the lights using Gain were darker because of the mesh area light size, so let's ignore them.

Image

Top is using Gain, bottom is using Power. Renders using Power are slightly brighter because I couldn't find what mesh light size to use to get identical brightness (using 0.5m here).

I don't see where the blue light gets a 10 times intensity boost to match the green light brightness.
If that intensity boost was even happening, it should not happen when using Power, but when using Gain.

Another render showing that changing the luminance of the color isn't compensated.
Image
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Light intensities and matching Cycles

Post by Dade »

chafouin wrote: Mon Dec 09, 2019 11:49 am Top is using Gain, bottom is using Power. Renders using Power are slightly brighter because I couldn't find what mesh light size to use to get identical brightness (using 0.5m here).
1m^2 so the division by area becomes a division by 1
chafouin wrote: Mon Dec 09, 2019 11:49 am I don't see where the blue light gets a 10 times intensity boost to match the green light brightness.
If color = (0, 0, 1) than color.Y() = 0.072169 and emittedFactor = (0, 0, 1) / 0.072169 = (0, 0, 13.85636492122657)

If color = (0, 1, 0) than color.Y() = 0.715160f and emittedFactor = (0, 1, 0) / 0.715160 = (0, 1.398288494882264, 0)

The green light should be brighter than the blue one, doesn't it match your test results ? I think it does:

Image

The green version is brighter than the blue one.
Support LuxCoreRender project with salts and bounties
chafouin
Posts: 120
Joined: Wed Jan 24, 2018 9:35 pm
Location: Los Angeles

Re: Light intensities and matching Cycles

Post by chafouin »

Dade wrote: Mon Dec 09, 2019 1:44 pm 1m^2 so the division by area becomes a division by 1
Well... That was my first try, and that didn't work :)
Dade wrote: Mon Dec 09, 2019 1:44 pm If color = (0, 0, 1) than color.Y() = 0.072169 and emittedFactor = (0, 0, 1) / 0.072169
Of course I can see it it the math, that's what I've been trying to explain. I mean visually.
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Light intensities and matching Cycles

Post by Dade »

chafouin wrote: Mon Dec 09, 2019 1:49 pm Of course I can see it it the math, that's what I've been trying to explain. I mean visually.
Sorry, I was writing the answer and the incomplete post got posted by accident.
Support LuxCoreRender project with salts and bounties
chafouin
Posts: 120
Joined: Wed Jan 24, 2018 9:35 pm
Location: Los Angeles

Re: Light intensities and matching Cycles

Post by chafouin »

No problem, my bad!

- The green light is brigther than the blue light because of the human eye sensitivity, it's default behavior.
- Your calculation just proved that the blue emitted factor should be 13.856, almost 10 times brighter than the green emitted factor of 1.398 to compensate for the human eye sensitivity. This is not the case here. The blue looks 10 times darker than green anyway.
- You have two pieces of code, one using color.Y() division, one that doesn't, and both render identically. There is obviously something wrong in there, or am I crazy? :D
User avatar
Dade
Developer
Developer
Posts: 5672
Joined: Mon Dec 04, 2017 8:36 pm
Location: Italy

Re: Light intensities and matching Cycles

Post by Dade »

chafouin wrote: Mon Dec 09, 2019 1:55 pm - You have two pieces of code, one using color.Y() division, one that doesn't, and both render identically. There is obviously something wrong in there, or am I crazy? :D
It doesn't make very much sense, can you post your test scene so I can check if there is something going wrong ?
Support LuxCoreRender project with salts and bounties
Post Reply