[Radiance-general] Re: rsensor file format

[Axel Jacobs]

Dear Greg, Jennifer,

 > The sensor file is normalized to 1.0 in arbitrary "response" units.
 > Think of it as a multiplier on the incoming radiance value in each
 > direction.

So I shouldn't think of it as an 'inverse' IES file, then. I've just run 
some simple examples with an ideal cosine data file, and the results do 
match the one I get from rtrace. Multiplying each value in the matrix 
with 2.0 gives me twice the illuminance.

I guess that the real question should be 'what do these sensors actually 
measure?'. It's not lux, because for this they would have to be cosine 
and v(lamda) corrected, which one could expect from a 500 Pound lux 
meter, but not from a 5 Pound sensor. I guess it all boils down to the 
commissioning of the sensors. The only thing we can say with certainty 
is that they measure 'some sort of radiation thing', which is different 
in different directions.

So is it correct to assume that SPOT only uses the relative response 
from the photocells, and not absolute W/m2 or lux values?

 >> b) What would the sensor file for a normal, cosine corrected
 >> illuminance meter look like? Does it need to have its maximum
 >> at 1.0 for an angle of (0,0)?

 > Yes to the second question, with 90 degrees being the maximum polar
 > angle, whose value is zero at all azimuths.  For this distribution,
 > rsensor will produce horizontal irradiance in watts/m^2, which
 > converts to lux using the standard 179 multiplier.  A uniform sky of
 > 100 watts/sr/m^2 would produce a value of 314.16 watts/m^2, or 56235
 > lux, for example.

Here is my own cunningly crafted cosine response. Just one column of 
azimuth values at zero degrees wouldn't work:

degrees	0	90	180	270
0	1.0000	1.0000	1.0000	1.0000
10	0.9848	0.9848	0.9848	0.9848
20	0.9397	0.9397	0.9397	0.9397
30	0.8660	0.8660	0.8660	0.8660
40	0.7660	0.7660	0.7660	0.7660
50	0.6428	0.6428	0.6428	0.6428
60	0.5000	0.5000	0.5000	0.5000
70	0.3420	0.3420	0.3420	0.3420
80	0.1736	0.1736	0.1736	0.1736
90	0.0000	0.0000	0.0000	0.0000

Does rsensor use a linear interpolation to fill in in-between rows?

 >> c) Suppose I wanted to model an illuminance meter that has
 >> a correct cosine response, but gives a reading twice as high as
 >> is should be.
 >> Would I need to multiply the values from b) by the cube root of 2?
 >> Cube root because the overall response appears to be proportional
 >> to the volume contained within the 3d shape of the curves.

 > It should be a simple proportion, so multiplying all values by 2.0
 > should give you what you expect.  I just confirmed that it works
 > that way.

I am still puzzled that the response is not proportional to the volume 
of the shape, or at least the area of the curve. Guess that's just the 
way it is, and there isn't really any strict photometric or radiometric 
reason behind this...

 >> It seems that the
 >> standard Radiance data file would have been sufficient to describe
 >> the sensor's characteristics. What is the advantage of using the
 >> SPOT format? Why not have a spot2rad (similar to ies2rad) import
 >> filter instead?

 > As I understand it, SPOT is an Excel-based program, so putting the
 > data in a format that isn't Excel-friendly didn't really suit Zack
 > Rogers and the other developers.  Charles Ehrlich had written an
 > earlier equivalent to rsensor that already used this data format,
 > and since ArchEnergy hired me to develop a more efficient approach,
 > they had the prerogative to specify the input and output.

This makes perfect sense now.

----------------

 > so you can download the program and take a look at the files
 > and implementation - if you haven't already.

It requires Windows and Excel, and while I have access to a Windows 
machine, I don't have Excel. Do you plan on making it cross-platform and 
OpenOffice compatible?

 > c)I might be misunderstanding the question but you should just
 > multiply the sensitivity values by 2 if you want double the signal.
 > This will increase the volume by 2^3 but is not used to scale the
 > sensitivity file.

Greg explained this, thanks. I understand it's all relative.

Thank you

Axel