Lux measurement using Irradiance feature

[Dade]

It is a lot easier to start from the C++ code and leave the OpenCL code as next step. The CPU code is here: https://github.com/LuxCoreRender/LuxCor ... tracer.cpp

Just looks for "irradiance" and you will find the 2 places (direct light + indirect light) where it is compute.

[pro]

It is a lot easier to start from the C++ code and leave the OpenCL code as next step. The CPU code is here: https://github.com/LuxCoreRender/LuxCor ... tracer.cpp

Just looks for "irradiance" and you will find the 2 places (direct light + indirect light) where it is compute.

Do you think it´s theoretically possible to readapt those pieces of code to output lux (somehow reusing directLight/indirectLight variables and than devide by m²) or did I totally misinterpreted this (my physics knowledge is not that strong in this topic)?

[pro]

It is a lot easier to start from the C++ code and leave the OpenCL code as next step. The CPU code is here: https://github.com/LuxCoreRender/LuxCor ... tracer.cpp

Just looks for "irradiance" and you will find the 2 places (direct light + indirect light) where it is compute.

.IES files carry only information about visible light, so if there is no radiation in other non-visible spectrum, illuminance should be equal to irradiance in that case. I hope that's the case in LuxCore and that heuristics in irradiance feature doesn't include radiation in other specturms? If that's right, obtained "irradiance feature" output should be just multiplied by a precalculated scalar to get illuminance.

Another question that I have related to optimization - is it possible to render only irradiance pass without rendering default passes i.e. Combined aka RGB_IMAGEPIPELINE (by commenting out lines in C++ code and recompiling)? Or Irradiance feature somehow depends on calculation of those passes?

Thank you very much for your time and help!

[Dade]

Another question that I have related to optimization - is it possible to render only irradiance pass without rendering default passes i.e. Combined aka RGB_IMAGEPIPELINE (by commenting out lines in C++ code and recompiling)? Or Irradiance feature somehow depends on calculation of those passes?

Both irradiance AOV and RGB_IMAGEPIPELINE are the product of the same process so disabling the second AOV will have no tangible benefits.

[pro]

Both irradiance AOV and RGB_IMAGEPIPELINE are the product of the same process so disabling the second AOV will have no tangible benefits.

Thanks for the previous hint! I further tested Irradiance AOV and its output (produced light intensity patterns a.k.a. "false color plots") correspond to illuminance (I calculated them with another software), which seems great. The relationship is linear, like this:

right_illuminance_values = linear_factor * irradiance_AOV_output

Now I want to automate search of this linear_factor: I created a room with no reflections on the walls (to reduce number of variable parameters), and I put one .ies file inside that room. I "shot" a surface with orthographic camera with Irradiance AOV and I manually calculate the factor for this .ies file (it is 5). No matter where I move the light the right factor stays the same, which look great. But when I replace .ies with another .ies, the right manually calculated factor=30 (again for all light positioning the same factor is right).

Now I'm stuck, because I don't know how could I get this relationship between the right factor and .ies file (and later on also for different reflection degrees on the walls). Do you maybe have any ideas on how to approach this - any additional explanation/information would be highly appreciated?

P.S.:
Before calculation I make sure that light's power=1 and efficacy=luminous_flux (defined in corresponding .ies).

[Dade]

As far as I remember, an IES file includes only the relative emission power profile, it doesn't include any absolute value. So it is applicable to your test if, and only if, you set an appropriate power and efficiency in blender light source definition.

I suggest you to just use a plain point light source instead of one with an IES profile. It will like using an IES file with a constant profile and it will be easy to compute the expected result by hand.

[marcatore]

Dade, why are writing that IES file doesn't include any absolute value?

As reported here https://knowledge.autodesk.com/support/ ... 1-htm.html

chrome_2019-03-08_08-56-24.png (7.23 KiB) Viewed 628 times

So, looking at one IES file provided by a lighting manufacturer

As you can see the Lumen is reported and , according to the Lumen definition, it seems an absolute value.

From wikipedia https://en.wikipedia.org/wiki/Lumen_(unit)
The lumen (symbol: lm) is the SI derived unit of luminous flux, a measure of the total quantity of visible light emitted by a source.
...
The lumen can be thought of casually as a measure of the total "amount" of visible light in some defined beam or angle, or emitted from some source. The number of candelas or lumens from a source also depends on its spectrum, via the nominal response of the human eye as represented in the luminosity function.

[Dade]

Dade, why are writing that IES file doesn't include any absolute value?

In LuxCore, the values you list are not used. The code is a direct port of old LuxRender code. The parsing of lumen per lamp filed is here: https://github.com/LuxCoreRender/LuxCor ... s.cpp#L252
The read values are not used. As I wrote, the IES file is used in Lux only to build a relative (to the power * efficiency paramters) profile.

I could modify the parsing code to use the m_LumensPerLamp field to define the total power emitted by the light

[pro]

Dade, why are writing that IES file doesn't include any absolute value?

In LuxCore, the values you list are not used. The code is a direct port of old LuxRender code. The parsing of lumen per lamp filed is here: https://github.com/LuxCoreRender/LuxCor ... s.cpp#L252
The read values are not used. As I wrote, the IES file is used in Lux only to build a relative (to the power * efficiency paramters) profile.

I could modify the parsing code to use the m_LumensPerLamp field to define the total power emitted by the light

Is it the right approach to set power=1 and efficacy=luminous_flux in LuxCoreRender to define the right light emmision as defined in .ies file (for example in my case)? Or would a this new parser do anything else?

Also if I understood marcatore correctly, .ies file includes only visible spectrum information, and Irradiance feature (pls correct me if I'm wrong) uses only this kind information without other invisible spectrums. If that's the case, maybe a better name for this feature would be "illuminance AOV" rather that "irradiance AOV"?

[Dade]

Is it the right approach to set power=1 and efficacy=luminous_flux in LuxCoreRender to define the right light emmision as defined in .ies file (for example in my case)? Or would a this new parser do anything else?

It may be not enough, the profile is scaled by:

Code: Select all

	float valueScale = data.m_CandelaMultiplier * 
		   data.BallastFactor * 
		   data.BallastLampPhotometricFactor;

here: https://github.com/LuxCoreRender/LuxCor ... n.cpp#L203

They are the fields parsed after m_LumensPerLamp field in IES file: https://github.com/LuxCoreRender/LuxCor ... s.cpp#L252

So it is about understanding the relation between all the IES fields before taking any action.

Also if I understood marcatore correctly, .ies file includes only visible spectrum information, and Irradiance feature (pls correct me if I'm wrong) uses only this kind information without other invisible spectrums. If that's the case, maybe a better name for this feature would be "illuminance AOV" rather that "irradiance AOV"?

LuxCore (and 99.99% of all rendering programs) works only in visible spectrum. So, by definition, we are talking only of the visible portion of the Irradiance like with any other LuxCore inputs/outputs.