# Converting intensity and radius to candela?

On 26/06/2015 at 01:49, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   R15
Platform:      Mac OSX  ;
Language(s) :     C++  ;

---------
Greetings to all!

How would one convert a light object's intensity + radius/decay to the appropriate Candela or Lumen value (as specified under the Photometric tab) when the falloff is set to "Inverse Square (Physically Accurate)"?

I'm having a hell of a time trying to figure out exactly what "Intensity" means in C4D. A percentage means nothing to me since it has no associated real world unit. The manual doesn't say anything about this either. I need to be able to convert these values into their real world units so I can export a scene to an external rendering engine (which only understands Candela or Lumen), but since I have no basis for what 100% actually means (at a given radius/decay), I don't know how to convert it into anything else.

-CMPX

On 26/06/2015 at 03:06, xxxxxxxx wrote:

actually giving a decaying radius is a joke , decaying radius makes it not physically accurate "from my understandings, there should be no radius, and light intensity at any point away from the light, is defined by:
intensity = light_intensity / distance^2
and at next intersection:
intensity2 = intensity / distance2^2
and at third:
intensity3 = intensity2 / distance3^2

and so on..

what you are doing is kinda strange, as the engine should have its own light object setup, and won't rely on Cinema4D light that much, + calculating intensity at any point is done during the rendering process "NOT a pre process".

so the external engine shouldn't know about radius, and the intensity units are discussed on wikipidea, Cinema4D scene unit scale can be accessed directly from project settings "project scale".

On 26/06/2015 at 04:01, xxxxxxxx wrote:

No, it's still physically accurate.

The radius/decay option in C4D just varies the actual light intensity so that the brightness of that light object reaches the target intensity at the edge of the radius. The actual falloff is still physically accurate (inverse square). It's a nifty way of setting up lights so you know exactly what the intensity is and where, but it seems to be a C4D specific thing, so other render engines can't cope with that.

Incidentally, C4D already supports Lumens, Candela, and Lux on the Photometric tab (which overrides the radius/decay because that's not required with real world units). Perhaps I wasn't clear in what I'm trying to achieve- I'd like to figure out how to convert the light intensity and radius/decay setting (when the falloff type is inverse square) to the equivalent Lumen or Candela output that would give the same visual effect when set on the Photometric tab.

So far I've worked out a rough approximation (it seems to be a linear conversion in the form of y = a * x + b), but it's not exact. I'd like to know if: A) that's even the case (I'd be surprised if it's that simple), and B) what the values for a and b actually are (I'm kinda hoping someone from MAXON can chip in here and offer up some details on how the Photometric tab's intensity works in regards to intensity and radius/decay).

-CMPX

On 26/06/2015 at 05:06, xxxxxxxx wrote:

actually you can't like this, let me explain why Cinema4D part is not physically accurate (*IF you didn't choose photometric intensity).

in any physically accurate light system, consider you have a point light of intensity I, the light will reach a point at a distance D.

intensity_at_point_d = I / D^2; // consider this equation (1)
so simple, now what Cinema4D does it:
intensity_at_point_d = I * (decay_radius - D)^2; // consider this equation (2)
intensity_at_point_d = Min(intensity_at_point_d , 0);//to avoid negative intensity outside of decay_radius

1 != 2 , so it is not physically accurate, it is just more user friendly.
Lumen, Lux, ..etc.. are just units, any one of them depends on project scale.

when you check photometric intensity (and inverse square decay (physically accurate)), Cinema4D uses equation (1) , if it is off, it uses equation (2)

units:
consider Lumen (lm) is the same as Cinema4D light intensity, so 1 lm = 100% light intensity.

On 27/06/2015 at 03:08, xxxxxxxx wrote:

Huh?

Lumens aren't the same as the C4D light intensity. You can test this yourself, go setup a spot light with a photometric intensity (configured for lumens) then play around with the outer angle of that spot light. The intensity of the light will correctly vary itself because lumens is a measure of total light output, not the brightness of the light itself (which is what candela is for).

Furthermore, you keep saying that C4D isn't physically accurate when you're using a inverse square falloff, radius/decay, and intensity. This seems incorrect since I can have one light configured as such and another light configured with a photometric candela intensity. I have to dial in that value by hand, but once I do the result is completely indistinguishable from the result without a photometric intensity. If both results null out in Photoshop, then how is the former not physically correct?

This is all getting way off topic. I know what I want to do can be done, because I can easily do it by hand (converting intensity & radius into candelas). I just need to know what the mathematical correlation between those are.

-CMPX

On 27/06/2015 at 06:39, xxxxxxxx wrote:

* I tested lumens with vray omni and c4d omni,
vray 100 lumens and 100% intensity gives exactly the same result as c4d 100 lumens and 100% intensity and similarly exactly the same result as 1 lumen and 10000% intensity, but this may not be correct with spots as I didn't test it so I can't confirm.

* I noticed, decay_radius is the starting radius of decay, so equation (2) is wrong and it converts to

intensity_at_point_d = (D <= decay_radius)? I : I / (D - decay_radius)^2; //equation (3)
//which doesn't equal equation (1) so it is not physically accurate, and shouldn't give the same result!!

you wrote:
"The radius/decay option in C4D just varies the actual light intensity so that the brightness of that light object reaches the target intensity at the edge of the radius. The actual falloff is still physically accurate (inverse square). It's a nifty way of setting up lights so you know exactly what the intensity is and where, but it seems to be a C4D specific thing, so other render engines can't cope with that."

which is exactly the same as I wrote here, non decaying light till a specific point is not physically correct even if it has a correct falloff, and you don't see it in other render engines because it is fake.

you also wrote "Incidentally, C4D already supports Lumens, Candela, and Lux on the Photometric tab (which overrides the radius/decay because that's not required with real world units). Perhaps I wasn't clear in what I'm trying to achieve- I'd like to figure out how to convert the light intensity and radius/decay setting (when the falloff type is inverse square) to the equivalent Lumen or Candela output that would give the same visual effect when set on the Photometric tab."

once you know the relation between lumen and c4d intensity unit "from the physically accurate behavior applied by equation (1)", you can solve the problem by using equation (3).

* I wrote a render engine so I know what I'm talking about

On 27/06/2015 at 18:36, xxxxxxxx wrote:

non decaying light till a specific point is not physically correct even if it has a correct falloff, and you don't see it in other render engines because it is fake.

Where are you getting "non decaying" from? That's where I'm getting lost. The light in C4D decays with whatever falloff you configure in the GUI ("Inverse Square" for physically accurate). The light doesn't stay at a constant brightness until it hits the edge of the radius (that would be "Inverse Square Clamped"). It exceeds the intensity by several factors (at the source of the light), and that amount is determined by the radius so that it meets the target intensity at the edge of that radius.

You can test this by rendering out an omni light near a flat surface with a large radius (enough to white out the render). If the render output is set to a 32-bit format, you can see that the values simply exceed white (255/255/255 or 1/1/1).

I believe what you're describing is actually the "Inverse Square Clamped" option (which MAXON themselves states is not physically accurate). This option will clamp the light output at the max intensity until you hit the edge of the radius, but that is a completely different option from "Inverse Square (Physically Accurate)".

Anyways, thanks for your help. I really do appreciate it, but I'm still kinda lost.  I understand the basis of the equations, but they're just not working for me even after I've rearranged them to try and calculate the actual brightness of the light object given a radius (and the intensity at that radius). This is what is puzzling me- it's like nothing I try lines up with what I'm reading on Wikipedia, Google, and here.

Just to try and clarify what I'm trying to figure out here, if you have a light object with the following settings, then they approximate the listed candela output (which I've just dialled in by hand)... I'm trying to calculate the exact correlation between these, but I can't seem to figure out what that formula is.

Light intensity: 100%
Light falloff: Inverse Square (Physically Accurate)
Approx. equivalent candelas: 1000

Light intensity: 100%
Light falloff: Inverse Square (Physically Accurate)
Approx. equivalent candelas: 1824.5

Light intensity: 100%
Light falloff: Inverse Square (Physically Accurate)
Approx. equivalent candelas: 2580

Light intensity: 100%
Light falloff: Inverse Square (Physically Accurate)
Approx. equivalent candelas: 3294

Light intensity: 100%
Light falloff: Inverse Square (Physically Accurate)
Approx. equivalent candelas: 3979

Light intensity: 100%
Light falloff: Inverse Square (Physically Accurate)
Approx. equivalent candelas: 4640

Light intensity: 100%
Light falloff: Inverse Square (Physically Accurate)
Approx. equivalent candelas: 5284

Light intensity: 100%
Light falloff: Inverse Square (Physically Accurate)
Approx. equivalent candelas: 5913

This doesn't seem to follow the formula of i = c / d^2, which is what puzzles me. I've tried rearranging that to solve for c (the output power at distance d with a known intensity at that distance), but the numbers don't line up.

-CMPX

On 28/06/2015 at 02:52, xxxxxxxx wrote:

I see, what you are saying is true "that's why it gives brighter intensity at points < radius" , so it increases light intensity by the radius factor.

//the equation "found from observation!!!"
float constant = 6.9077f;//ln(1000)
float difference = decay_radius - 1.f;
//curve fit points
//x, 2,3,4,5,6,7,8
//y, 2.31,  3.7 ,  5.98, 9.14,12.63,17.07,19.37
float curve_fit = 0.69f * (decay_radius^1.611f);
float factor = (difference <= 0.f)? constant: constant + exp(1.f + (1.f / curve_fit)));
float L = exp(factor * (1 - dr^(-1) + dr^(-2) - dr^(-3) + dr^(-4) - dr^(-5) + dr^(-6)));      //let this be equation Mohamed Sakr
dr = 2m, L = 1951
dr = 3m, L = 2426
dr = 5m, L = 3948
and so on...

have fun

On 28/06/2015 at 23:33, xxxxxxxx wrote:

Hey, thanks for the reply, but the numbers are still off.

It looks like this issue has something to do with sRGB correction when Linear Workflow is enabled. If LWF is disabled OR the input profile is configured for linear, then the inverse square law formulas apply perfectly and it's trivial to convert values (which is what I'd expect to happen). If you're working in LWF mode with an sRGB input profile, it appears as though the colour + intensity of the light are corrected somehow, which throws off your results if you're reading in the GUI values directly (which is what I was doing).

I've got a few things to try, but I'll update this thread later on.

-CMPX

On 29/06/2015 at 01:27, xxxxxxxx wrote:

Yup.

So the candela input in the C4D GUI is somehow "sRGB" corrected. If you're trying to convert the light intensity + radius (both of which are not sRGB corrected) to the corresponding candela units as listed under the Photometric tab, it's possible using the inverse square law to derive the intensity at the light source, but then that value needs to be converted from linear to sRGB before you can enter it into the GUI (unless of course LWF is disabled or the LWF input profile is set to linear).

I'm not entirely sure why photometric units are being corrected like this... Seems kinda weird if they're "real world" units.

-CMPX