Radiance Digest Volume 2, Number 10

Dear Radiance users:
Here is a long overdue installment of the Radiance Digest, your peek at
conversations between me and users like yourself.  If you don't consider
yourself a "user;" you have kicked the habit and would like to kick the
mailing list as well, write to me at:
Please do not respond directly to this mailing, as we don't have a proper
list server.  (And please don't ask why not.)
Here is the list of topics covered in this edition:
	GENSKY AND COLOR		How to color the sky and ground
	ANIMATION			Steps towards walk-through animations
	SETTINGS AND ACCURACY		How renderer settings map to accuracy
	MAPPING BARK TO BRANCHES	How patterns map to cylinders
	MUNGING PICTURE HEADERS		How to change the header on a picture
	MODELING A LASER		How to model laser light sources
	FALSECOLOR IN BLACK AND WHITE	Getting B&W display from falsecolor
	COMPILE SWITCHES		What are all those things in makeall?
	TRANS PARAMETERS		Making sense of trans primitive
	SOLAR ECLIPSE			Sampling a solar penumbra
	RETROREFLECTORS			Modeling SAE reflectors
In other news, I plan very shortly to release version 3.0 of Radiance,
which includes (among other things) a new type for single-scatter modeling
of participating media, and an animation control program called ranimate.
I decided to call it 3.0 instead of 2.6 since I made so many major revisions
and it's been nearly a year since 2.5 was released.  Watch this list for
an announcement.
Happy rendering!
From HXZZDUBIELJ@cluster.north-london.ac.uk Wed Oct 25 10:09:15 1995
Date: Wed, 25 Oct 95 17:06 BST
From: HXZZDUBIELJ@cluster.north-london.ac.uk
To: GREG <GREG@theo.lbl.gov>
Subject: Re: Floodlit Radiance pictures
To: Greg Ward
From: Jo Dubiel and Aris Tsangrassoulis
Hi Greg,
You may remember that I was going to send you some pics via xfer, and a couple
of papers. I have not forgotten, just not got round to it yet.
Aris is visiting us from the University of Athens. He seems to be the only
person in Greece who is using RADIANCE at the moment.
We are both working on a new project here, looking at daylighting under sunny
skies, and we will use RADIANCE simulations. This has brought up a couple
of questions:
(1) What is the difference between using the '-g' option on gensky, and using
    a ground of the same reflectivity as follows:
skyfunc glow ground_glow
4  0.2  0.2  0.2  0
(2) If using the 'glow' material type for the sky, how do we arrive at correct values for the r,g,b ? Is the magnitude of these values important? What r,g,b
values would you recommend for the colours of different sky types?
skyfunc glow skyglow
4  0.9  0.9  1  0
We hope to hear from you soon,
Aris & Jo
From: j.dubiel@unl.ac.uk
      Jo Dubiel
      Low Energy Architecture Research Unit
      University of North London
      Spring House
      6 - 40 Holloway Road
      London N7 8JL
      Tel:  0171- 753- 7006
      Fax:  0171- 753- 5780
From greg Wed Oct 25 10:24:08 1995
Date: Wed, 25 Oct 95 10:23:33 PDT
From: greg (Gregory J. Ward)
To: HXZZDUBIELJ@cluster.north-london.ac.uk
Subject: Re: Floodlit Radiance pictures
Hi Aris and Jo,
Working kind of late, aren't we?
You should use the -g option of gensky rather than reducing the color param's
on your glow material.  If you want to add color to either your ground or
your sky, make sure that the luminance is still 1 so that when you combine it
with the skyfunc pattern, the total luminance will be correct.
To do this, use the following formula for luminance from (r,g,b):
	l = .265*r + .670*g + .065*b
(This is in units of .00559 cd/m^2, but never mind that.)  Then, say you want
your color (hue,saturation) to be the same as (r,g,b)=(.5,.1,.05) -- a nice
brown.  The values you would use for your glow would be these divided by the
luminance as defined above, i.e. divided by (.256*.5 + .670*.1 + .065*.05),
which is .198.  Thus, you would use:
	skyfunc glow groundglow
	4 2.52 .504 .252 0
Apply the same type of calculation to the sky.  I don't know the best color
to use for anything, unfortunately.  You'll just have to pick your own
preference for that.  Beware highly saturated colors, as they tend to result
in odd-looking interiors with strong color casts on the floor and ceiling.
Good luck!
[And here's the question once more from someone else -- I can't believe I
 forgot that I had answered it before, but I've probably done it before and
 will probably do it again....]
From jst_ibp@mars.IPA.FhG.de Thu May 23 00:43:59 1996
Date: Thu, 23 May 1996 09:43:50 EDT
From: jst_ibp@mars
To: %mx%"greg@hobbes.lbl.gov"@mars
Subject: Gensky problem
Dear Greg,
We were asked the following questions by Dr. Hans Schmidt, Siemens,
which we are not able to answer and therefore would very much 
appreciate your help. Probably the answers are very straight forward
for you...
H. Schmidt noticed that the colour used for the sky influences
the luminances on the pictures and asked the following questions:
1) How do the RGB values for sky_glow and ground_glow have to be set 
to get the "original" CIE sky luminances and realistic values for the
ground (R=G=B=1 ?)
2) How does the -g option influence the result? Are the values of skyfunc
in the "lower" hemisphere weighted by using this factor?
3) R=G=B=1 results in a sky which is much too bright. Dark blue (for 
clear sky) and dark grey (for overcast sky) seems to be much better.
What can be done to get a realistic visualization and too be correct
according to CIE definition at the same time?
Thanks for your help.
Best regards,
Juergen Stoffel
Fraunhofer Institute of Building Physics, Division of Heat Technology
Nobelstrasse 12, 70569 Stuttgart, Germany
Tel +49 711 970 3327, Fax +49 711 970 3399, e-mail: jst@ibp.fhg.de
From greg Thu May 23 10:27:36 1996
Date: Thu, 23 May 96 10:27:12 PDT
From: greg (Gregory J. Ward)
To: jst@ibp.fhg.de, jst_ibp@mars
Subject: Re:  Gensky problem
Hi Juergen,
> 1) How do the RGB values for sky_glow and ground_glow have to be set 
> to get the "original" CIE sky luminances and realistic values for the
> ground (R=G=B=1 ?)
For a blue sky, I recommend the following glow material:
	skyfunc glow sky_glow
	4 0.986 0.986 1.205
	sky_glow source sky
	4 0 0 1 180
This will give a slight blue tint without affecting the luminosity.
I computed this using the formula:  grey = .265*R + .670*G + .065*B
> 2) How does the -g option influence the result? Are the values of skyfunc
> in the "lower" hemisphere weighted by using this factor?
Yes, gensky's -g option does affect the luminance of the lower hemisphere.
You should therefore make sure that it agrees with the grey value of the
color of the ground plane, if any.  If your ground plane is not grey,
you should also use the above formula to compute an appropriate glow
source for the ground.  For example, let's say that your ground plane
has the color (R=.4, G=.3, B=.1).  Then, your -g option should be set
to (.265*.4 + .670*.3 + .065*.1) = .3135, and your glow material should
have these values divided by the grey value, i.e., (R=.4/.3135, G=.3/.3135,
B=.1/.3135), thus:
	!gensky {date} +s -g .3135 {other options}
	void plastic ground_mat
	0 0
	5 .4 .3 .1 0 0
	ground_mat ring ground_plane
	0 0
	8 0 0 0 0 0 1 0 100
	skyfunc glow ground_glow
	0 0
	4 1.28 .957 .319 0
	ground_glow source ground
	0 0
	4 0 0 -1 180
> 3) R=G=B=1 results in a sky which is much too bright. Dark blue (for 
> clear sky) and dark grey (for overcast sky) seems to be much better.
> What can be done to get a realistic visualization and too be correct
> according to CIE definition at the same time?
This is a dynamic range problem, and there is little one can do about it.
The same problem occurs with an ordinary camera -- one simply cannot expose
both the inside and outside simultaneously and get decent results.  When a
person is in the acutal environment, their pupils and retina adjust as they
look out the window then back at their desk.  On a picture or a computer
monitor, however, we cannot easily mimic this.  The best you can do is to
readjust the exposure in ximage using the '=' or '@' commands.  Others have
substituted a fake sky out the window to overcome this problem, but that
seems like a lot of work and a bit of a cheat if you ask me.
Hope this helps.
From MFKPGMA@fs1.ar.man.ac.uk Fri Nov 24 03:07:17 1995
From: Mohd Hamdan Ahmad <MFKPGMA@fs1.ar.man.ac.uk>
Organization: Planning and Architecture.
To: greg@hobbes.lbl.gov
Date: Fri, 24 Nov 1995 11:04:20 GMT0BST
Dear Greg,
I am using Radiance to get DF results for my scenes.
I would like to ask if there is a way by which I can get rtrace to generate
periodic reports (similar to "rad") while I run my simulations. 
The reason behind is due to the long simulation time needed to do an 
rtrace to get my illuminance measurements.
My rtrace script is as follows:
rtrace -h -i -ds 0.02 -dt 0 -dc 1 -ab 2 -aa .15 -ad 512 -ar 128 -as 256 \
*.oct < points | rcalc -e '$1=($1*0.3+$2*0.59+$3*0.11)/(PI*8.9)' \
>> df_file
Another question I would like to ask refers to the gensky command.
I am currently using the Standard CIE Overcast sky. if I use the following
rad file:
    !gensky 01 01 13 -c -a 52.3 -o 0 -m 0 -B 27.93
    skyfunc glow skyglow
    4 1 1 1 0
    skyglow source sky
    4 0 0 1 180
 Is it safe to assume that this will generate an even sky distribution. 
 The reason I ask is because I've tested this sky on a symmetrical model
 ie. a box) with no roof and I get DF results that are not the same 
 on opposite ends of my model (I have used the same material reflective 
 properties for all my surfaces). Is there anyway I can improve on the
 results or is this really how RADIANCE behaves. If my illuminance readings
 are not the same on opposite ends of my  room, then should I assume that
 the -c (CIE overcast sky) parameter for gensky takes into account a
 sun source at an angle? Please enlighten me on this.
 Hamdan Ahmed
 email: mfkpgma@orpheus.man.ac.uk
From greg Mon Nov 27 11:16:35 1995
Date: Mon, 27 Nov 95 11:16:02 PST
From: greg (Gregory J. Ward)
To: MFKPGMA@fs1.ar.man.ac.uk
Subject: Re:  RADIANCE
Hello Hamdan,
The only way to know how far rtrace has progressed is to use the -x option
to cause it to flush its output after each point.  Then, use the -u option
to rcalc to make it flush its buffer, also.  The number of lines in the
output file (which can be determined simply with the "wc" program) will tell
you how many of the total points have been computed.  Your command would change
rtrace -x 1 -h -i -ds 0.02 -dt 0 -dc 1 -ab 2 -aa .15 -ad 512 -ar 128 -as 256 \
*.oct < points | rcalc -u -e '$1=($1*0.3+$2*0.59+$3*0.11)/(PI*8.9)' \
>> df_file
I hope you realize also the difference between the rtrace -i and -I options.
The former, which you are using, sends rays from the point in the direction
given to intersect a surface and compute the irradiance at the intersected
point.  If, instead, you want to compute the irradiance at a specific point,
which may not lie on any surface (e.g., the workplane), the you should use
the -I option instead.
The gensky command you are using will compute a symmetric CIE overcast sky
distribution.  It is not uniform, because it changes as a function of
altitude, but it is not a function of azimuthal direction, so your daylight
factors on opposite sides of a symmetric room should match.  That they don't
is not unusual, but it may indicate that more samples (-ad parameter) are
required for better accuracy.  Don't expect the values to ever match exactly,
however, since Monte Carlo calculations always have some random error
associated with them (as opposed to a systematic error, which may match).
I hope this helps.
From takehiko@MIT.EDU Tue Dec 12 06:55:01 1995
To: greg@hobbes.lbl.gov (Gregory J. Ward)
Subject: Re: Question 2.
Date: Tue, 12 Dec 1995 09:54:23 EST
From: Takehiko Nagakura <takehiko@MIT.EDU>
Mr. Ward;
 Thank you for the tips about rendering parameters.
 I tried to boost up -ad and -as values and am getting better
 image qualities now (takes a moment on my workstation, though).
 I am starting to work on a project to visualize interior space
 of famous but unbuilt architecture from the early 20 century now
 and interested in making animations.
 I have a few experience of making CG film of architecutre
 in Alias and Wavefront, but
 for this interior project, I would love to try with Radiance.
 Phil Thompson showed me a few of his animated work that he 
 did with Radiance before, and I am wondering if there is any utility
 to do animation that you or other people made? I found one
 on the Web made by New Zealand people (
, but if there is any other utilities for doing walk-through or
 lighting-animation, etc, will you let me know where I should
 look into? (I could not find any on your radiance manual. I am
 currently running radiance2.5, and maybe something is in 2.6?)
 I have some experience in cshell and c programming, and I would
 love to build myeslf some thing that I can contribute, but I
 would also like to know what is available now.
 Thank you for taking time for reading this again.
Takehiko Nagakura (Assist. Prof. of Architecture, MIT)
From greg Tue Dec 12 09:59:19 1995
Date: Tue, 12 Dec 95 09:59:05 PST
From: greg (Gregory J. Ward)
To: takehiko@MIT.EDU
Subject: Re: Question 2.
Hello Prof. Nagakura,
Unfortunately, there are no general animation tools in Radiance.  I have done
lighting and walk-through animations myself, and I find it is always better
to write the scripts to do them (using the C-shell or Tcl or Pearl or
whatever) and customize them each time.  There are simply too many different
optimizations and different ways of doing things to have a general utility.
I have tried and failed to design one several times.
You should study the utility programs cnt and rcalc, and the image inter-
polation program pinterp, which uses the -z option of rpict.  Other rpict
options you should know are -S and -o.  Check the man page for explanations.
My usual method to create a walk-through animation is to select keyframe
points using rview and the "view key.vf -t #seconds" command to add a new
keyframe with a separation (in seconds) from the previous view.  Then, I
use the following script to take this file and create a .cal file appropriate
for use with rcalc and the "spline.cal" file, which can be found in the
ray/src/cal/cal directory.  Rcalc may be used with cnt to generate a sequence
of evenly-spaced views as input to rpict.  These steps again are:
	1.  Run rview, and use the "v key.vf -t #secs" command to add views
		to a keyframe file.
	2.  Use the attached script, mkspline, to generate a .cal file for
		use with rcalc:
		% mkspline key.vf > key.cal
	3.  Use cnt with rcalc, key.cal and spline.cal to render a sequence
		of frames.  You may want to do this in low resolution first
		to check everything:
		% cnt 200 | rcalc -f spline.cal -f key.cal -e '5=$1/Ttot' \
			-o view.fmt | rpict [rendering options] \
			-S 1 -o anim%03d.pic -z anim%03d.zbf scene.oct &
		(The file view.fmt contains something like this:
VIEW= -vp ${s(Px)} ${s(Py)} ${s(Pz)} -vd ${s(Dx)} ${s(Dy)} ${s(Dz)}
	4.  Use the generated anim*.pic and anim*.zbf with pinterp to
		interpolate frames inbetween for a smoother animation.
The same command issued in step 3 above may be repeated on different machines
sharing the filesystem over NFS.  Each process will render the next unrendered
frame in the sequence.  If you are performing an interreflection calculation
(i.e., -ab >=1), be sure to use the -af option to rpict so that values are
shared between renderings and processes.
Also note that the views put out by rcalc AMMEND the initial view you may
set on the rpict command line.  View parameters that stay the same, such
as view type, resolution and probably up vector and size, need only be given
once on the command line.
I hope this is enough to get you started.  I'm sorry that I don't have a
canned solution to provide you.  Maybe someday, with help from users such
as you, I can gain enough insight into this problem to devise a general
----------------------------------------------- mkspline
#!/bin/csh -f
# Make a .cal file for use with spline.cal from a set of keyframes
if ( $#argv != 1 ) then
	echo Usage: $0 viewfile
	exit 1
cat <<_EOF_
	Keyframe file created by $0
	from view file "$1"
rcalc -i 'rview -vtv -vp ${Px} ${Py} ${Pz} -vd ${Dx} ${Dy} ${Dz} -vu ${Ux} ${Uy} ${Uz} -vh ${H} -vv ${V} -vs 0 -vl 0 -vo 0 -va 0 -t ${T}'\
	-o '${recno} ${Px} ${Py} ${Pz} ${Dx} ${Dy} ${Dz} ${Ux} ${Uy} ${Uz} ${H} ${V} ${T}'\
	$1 | tabfunc Px Py Pz Dx Dy Dz Ux Uy Uz H V T
[I have since written a new program, called ranimate, which handles many
 of the nasty details of running long animations.  It will be included in
 the 2.6 release, due any day now. -G]
From karner@fcggsg02.icg.tu-graz.ac.at Mon Jan 29 13:28:25 1996
Return-Path: <karner@fcggsg02.icg.tu-graz.ac.at>
Date: Mon, 29 Jan 1996 22:17:43 +0100 (MET)
From: Konrad Karner <karner@icg.tu-graz.ac.at>
To: GJWard@lbl.gov
Subject: Accuracy!
Status: R
Hi Greg,
Thank you for your quick answer of my last question.
I'm using Radiance (rpict and rtrace) to calculate luminance values
respectively illuminance values in my test scene. 
I used your recommended rendering options (min, fast, accurate) to 
calculate the luminance values for the same point and I saw that there 
occur large differences. So I'm interested how close are the value 
of the accurate simulation to the maximum option. 
For example, I got 30cd/m2 for the min. option
	  	   38cd/m2 for the fast option
	       and 88cd/m2 for the accurate option
I had to stop the calculation with the max. option because it took to 
much time (I got no results after 3 days on a SGI Power Challenge).
I also studied the convergence of the algorithm by calculating the 
luminance values in 11 equally steps between the fast and the accurate 
option by interpolating the parameters. The luminance values of 50% of the 
points in the last steps exhibits no convergent behavior.
Do you have any data of the accuracy of the algorithm?
Do you know how large are the errors in the min, fast, accurate and max 
option could be?
| Konrad F. KARNER                                           |
| Institute for Computer Graphics                            |
| Graz University of Technology                              |
| -----------------------------------------------------------|
| Muenzgrabenstrasse 11                                      |
| 8010 Graz, Austria                                         |
| Tel.: (+316) 873-5022    	Fax: (+316) 873-5050         |
| E-mail: karner@icg.tu-graz.ac.at                           |
| WWW: http://www.icg.tu-graz.ac.at/                         |
From greg Mon Jan 29 13:37:37 1996
Date: Mon, 29 Jan 96 13:37:15 PST
From: greg (Gregory J. Ward)
To: karner@icg.tu-graz.ac.at
Subject: Re:  Accuracy!
Hi Konrad,
The accuracy of the calculation depends a lot on your scene, so there is no
direct correlation between most of the rendering options and a percentage
accuracy value.  This is an unfortunate but necessary characteristic of
this approach to lighting calculation.  The only method that can truly
claim convergence under arbitrary conditions is naive Monte Carlo, which
would never finish in our lifetimes for most scenes.
My best advice is to employ the "rad" program to set options for you based
on qualitative scene characteristics.  Using "rad", you can expect about
20% pixel accuracy for "low" quality, 10% pixel accuracy for "medium"
quality, and 5% pixel accuracy for "high" quality settings.  There will
be exceptions, of course.
The kind of bad convergence you are seeing would seem to indicate that you
are not choosing an appropriate value for the -av setting, which is very
important as an initial guess of average scene radiance.  Without it, you
are relying entirely on Radiance to follow every bit of light around your
scene, through all its random bounces ad infinitum.  It doesn't do that so
The main parameter that will affect convergence in simple scenes is -ab,
followed by -ad.
P.S.  Radiance has been validated against other calculations and model
measurements, and is (at least potentially) quite accurate.  The problem
is applying it properly, which can be difficult.
From cs4gp6ar@maccs.dcss.mcmaster.ca Thu Feb 29 12:30:59 1996
Date: Thu, 29 Feb 1996 15:27:23 -0500 (EST)
From: Janik       ME <cs4gp6ar@escher.dcss.McMaster.CA>
To: greg@hobbes.lbl.gov
Subject: radiance
Hello there,
We are working on a project at McMaster University with Dr.Jones to 
generate various trees using L-systems.
We would like to map bark and leaf textures onto them, but we are having 
a difficult time finding examples or methods in the available 
If you could please  tell us where to look for such examples, or send us 
an example we would greatly appreciate it.
				Marta Janik
From greg Thu Feb 29 12:41:01 1996
Date: Thu, 29 Feb 96 12:39:28 PST
From: greg (Gregory J. Ward)
To: cs4gp6ar@escher.dcss.McMaster.CA
Subject: Re:  radiance
Hi Marta,
I don't have a really good example handy, but for mapping onto branches
and the like, I've used a cylindrical mapping, that looks like this:
void colorpict bark_pat
7 red green blue pinebark.pic cyl.cal cyl_match_u cyl_match_v
2 1.5225225 .25
The first real argument is the aspect ratio of the pattern's picture
(pinebark.pic in this case), and the second real argument is the
unit scale for this picture (larger values yield larger tiles).
This pattern must then be transformed (along with the branch) to the
appropriate position.  The cylindrical mapping in cyl.cal assume you
have a cylinder with unit radius whose axis is along the Z coordinate axis.
You may use a cone with a slight graduation instead of a cylinder and you
won't notice much difference.
I hope this helps.
From courret@lesosun2.epfl.ch Fri Mar  1 02:32:30 1996
Return-Path: <courret@lesosun2.epfl.ch>
Date: Fri, 1 Mar 96 11:30:22 +0100
From: courret@lesosun2.epfl.ch (Courret)
To: greg@hobbes.lbl.gov
Subject: findglare
Status: RO
Hi greg,
I would like to compute the Guth's comfort index for a picture obtained
by pcomb. I have seen in the man page of findglare that, this command
will not work on pictures processed by pcomb. Is there a way to go around
this limitation? Or, would it be possible to extend the capability of
Note: I have tried also to add the view information lost by pcomb using
the option -vf view.vp in the commande that calls findglare,
but without success...
Laboratoire d'Energie SOlaire et de Physique du Bbtiment
Ecole Polytechnique Fidirale de Lausanne
1015 Lausanne
Til: xx.21.693.55.53
Fax: xx.21.693.55.50
From greg Fri Mar  1 09:37:15 1996
Date: Fri, 1 Mar 96 09:35:40 PST
From: greg (Gregory J. Ward)
To: courret@lesosun2.epfl.ch
Subject: Re:  findglare
Hi Gilles,
The main problem with pcomb is not that it loses the view information
(though this may be why findglare fails), but that it performs arbitrary
operations on the pixels, so it is easy to mess up.
You can get around the information header stuff by editing it yourself,
like so:
	% getinfo < picture > header
	% vi header
	% getinfo - < picture >> header
	% mv header picture
The "getinfo -" command takes a picture from standard input and strips off
the header, thus the above replaces the header of "picture" with whatever
you create in vi.
Hope this helps.
From jm@dmu.ac.uk Tue Mar 26 06:12:37 1996
Date: Tue, 26 Mar 1996 14:12:35 GMT
From: John Mardaljevic <jm@dmu.ac.uk>
To: greg@hobbes.lbl.gov
Subject: Re:  Mist extinction
Two things:
(1) How do I specify a non-diverging ("laser") beam, other than using
a long focus spot; and
(2) I thought you'd like to know, if you don't already - the
Bartlett School (Univ. College London) have just advertised
a "Lighting Researcher" post specifically asking for Radiance
experience.  It's only one year, but I guess they feel they are
being left behind without some direct involvement.  Be interesting
to see who they get.
From greg Tue Mar 26 11:04:14 1996
Date: Tue, 26 Mar 96 11:03:57 PST
From: greg (Gregory J. Ward)
To: jm@dmu.ac.uk
Subject: laser
Hi John,
The only way I can think to model a laser beam is to set the radiance to
increase as a function of distance, but be non-zero only within a cylinder
projected from the source.  I.e.:
	# Beam function with cancellation of fall-off (A1 is beam radius)
	void brightfunc laser_beam
	2 if(Ts*Ts*(1-Rdot*Rdot)-A1*A1,0,Ts*Ts/(PI*A1*A1)) .
	1 .125
	# Laser beam emittance (in watts/sq.meter)
	laser_beam spotlight laser
	7 1000 0 0  1  0 1 0
	# Laser source (radius should match laser_beam A1 above)
	laser ring laser_source
		0	0	0
		0	1	0
		0	.125
The function in laser_beam does two things -- first, it checks to see whether
or not a sample point is within the cylindrical beam.  If it isn't, a value
of zero is returned.  If it is, then a value that will cancel the normal
R-squared falloff is returned.  This, when multiplied by an initial radiant
emittance, will result in the same irradiance for any surface oriented
towards the laser source at any distance.
The spotlight type is only used for efficiency, so we don't have to check
the source in all directions, just 1 degree around the aimed direction.
That's curious about the Bartlett School position.  I wish Radiance drew
the sort of crowd here that it does in England!  Maybe I should have you
come out to California to run my publicity campaign!
From sfa@sizemorefloyd.com Thu Apr  4 14:44:41 1996
Date: Thu, 4 Apr 1996 17:44:30 -0500
To: greg@hobbes.lbl.gov
From: "Sizemore Floyd Architects, Inc." <sfa@sizemorefloyd.com>
Subject: falsecolor question
Hi Greg,
I have a (hopefully) brief question for you:
We am trying to put together a presentation for our clients, where we need
to make a _greyscale_ graphical represention of the "value" of one
daylighting design over a presumably less optimal one.
(Since I have virtually /no time/ to do this,) my idea was to 
use some perspective renderings of the two designs at issue,
then use 'falsecolor' with the -r/-g/-b switches so that the 
range of falsecolors representing the luminance gradient would go 
from white to black instead of red to green to blue.  We could then
(hopefully, with a little help from Photoshop) use these images to visually
illustrate our point.  (In addition to the daylight factor (etc.) numbers.)
The docs say:
      "The remaining options, -r, -g, and -b are for changing 
      the mapping of values to colors. These are expressions 
      of the variable v, where v varies from 0 to 1. These 
      options are not recommended for the casual user."
Well, I'm pretty casual but I'd like to try this anyway...
Can you please point me toward any information on how to go about
tweaking these options?  Hope the intent of what I'm thinking of is clear.
Oh yeah, please email me at stuartl@netcom.com instead of the reply-to address.
PS:  I've set up a new Pentium Pro in the office with Linux expressly for
the purposes of running Radiance.  (It's not an Indigo, but...)  It
multiple-boots Windoze NT and DOS also.
Stuart Lewis,
Sizemore Floyd Architects, Inc.
From greg Thu Apr  4 15:16:52 1996
Date: Thu, 4 Apr 96 15:16:28 PST
From: greg (Gregory J. Ward)
To: stuartl@netcom.com
Subject: falsegrey
Hi Stuart,
Glad to hear you're still struggling with Radiance in your new capacity....
Try the following:
	-r 'if(frac((x-y)*v/10)-v,1,0)'
	-g 'if(frac((x-y)*v/10)-v,1,0)'
	-b 'if(frac((x-y)*v/10)-v,1,0)'
This should result in a dashed line, the length of which is controlled
by the value.  (I'm assuming you're using the -cl and -p options of
falsecolor as well.)  I tried it on one example, and it seems to work
for B&W output.  The only problem is that the dashes aren't computed
according to the line orientation (which is unknown to the program),
so diagonals one way look better than diagonals the other way.
From stuartl@netcom.com Fri Apr  5 07:56:26 1996
Return-Path: <stuartl@netcom.com>
From: stuartl@netcom.com (Stuart Lewis)
Subject: grayscale revisited
To: greg@hobbes.lbl.gov
Date: Fri, 5 Apr 1996 07:56:05 -0800 (PST)
Status: RO
Hi Greg,
I tried both the solutions you offered, but they didn't do /exactly/
what I had in mind- hopefully it's simpler than that.  We are not going
to contour lines at all on these images.  The intent is to convey
different degrees of brightness to the viewers (who wouldn't
understand the numbers, anyway.)
Any ideas?  Your solutions /will/ be valuable in the future, since we
don't do very many color submittals.
Thanks again!
From greg Fri Apr  5 10:00:59 1996
Date: Fri, 5 Apr 96 10:00:34 PST
From: greg (Gregory J. Ward)
To: stuartl@netcom.com
Subject: Re:  grayscale revisited
Well, all I can suggest is setting "-r v -g v -b v", thereby mapping to
greyscale with a legend, and see if that's good enough.
From jedev@MIT.EDU Tue May  7 13:10:10 1996
To: greg@hobbes.lbl.gov (Gregory J. Ward)
Subject: lighting units 
Date: Tue, 07 May 1996 16:10:15 EDT
From: John E de Valpine <jedev@MIT.EDU>
I apologize if this is somewhere that I should be able to discover it
myself, but what are the proper units for "nits". I assume that "nits"
are the appropiate term for radiance and irradiance values, is this
And while I am on the subject, when one uses the mouse and the "L" key
to query a radiance image what are the units returned, is it lux? How
can I create an image that has a series of these values displayed which
the image is first opened with ximage?
My knowledge of lighting is largely experiential derived through
experimentation with radiance, so these are probably fairly naive questions.
-Jack de Valpine
From greg Tue May  7 13:21:18 1996
Return-Path: <greg>
Date: Tue, 7 May 96 13:21:05 PDT
From: greg (Gregory J. Ward)
To: jedev@MIT.EDU
Subject: Re:  lighting units
Status: R
Hi Jack,
"Nits" is shorthand for "candelas per square meter", which is shorthand for
"lumens per steradian per square meter".  This is the photometric unit
reported by the "l" commmand of ximage when run on a standard Radiance picture.
If, on the other hand, the Radiance picture was generated using the -i option,
then the values reported would be in terms of lux (lumens per square meter).
The units of radiance are actually watts per steradian per square meter.  These
get converted from watts to lumens using a factor of 179 lumens/watt and the
proper proportions of red, green and blue to match the human eye's sensitivity
to different wavelengths.
There is no way to get ximage to come up displaying point luminances, unless
you write a program or something to stick mouse events into its input queue.
(I don't know enough about X11 to even be sure this is possible.)  A better
approach is to use the "falsecolor" program to convert your image to one
that displays luminance or whatever with a corresponding legend.  Check out
the manual page for examples.
P.S.  Your questions are not too naive.  A lot of users don't know this stuff,
and it's rather difficult to explain/understand.
From audile@onramp.net Fri May 24 10:43:14 1996
Subject: RE: optimized rpict
Date: Fri, 24 May 96 12:42:53 -0500
From: Robert Kay <robert@audile.com>
To: "Kevin Matthews" <matthews@aaa.uoregon.edu>,
        "Greg Ward" <greg@hobbes.lbl.gov>
Hi Greg and Kevin:
I thought I'd let you know of my progress in optimizing the rpict code.  
Although I'm in almost daily contact with Motorola with bug reports on 
their compiler, I have made some good progress with the project.
The large image in the texture folder which originally took around 30 
hours now completes in around 10.  The compiler is causing some of the 
classic size/speed issues; not in the produced code (it is actually 
smaller) but in the memory usage of the program when running.  I have 
gotten stack overflows several times.  As soon as I figure out how to 
adjust stack size, I will.
There are still several outstanding issues which I do not understand.  
The new rpict cannot properly execute commands (!'s) within an object.  
It is as if the pipe which sends the data back to rpict always comes up 
empty.  I can't figure out why.
Other problems include the inability to fully optimize the files 
calfunc.c and o_instance.c and particularly header.c, which causes the 
compiler to crash the machine when it is optimized !!!
I have also not been able to get the compiler to properly do 
interprocedural analysis across different source files, which I'm sure 
will help quite a bit.  I have a plan to make that happen, but first I 
have to figure out what makes the optimizers freak out with the above 
three files.
Greg -- is there any place I can find out just what all of the Radiance 
compile switches really are for?  Most are obvious, but other's are a 
little harder to figure out.  I have tried to go through the makeall 
script to figure out when they get set, but it's not quite enough info.
So that's where I am.  I look forward to making this rpict binary 
available to everyone when I get it fixed.  I really think it makes the 
Mac a more than just viable rendering platform.  Next we'll try to get it 
out of the UNIX operating system, which slows it down.  Seems like it 
should be possible (with frozen octrees at least).  Maybe after that 
we'll figure out Mac distributed rendering.
take care,
From greg Tue May 28 11:22:32 1996
Date: Tue, 28 May 96 11:22:06 PDT
From: greg (Gregory J. Ward)
To: robert@audile.com
Subject: RE: optimized rpict
Cc: matthews@aaa.uoregon.edu
Hi Robert,
Your work sounds quite ambitious to me!  I'm glad that you're making such
progress.  In answer to your query regarding compile switches, here's a
quick list:
	-DALIGN=(type)	Alignment type, machine-dependent.  Most RISC
			architectures align on 8-word boundaries (double).
			The default alignment type is int.
	-DSPEED=(MIPS)	Millions of instructions per second for this
			processor (approximate).  This is used to decide
			certain unimportant timing issues such as how many
			rays to trace before checking input in rview and
			whether or not to optimize the color table in ximage
			on 8-bit displays.
	-DWFLUSH=(rays)	Override for number of rays before flush in rview.
	-DBSD		Operating system has a strong Berkeley flavor, meaning
			that bcopy() and bzero() are present but maybe memcpy()
			and memset() are not.  (See common/standard.h for other
			things this flag affects.)  Also affects certain system
			calls, such as signal handling and resource tracking.
	-DDCL_ATOF	The function atof() (ASCII to float) is not defined
			in either stdio.h or math.h, so we need to declare it.
			In better days, a duplicate declaration of such a
			function would never have been a problem, but with
			the advent of prototypes and idiot systems that define
			these things as macros, portability is Hell.
	-DBIGMEM	The system has lots of RAM available, so size hash
			tables and the like accordingly.  Also provides for
			larger overall scene descriptions (262,080 primitives
			rather than 32,704).  Even larger scenes can be
			accommodated by defining MAXOBJBLK > 4096.
	-DSMLFLT	This setting tells Radiance to use short floats
			(4-bytes) throughout, which saves lots of memory
			but can cause calculation inaccuracies in many
			cases.  Its use has been discontinued for this reason.
Other defines may be used to overcome portability problems on various operating
systems.  A common trick, for example, is -Dvoid=char to overcome systems that
define malloc() as returning pointer to void, which is prohibited on other
systems and disagrees with the way I've defined things in Radiance.  (Again,
this wouldn't be such a problem if there was consistency as to when and where
malloc() and other such declarations show up.)
I hope this helps.
From jedev@MIT.EDU Fri May 31 11:40:07 1996
From: jedev@MIT.EDU
To: greg@hobbes.lbl.gov (Gregory J. Ward)
Subject: More question on 'trans'
Date: Fri, 31 May 1996 14:40:45 EDT
Based on our previous discussions I modeled a cloth membrane in the
following manner:
	void trans trans_cloth
	7 0.35 0.35 0.35 0.1 0 1 0.1
which assuming I have worked this out properly should yield the
following behavior:
	void trans id
	7 r g b spec rough trans tspec
	d_ref =	((1 - spec) * (1 - trans) * rgb_avg)
		((1 - 0.1) * (1 - 1) * 0.35) = 0
	I'm not sure about this one, in our last correspondence you said
	that I needed to add in a (1 - specular_reflection)
	d_trans = (rgb_avg * trans * (1 - tspec))
		  (0.35 * 1 * (1 - 0.1)) =  31.5%
	s_trans = (rgb_avg * trans * tspec)
		  (0.35 * 1 * 0.1) = 3.5%
This yields a material that from the interior appears as a light grey
and through which the shadows of the external photovoltaics can be
seen. But from the exterior this material appears as a fairly dark
grey. Now on the one hand this may make sense, because of the darker
interior and the high diffuse transmitted component we are seeing a
farily dark surface. But the effect that I am now looking for which
seems to make intuitive sense to me, but may not make physical sense, is
a material that is 'white,' from the outside, 'light grey' inside ,and
diffusely transmits approximately 35% of incoming light while reflecting
approximately 65%.
In the initial case did I model a 'grey' trans material?
Would 'white' be something like the following:
	void trans trans_cloth
	7 1 1 1 0.07 0.2 0.35 0.1
	d_ref =	((1 - spec) * (1 - trans) * rgb_avg)
		((1 - 0.07) * (1 - 0.35) * 1) = 60.45%
	d_trans = (rgb_avg * trans * (1 - tspec))
		  (1 *  0.35 * (1 - 0.1)) =  31.5%
	s_trans = (rgb_avg * trans * tspec)
		  (1 * 0.35 * 0.1) = 3.5%
How does roughness get factored in?
What am I missing? Is there somewhere that I should look to find these
various formula/relationships?
As always thank you very much for your time.
-Jack de Valpine
From greg Fri May 31 12:04:23 1996
Date: Fri, 31 May 96 12:03:57 PDT
From: greg (Gregory J. Ward)
To: jedev@MIT.EDU
Subject: Re:  More question on 'trans'
Hi Jack,
The formulas for various materials may be found in the file ray/doc/material.1,
or in PostScript form in ray/doc/ps/material.1.  What you have written here
is mostly correct, except that the diffuse transmittance needs another
factor of (1 - spec) in there.
The problem is as you have stated it; i.e., you want more diffuse reflection
than your original material has.  It would be highly abnormal for a material
to diffusely transmit light without also diffusely reflecting it, which is
why the results disagree with your intuition (which I would call 'experience').
Your revised values I think should give you a much more satisfactory, and
realistic, result.  The roughness determines how much specular light is
scattered, which affects how clear reflected and transmitted images appear.
I am not sure in this case if you really want any specular reflection --
I would be tempted to set the fourth argument to zero.  If you set the
roughness also to zero, then you will be able to see objects clearly
through the material.  I don't know if this is what you want, though.
From jromera@dolmen.tid.es Thu Oct 19 10:24:32 1995
Date: Thu, 19 Oct 1995 18:25:17 GMT
From: jromera@dolmen.tid.es (Juan Romera Arroyo)
To: greg@hobbes.lbl.gov
Hi Greg,
long time ago I sent you a mail about simulating an eclipse.
The problem was that the penumbra was not accurate.
I'm trying to reproduce the situation of the next total eclipse (24th Oct 1995)
The radiance file I'm working on is something like this:
void plastic blue
5  0.2  0.1  0.8  0.00  0.00
void plastic gray
5  0.8  0.8  0.8  0.00  0.00
void illum sunlight
1 bright
3  90000  90000  90000
void light bright
3  5 0.2 0
sunlight sphere sun
4 -70.837471 162.4618481 71.9712839 109.245
!xform -s 1.0 -t 20282.884754 10793.67311 4681.0978365363  earth.norm
!xform -s 0.273 -t 20232.3077 10767.19458 4669.9966 moon.norm
earth.norm is:
blue sphere ball
4  0 0 0 1.0
moon.norm is:
gray sphere ball2
4  0 0 0 1.0
The coordinates of the moon, earth and sun are exactly the same ones as
on 24th Oct. 1995 at 4:30 PM GMT. All of them are scaled to the radius
of the earth. (Radius earth=1.0)
When I render this file using rpict with the following parameters:
rpict -ps 1 -dj 0.50 -pj .9 -ds 0.1 -vv 2 -vh 2 -x 480 -y 480 -t 5 
-vp 20200 10740 4650 -vd 82 53 31 -av .00 .00 .00 
I get the moon shadow on the earth. However despite the "artifacts" I get
in the border of the shadow, it's also too big and too much sharp. The area
of total obscurity should be much smaller than the one I get.
Am I doing something wrong ? maybe changing the rpict parameters ? ...
Hope you can help me on this.
Thank you
Juan Romera
From greg Thu Oct 19 11:14:39 1995
Date: Thu, 19 Oct 95 11:14:22 PDT
From: greg (Gregory J. Ward)
To: jromera@dolmen.tid.es
Subject: Re:  ECLIPSES
Hello Juan,
I do not understand why you used an illum for your sun source.  I would have
just used the light specification with the illum arguments, i.e.:
void light sunlight
3 90000 90000 90000
Anyway, this doesn't affect penumbra so it doesn't really address your question.
The basic problem you are facing is the fact that Radiance does not do
high-accuracy penumbra for spherical sources.  I would recommend that you
replace your sun with a tessellated sphere.  I took the following right from
the gensurf man page:
	!gensurf sunlight sun 'X+R*sin(PI*s)*cos(2*PI*t)' 'Y+R*cos(PI*s)' \
			'Z+R*sin(PI*s)*sin(2*PI*t)' 7 10 -e 'R:109.245' \
			-e 'X:-70.837471;Y:162.4618481;Z:71.9712839'
Use it in place of your solar sphere, and I think you'll start to see a better
From esp@sirius.com Mon Oct  9 16:48:41 1995
Date: Mon, 9 Oct 1995 16:50:58 -0700
To: gjward@lbl.gov
From: esp@sirius.com (Erich Phillips)
Subject: SAE Retroreflectors (and your memory)
Hi Greg-
You may remeber sometime ago, you helped me figure out how to model
retrofeflectors on cars as specified by the SAE. I am trying to resurrect
this, and I am confused on some points. The SAE specs give values in
millicandelas per incident lux. This strange unit is provided for 3
entrance angles at each of 2 observation angles. The table for a red
retroreflector is as follows:
                0 degrees       10 degrees      20 degrees
Observation     Entrance        Entrance        Entrance
Angle (deg)     Angle           Angle           Angle
0.2             420             280             140
1.5             6                 5               3
The SAE spec also states that "...reflectors may have any linear or area
dimension; but, for the photometric test, a maximum projected area of 7740
mm2 contained within a 254mm diameter circle shall be exposed". As I
recall, your calculations took this area restriction into account somehow.
If you wouldn't mind, could you help me resolve this puzzle? I have
attached the following three files that you created before:
reflector.cal - the function file
sae_refl.dat - the data file for red reflectors
sae_retro.rad - the radiance description file for a 2" x 2" square reflector
Lastly, my old mail server appears to be down.  I can also be reached at
esp@sirius.com, the server from which this message originates.
	Retroreflector BRDF's
	from Greg Ward
	A5 is the surface area of the reflector in square meters
	{divied value by projected area}
sae_refl(v) = v / Rdot / A5;
	{angle of source to normal}
sae_theta (x,y,z) = Acos(x*Nx+y*Ny+z*Nz)*180/PI;
	{angle of view to source}
sae_phi(x,y,z) = Acos(-(x*Dx+y*Dy+z*Dz))*180/PI;
#  sae_refl.dat
0 20 3
.2 1.5 2
1.67 .026
1.12 .019
.558 .011
# sae_retro.rad
# SAE Red Road reflectors
# Units originally in inches
void metdata sae_red
5 sae_refl sae_refl.dat reflector.cal sae_theta sae_phi
5 1 .01 .01 .9 .00258
sae_red polygon reflector
0 0
12 -1 -1 -240
    -1  1 -240
    1  1 -240
    1 -1 -240
 Erich S. Phillips, Ph.D.            email:  esp@sirius.com
 Biophysics                          work:   (415) 597-4300
 FTI Corporation                     FAX:    (415) 597-4344
 55 Hawthorne Street, 10th Floor
 San Francisco, CA  94105
From greg Mon Oct  9 17:55:47 1995
Date: Mon, 9 Oct 95 17:55:30 PDT
From: greg (Gregory J. Ward)
To: esp@sirius.com
Subject: Re:  SAE Retroreflectors (and your memory)
Hi Erich,
I do remember this, though not terribly well.  Are the files I did for the
reflector data you included in your message?  If so, I have not succeeded
in reproducing the values in the sae.dat file, though the calculation seems
to be generally correct, at least if the millicandelas/lux are relative to
lux measured perpendicular to the reflector plane.  If the lux values in the
SAE spec. are measured relative to the incident beam rather than the reflector,
then an additional correction factor may be needed.
As for the limitation on measurement conditions, there is no correction I
can see for the fact that the reflector may exceed the measurement conditions.
As long as your reflector is less than 12 square inches and fits within a 10"
diameter circle (converting to units my brain is familiar with), there is
no need for concern.  Is this not the case?
From esp@sirius.com Tue Oct 10 17:37:17 1995
Date: Tue, 10 Oct 1995 17:39:49 -0700
To: gjward@lbl.gov
From: esp@sirius.com (Erich Phillips)
Subject: metdata and my ignorance (clue: GDG)
Hello again, do you like my hat?
No, I do not like that hat.
Goodbye, again.
Do you know the source?  You get a wonderful prize for the correct answer.
This is not really why I rang.  I admit that I am still confused by the
metdata material type.  I do not understand exactly what it is I am
computing for the data file.  In the example I sent you, how would one
compute the values that go into the sae_refl.dat file?  For example, at 0
degrees entrance angle and 0.2 degrees observation angle, the sae spec is
420 millicandela per incident lux.  Do I want to compute the effective
reflectance?  In my understanding, this would be Reflectance =
Pi*Luminance/Illuminance.  But I do not know the luminance, I know that I
have a reflected luminous intensity of 0.42 candela for each incident lux.
Furthermore, why in the reflector.cal function file am I dividing by the
projected source area (I assume Rdot*A5 is the projected source area).
I guess what I am asking is how would one structure the files to create a
retroreflector meeting the SAE specs.  And one more related question, if I
am permitted.  I also have specs for some retroreflective sheeting where
the reflectance is given in units of specific intensity per unit area (such
as candela/lux/square meter).  How would one perform a similar computation
with such data.
I thank you for your prompt attention, as usual, to my questions.  If my
ignorance should ever become too intolerable, please feel free to question
my heritage.
 Erich S. Phillips, Ph.D.            email:  esp@sirius.com
 Biophysics                          work:   (415) 597-4300
 FTI Corporation                     FAX:    (415) 597-4344
 55 Hawthorne Street, 10th Floor
 San Francisco, CA  94105
From greg Wed Oct 11 10:09:46 1995
Date: Wed, 11 Oct 95 10:09:29 PDT
From: greg (Gregory J. Ward)
To: esp@sirius.com
Subject: Re:  metdata and my ignorance (clue: GDG)
Hi Erich,
I don't blame you for your confusion in the least.  I'll have to
say that those are about the most confusing units I've ever run across,
even in lighting!
Here's my logic for the conversion of 420 millicandelas/lux to the required
units of 1/steradian for the BRDF of metdata:
	420 millicandelas/lux -> 420/1000 candelas/lux
	-> .42 lumens/sr/(lumens/m^2) -> .42 m^2/sr
Note that the photometric quantities cancelled, so 420 millicandelas/lux
might as well be .42 (watts/sr)/(watts/m^2) (as long as we don't take
the spectrum into account).
Now, the metdata calculation in Radiance looks like the following:
	radiance (watts/sr/m^2) Lo = spec * cos(theta_i) * omega_i * Li * f
where:	f	= computed BRDF in 1/sr
	omega_i	= solid angle of source in sr
	Li	= avg. radiance of source in watts/sr/m^2
	theta_i	= angle between surface normal and source direction
	spec	= multiplier for specular component from material arguments
>From the above formula, the incident beam irradiance is simply:
	beam irradiance (watts/m^2) Ei = omega_i * Li
This is the quantity our SAE spec is in terms of, so our formula should
resemble the following:
	radiant intensity (watts/sr) = SAE_value * Ei
However, since Radiance never deals in units of radiant intensity, only
in units of radiance, we need to divide the radiant intensity by the
projected area in the viewing direction to get the radiance, i.e.:
	Lo = SAE_value * Ei / A_proj
where:	A_proj = A * Rdot
>From this, we can see that our BRDF is actually:
	f = SAE_value / (A * Rdot) / cos(theta_i)
It was this final cos(theta_i) that I didn't have in my original calculation,
I guess because I thought the lux value in the SAE spec was relative to the
plane of the reflector.  Thinking more on it (and you should check this), it
makes more sense that the lux is relative to the incident beam, which may be
at an angle to the reflector.
So, getting back to your original question, you can either plug the SAE values
into the data file directly (dividing each by 1000), and modify the .cal file
so that:
	sae_refl(v,x,y,z) = v / Rdot / A5 / (x*Nx+y*Ny+z*Nz) ;
Or, probably better, divide each value by the cosine of the incident angle.
Taking the table you gave me:
			0 degrees       10 degrees      20 degrees
	Observation     Entrance        Entrance        Entrance
	Angle (deg)     Angle           Angle           Angle
	0.2             420             280             140
	1.5             6                 5               3
This yields a data file of:
	0 20 3
	.2 1.5 2
	.42	.006
	.276	.0049
	.132	.0028
Just one final warning.  You should be very careful about how you analyze
the data from your calculations involving reflectors.  A simple Radiance
picture may give you correct pixel values, but these super-bright pixels
will of course flare out when they get to your eye and retina under scotopic
adaptation.  I think that's the wisdom behind using luminous intensity rather
than luminance.
As for the sheeting, you can simply remove the area condition from the
sae_refl formula in the .cal file -- i.e. take out A5.  This should do it.
Now, "Go, Dog, Go!"
From greg Wed Oct 11 10:13:18 1995
Date: Wed, 11 Oct 95 10:13:03 PDT
From: greg (Gregory J. Ward)
To: esp@sirius.com
Subject: P.S.
I forgot to mention that my original calculation could actually have been
right, but I don't have the data so I can't check whether or not I divided
by the additional cosine factor in computing those values.  Also, you really
need to find out for sure what plane the SAE lux value is measured in.
From esp@sirius.com Wed Oct 11 12:11:33 1995
Date: Wed, 11 Oct 1995 12:14:04 -0700
To: gjward@lbl.gov
From: esp@sirius.com (Erich Phillips)
Subject: Thanks and YOU WIN!!
Thank you for you e-mail.  What you are saying, believe it or not, makes
things much clearer.  I checked, and in fact the illuminance in the SAE
spec is relative to the incident beam, not the surface of the reflector.
This actually comes from the definitions of Specific Intensity (SI) and
Specific Intensity per Unit Area (SIA), as defined in Federal Test Method
Standard 370, "Instrumental Photometric Measurements of Retroreflective
Materials and Retroreflective Devices," March 1, 1977.  Not that's a
mouthful.  I found reference to this standard in a NHTSA sponsored study on
Truck Conspicuity (one of my favorite words).  If you have any interest in
the section dealing with photometry of retroreflectors, please let me know
and I would be happy to send it.
Now on to more important matters. I don't know about you, but I really
enjoy rediscovering things from my childhood through the eyes of my kids.
"GO DOG GO" is one good example.  Now, I must come up with a suitable prize
for your correct answer.   Let me think on it, and I will come up with
something guarenteed not to disappoint.  Perhaps a party hat...
Thanks again,
 Erich S. Phillips, Ph.D.            email:  esp@sirius.com
 Biophysics                          work:   (415) 597-4300
 FTI Corporation                     FAX:    (415) 597-4344
 55 Hawthorne Street, 10th Floor
 San Francisco, CA  94105

Mail requests to subscribe/cancel to:  radiance-request@radsite.lbl.gov

Back to Top of Digest Volume 2, Number 10
Return to RADIANCE Home Page
Return to RADIANCE Digests Overview

All trademarks and product names mentioned herein are the property of their registered owners.
All written material is the property of its respective contributor.
Neither the contributors nor their employers are responsible for consequences arising from any use or misuse of this information.
We make no guarantee that any of this information is correct.