Light intensities and matching Cycles
Forum rules
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
Please upload a testscene that allows developers to reproduce the problem, and attach some images.
Re: Light intensities and matching Cycles
I'm starting to become crazy with all these comparisons and pi factors, but Power to Lumen to Candela to Candela per square meter is correct in BlendLuxCore.
There is a discrepancy comparing to Unreal at identical camera exposure, but this is not related to the new light units, and it was there before.
I don't know if you want to check the tonemapping before shipping a release candidate.
EDIT: Been reading a bit more about the camera tonemapping, and LuxCore does this:
which is coming from https://en.wikipedia.org/wiki/Film_speed.
0.65 is a factor depending on the transmittance T of the lens, the vignetting factor v(θ), and the angle θ relative to the axis of the lens.
I don't know if Unreal is doing any of that, which could explain the difference. Not sure if all apps take this factor in account.
EDIT: I looked at https://en.wikipedia.org/wiki/Exposure_value . EV=log2(LS/K), where if K = 12.5 (unit: cd s/m2 ISO), an EV of zero (e.g., an aperture of f/1 and a shutter time of 1 sec) for ISO = 100 corresponds to a luminance of 0.125 cd/m2 (0.01 cd/ft2).
So I set an area light to 0.125 cd/m2, set my camera to these exposure values, and if all goes well, I assume the area light surface should be mid-gray. I ended up with a sRGB 166 gray, which is not too far from mid-gray.
There is a discrepancy comparing to Unreal at identical camera exposure, but this is not related to the new light units, and it was there before.
I don't know if you want to check the tonemapping before shipping a release candidate.
EDIT: Been reading a bit more about the camera tonemapping, and LuxCore does this:
Code: Select all
exposure / (fstop * fstop) * sensitivity * .65f / 10.f * powf(118.f / 255.f, gamma)
0.65 is a factor depending on the transmittance T of the lens, the vignetting factor v(θ), and the angle θ relative to the axis of the lens.
I don't know if Unreal is doing any of that, which could explain the difference. Not sure if all apps take this factor in account.
EDIT: I looked at https://en.wikipedia.org/wiki/Exposure_value . EV=log2(LS/K), where if K = 12.5 (unit: cd s/m2 ISO), an EV of zero (e.g., an aperture of f/1 and a shutter time of 1 sec) for ISO = 100 corresponds to a luminance of 0.125 cd/m2 (0.01 cd/ft2).
So I set an area light to 0.125 cd/m2, set my camera to these exposure values, and if all goes well, I assume the area light surface should be mid-gray. I ended up with a sRGB 166 gray, which is not too far from mid-gray.
Last edited by chafouin on Wed Mar 04, 2020 4:53 am, edited 1 time in total.
-
- Posts: 234
- Joined: Thu Jan 18, 2018 6:02 pm
Re: Light intensities and matching Cycles
Hi,
just a little question: how do you read light values from the rendering results?
I mean how do you get the numbers? I needed some professional (means expensive) software for that task and I'm looking for workaround for this issue.
From my understanding (at least) the *.exr results should show direct luminance values.
All the tonemapping etc shouldn't influence this values at all. It "just" the interpretation of those values!
Is that right?
BR.
just a little question: how do you read light values from the rendering results?
I mean how do you get the numbers? I needed some professional (means expensive) software for that task and I'm looking for workaround for this issue.
From my understanding (at least) the *.exr results should show direct luminance values.
All the tonemapping etc shouldn't influence this values at all. It "just" the interpretation of those values!
Is that right?
BR.
OS - Windows 7 X64
CPU - Intel CORE i7
GPU1 - Variants of notebook card from nVidia
GPU2 - Variants of notebook onboard card from Intel
Lux - Latest possible relaease
CPU - Intel CORE i7
GPU1 - Variants of notebook card from nVidia
GPU2 - Variants of notebook onboard card from Intel
Lux - Latest possible relaease
Re: Light intensities and matching Cycles
You are correct. This is in cd/m2 so if you set the tonemapper off and disable color management (show Raw values), the value you enter in your area light in Candela per Square meter (or artistic gain in LuxCore) will be the exact output value: 0.125 cd/m2 = RGB 32, 0.5 cd/m2 = RGB 128.lighting_freak wrote: ↑Tue Mar 03, 2020 1:25 pm From my understanding (at least) the *.exr results should show direct luminance values.
The linear and the camera exposure tonemapping are simple scale of these values. But I learned something about Exposure Value. Since it's a logarithmic scale I always thought EV 0 whould just be a scale of 2^0 = 1, and should not do anything to the image. And I was wrong as I didn't take the q factor or the K reflected-light meter calibration constant.
EDIT: Unreal uses a different formula for exposure, with a 1.2 factor:
https://docs.unrealengine.com/en-US/Eng ... index.html
-
- Posts: 13
- Joined: Wed Feb 26, 2020 1:35 am
Re: Light intensities and matching Cycles
Pretty confident they ain't. I perused their exposure documentation and some cursory looks into the repo and there seemed to just be the EV math, nothing regarding film transmittance or light meter calibration constants.chafouin wrote: ↑Mon Mar 02, 2020 9:13 pmwhich is coming from https://en.wikipedia.org/wiki/Film_speed.Code: Select all
exposure / (fstop * fstop) * sensitivity * .65f / 10.f * powf(118.f / 255.f, gamma)
0.65 is a factor depending on the transmittance T of the lens, the vignetting factor v(θ), and the angle θ relative to the axis of the lens.
I don't know if Unreal is doing any of that
The formula used to compute the camera exposure scale is:
Exposure = 1 / (1.2 * 2^EV100)
With:
EV100 = log2( N²/t * 100/S )
The Exposure here defines the relationship between the scene surface luminance (L in cd/m²) and pixel brightness (B) before the tonemapper and exposure compensation are applied:
B = Exposure * L
Re: Light intensities and matching Cycles
Found what the 1.2 is:
So they are actually doing the same. However... reading the 20 pages of that thread, it looks like Unreal may not be the most trustworthy...
https://forums.unrealengine.com/develop ... al-lights/
Code: Select all
// Compute the maximum luminance possible with H_sbs sensitivity
// maxLum = 78 / ( S * q ) * N^2 / t
// = 78 / ( S * q ) * 2^ EV_100
// = 78 / (100 * 0.65) * 2^ EV_100
// = 1.2 * 2^ EV
https://forums.unrealengine.com/develop ... al-lights/
-
- Posts: 234
- Joined: Thu Jan 18, 2018 6:02 pm
Re: Light intensities and matching Cycles
Hello,
Does the exr format contain a channel to save directly the absolute luminance values? Can we read that channel somehow?
And one more question: the mesh light units aren't touched, do they? In my particular case I'm using this mesh light to rebuild LEDs down to their chip... this chip mesh is my light source and from LED datasheet I know the amount of lumens that are emitted by the chip but not is luminance... for me it would be helpful to keep the lumen input for mesh lights.
BR
Is there an option somewhere in the tons of Blender menus that allows me to read those raw values? I really don't see an option there to read the numbers.chafouin wrote: ↑Tue Mar 03, 2020 5:16 pm You are correct. This is in cd/m2 so if you set the tonemapper off and disable color management (show Raw values), the value you enter in your area light in Candela per Square meter (or artistic gain in LuxCore) will be the exact output value: 0.125 cd/m2 = RGB 32, 0.5 cd/m2 = RGB 128.
Does the exr format contain a channel to save directly the absolute luminance values? Can we read that channel somehow?
And one more question: the mesh light units aren't touched, do they? In my particular case I'm using this mesh light to rebuild LEDs down to their chip... this chip mesh is my light source and from LED datasheet I know the amount of lumens that are emitted by the chip but not is luminance... for me it would be helpful to keep the lumen input for mesh lights.
BR
OS - Windows 7 X64
CPU - Intel CORE i7
GPU1 - Variants of notebook card from nVidia
GPU2 - Variants of notebook onboard card from Intel
Lux - Latest possible relaease
CPU - Intel CORE i7
GPU1 - Variants of notebook card from nVidia
GPU2 - Variants of notebook onboard card from Intel
Lux - Latest possible relaease
Re: Light intensities and matching Cycles
In the render settings, under Color management: Then disable LuxCore tonemapper in the camera: In the viewport, values above 1 will obviously be clamped to 1. You can use LuxCore Linear tonemapper to multiply that value down: Pixel brightness = Luminance * Linear Tonemap gain.lighting_freak wrote: ↑Wed Mar 04, 2020 8:09 am Is there an option somewhere in the tons of Blender menus that allows me to read those raw values? I really don't see an option there to read the numbers.
If you start a normal render, the Image View has a Sample tool that will allow you to vizualize unclamped values (hold left click over the image)
Irradiance, although it won't contain the entire final image.lighting_freak wrote: ↑Wed Mar 04, 2020 8:09 am Does the exr format contain a channel to save directly the absolute luminance values? Can we read that channel somehow?
EDIT: If you set the tonemapper off, EXR and HDR files will contain the luminance information. Color management is not saved in these files.
2.3 adds new light units and didn't remove any. There are difference with 2.2 if you were using Power and Gain. In 2.2, Power and gain was automatically normalized by color luminance for the Emission node (but not for lights!). In 2.3 this will be turned off by default, with the option to turn it on yourself. This is to fix the previous behavior that somewhat assumed that Power was a photometric unit.lighting_freak wrote: ↑Wed Mar 04, 2020 8:09 am And one more question: the mesh light units aren't touched, do they?
There will be a button at the bottom of the render tab to convert the scene for you:
Re: Light intensities and matching Cycles
I wanted to make sure there was no wrong information staying on the forum as I wrote some confusing things yesterday.
If LuxCore tonemapping is off, the output is luminance (cd/m2) and can be saved as EXR and HDR format.
With the next version of Photographer (3.x), you will be able to visualize camera exposure tonemapping that won't affect EXR and HDR outputs, only SDR formats (png, TGA...) as Blender Color Management isn't applied on these 32-bits formats.
PS: And just as we discussed the q factor for camera exposure, Unreal decided to remove it in 4.25! https://www.unrealengine.com/en-US/tech ... re-in-4-25
If LuxCore tonemapping is off, the output is luminance (cd/m2) and can be saved as EXR and HDR format.
With the next version of Photographer (3.x), you will be able to visualize camera exposure tonemapping that won't affect EXR and HDR outputs, only SDR formats (png, TGA...) as Blender Color Management isn't applied on these 32-bits formats.
PS: And just as we discussed the q factor for camera exposure, Unreal decided to remove it in 4.25! https://www.unrealengine.com/en-US/tech ... re-in-4-25
Re: Light intensities and matching Cycles
@Dade, can you please check the Camera exposure math to see if everything is correct?
In Unreal, here is a 1 candela point light placed 1 meter above a white floor: As you can see it reads 1 lux, everything is exposed with a manual EV of 0. This is in 4.25 without using the q factor.
Same scene in LuxCore, with no Tonemapper: It matches fine, all good here.
Then using a Camera exposure of EV 0: The image is 3 times brighter, which is an exposure difference of 1.6 EV. This doesn't seem correct. In Unreal the difference between using q and not using it is a 0.263 EV difference, not 1.6.
In Unreal, here is a 1 candela point light placed 1 meter above a white floor: As you can see it reads 1 lux, everything is exposed with a manual EV of 0. This is in 4.25 without using the q factor.
Same scene in LuxCore, with no Tonemapper: It matches fine, all good here.
Then using a Camera exposure of EV 0: The image is 3 times brighter, which is an exposure difference of 1.6 EV. This doesn't seem correct. In Unreal the difference between using q and not using it is a 0.263 EV difference, not 1.6.