Dear list,
would anybody happen to have an example of an IES file with MGF
geometry that they are happy to share? I have the latest LM-62
(2002), but it doesn't even mention MGF, and I don't seem to be able
to find an example ies file with embedded MGF.
The reason why I'm looking into this is this: I have a round bollard
light and need to generate the distribution for only the vertical
cylinder, but not the top and bottom which ies2rad generates as well.
I figure that removing the top and bottom 'rings' would invalidate the
photometry.
Many thanks
Regards
Axel
Hi Axel,
Oh wow, an MGF question. In all my years, never. Wow.
Interesting question. I'm not sure what having the MGF description will
buy you in terms of your problem. The MGF is just a geometry section
AFAIK; the photometry is still tied to the ies-format data, so I don't
think you gain any added flexibility there. Depending on how diffuse the
top and bottom of the luminaire are, you probably *could* remove the rings
and have a reasonably fair distribution for the cylinder, but I'm guessing
they are some really diffuse, blobby lenses and so you're getting some
scatter. Another option would be to generate the simple geometry with
ies2rad and then add some sort of "caps" with added geometry to the top
and bottom of the luminous geometry created from ies2rad. Not sure how
accurate the "thing" needs to look, versus the space lighted by the thing.
If you only care about the distribution, this option may work for you.
- Rob
···
On 11/5/14, 5:14 AM, "Axel Jacobs" <[email protected]> wrote:
Dear list,
would anybody happen to have an example of an IES file with MGF
geometry that they are happy to share? I have the latest LM-62
(2002), but it doesn't even mention MGF, and I don't seem to be able
to find an example ies file with embedded MGF.
The reason why I'm looking into this is this: I have a round bollard
light and need to generate the distribution for only the vertical
cylinder, but not the top and bottom which ies2rad generates as well.
I figure that removing the top and bottom 'rings' would invalidate the
photometry.
Many thanks
Regards
Axel
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi Rob,
thanks for your reply. Yes, MGF is still alive and kicking--now
officially endorsed by the IESNA as far as I understand.
The product I'm looking at is this:
http://products.iguzzini.com/iway_round
which is why I want to get rid of the top and bottom bits of the
ies2rad geometry.
What I was hoping to be able to do with MGF is tell it what the
fitting looks like. In this particular case, I'd model 3 stacked
cylinders, enclosed with a disk at the top. Only the middle cylinder
would act as an emitter. Does that make sense?
Best
Axel
···
On 5 November 2014 14:33, Guglielmetti, Robert <[email protected]> wrote:
Hi Axel,
Oh wow, an MGF question. In all my years, never. Wow.
Interesting question. I'm not sure what having the MGF description will
buy you in terms of your problem. The MGF is just a geometry section
AFAIK; the photometry is still tied to the ies-format data, so I don't
think you gain any added flexibility there. Depending on how diffuse the
top and bottom of the luminaire are, you probably *could* remove the rings
and have a reasonably fair distribution for the cylinder, but I'm guessing
they are some really diffuse, blobby lenses and so you're getting some
scatter. Another option would be to generate the simple geometry with
ies2rad and then add some sort of "caps" with added geometry to the top
and bottom of the luminous geometry created from ies2rad. Not sure how
accurate the "thing" needs to look, versus the space lighted by the thing.
If you only care about the distribution, this option may work for you.
- Rob
On 11/5/14, 5:14 AM, "Axel Jacobs" <[email protected]> wrote:
Dear list,
would anybody happen to have an example of an IES file with MGF
geometry that they are happy to share? I have the latest LM-62
(2002), but it doesn't even mention MGF, and I don't seem to be able
to find an example ies file with embedded MGF.
The reason why I'm looking into this is this: I have a round bollard
light and need to generate the distribution for only the vertical
cylinder, but not the top and bottom which ies2rad generates as well.
I figure that removing the top and bottom 'rings' would invalidate the
photometry.
Many thanks
Regards
Axel
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Do I understand that the problem is not generating geometry much taller than the actual lens, but rather that that it generates a cylinder with top and bottom circles, while only the shell of the cylinder is the actual light emitter? I had started to reply regarding adjusting the height in the IES file, but maybe someone else knows a solution for the top/bottom surface problem - which would be good to know.
···
-----Original Message-----
The product I'm looking at is this:
http://products.iguzzini.com/iway_round
which is why I want to get rid of the top and bottom bits of the
ies2rad geometry.
What I was hoping to be able to do with MGF is tell it what the
fitting looks like. In this particular case, I'd model 3 stacked
cylinders, enclosed with a disk at the top. Only the middle cylinder
would act as an emitter. Does that make sense?
Best
Axel
____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses
Ah, I "see". So you have this thing that throws down a great deal, so a
lot of the candelas toward nadir are being mapped to that bottom ring in
the ies2rad translation. My sense is that for the best result you'd want
to use the illum sphere with a large-ish radius ‹ large enough so that the
output gets mapped to points on the sphere that would fall outside the
supporting post impostor geometry, but small enough that the sphere is
high enough off the ground that the projected light looks "right".
Obviously for critical illuminance calcs you could do one run with just
the emitters (which seem to have been used in the images on the
manufacturer's website), and then for visualization you could use the
illum sphere trick, or get fancy with lboxcorr...
···
On 11/5/14, 8:14 AM, "Christopher Rush" <[email protected]> wrote:
Do I understand that the problem is not generating geometry much taller
than the actual lens, but rather that that it generates a cylinder with
top and bottom circles, while only the shell of the cylinder is the
actual light emitter? I had started to reply regarding adjusting the
height in the IES file, but maybe someone else knows a solution for the
top/bottom surface problem - which would be good to know.
-----Original Message-----
The product I'm looking at is this:
http://products.iguzzini.com/iway_round
which is why I want to get rid of the top and bottom bits of the
ies2rad geometry.
What I was hoping to be able to do with MGF is tell it what the
fitting looks like. In this particular case, I'd model 3 stacked
cylinders, enclosed with a disk at the top. Only the middle cylinder
would act as an emitter. Does that make sense?
Best
Axel
____________________________________________________________
Electronic mail messages entering and leaving Arup business
systems are scanned for acceptability of content and viruses
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi Axel,
Regarding MGF, I wasn't aware that IES ever gave it's official support to the LUMINOUSGEOMETRY tag, and I don't know of any manufacturer's that included this information. After working on the format for many months, I was rather disappointed that they declined to use it, so I'd be very happy to know otherwise. The intent of MGF was to provide detail geometry for the fixture's appearance, but it does not technically interact with the photometry. That would be handled by "imposter" geometry (an illum sphere or similar) enclosing the MGF description.
Regarding your actual problem of representing your luminous geometry as an open cylinder rather than two disks, you will need to do this by hand. The IES luminaire standard had some odd ways of specifying geometry, involving negative dimensions in the (height,width,depth) fields, and all geometry was assumed to be closed. The current source.cal file has projection calculations needed to convert candelas (as given in the IES file) to radiance (watts/sr/m^2) as needed for rendering, but only for closed cylinders. You would have to roll your own if you wanted to remove the end caps to have the correct factors in there. The current projected area is approximated as:
cylprojection = A2*A3*sqrt(1-Dz*Dz) + PI/4*A2*A2*abs(Dz);
This is only valid for far-field -- I don't have a local projection factor for cylinders in there, like I do for boxes. You probably need one in your case, but I'm not sure off-hand how to compute it. The far-field approximation for just the cylinder section would be the first term, above.
Hope this helps!
Cheers,
-Greg
···
From: Christopher Rush <[email protected]>
Subject: Re: [Radiance-general] IES files and MGF geometry
Date: November 5, 2014 7:14:18 AM PST
Do I understand that the problem is not generating geometry much taller than the actual lens, but rather that that it generates a cylinder with top and bottom circles, while only the shell of the cylinder is the actual light emitter? I had started to reply regarding adjusting the height in the IES file, but maybe someone else knows a solution for the top/bottom surface problem - which would be good to know.
++++++
From: "Guglielmetti, Robert" <[email protected]>
Subject: Re: [Radiance-general] IES files and MGF geometry
Date: November 5, 2014 7:41:17 AM PST
Ah, I "see". So you have this thing that throws down a great deal, so a
lot of the candelas toward nadir are being mapped to that bottom ring in
the ies2rad translation. My sense is that for the best result you'd want
to use the illum sphere with a large-ish radius ‹ large enough so that the
output gets mapped to points on the sphere that would fall outside the
supporting post impostor geometry, but small enough that the sphere is
high enough off the ground that the projected light looks "right".
Obviously for critical illuminance calcs you could do one run with just
the emitters (which seem to have been used in the images on the
manufacturer's website), and then for visualization you could use the
illum sphere trick, or get fancy with lboxcorr...
-----Original Message-----
The product I'm looking at is this:
http://products.iguzzini.com/iway_round
which is why I want to get rid of the top and bottom bits of the
ies2rad geometry.
What I was hoping to be able to do with MGF is tell it what the
fitting looks like. In this particular case, I'd model 3 stacked
cylinders, enclosed with a disk at the top. Only the middle cylinder
would act as an emitter. Does that make sense?
Best
Axel
Regarding MGF, I wasn't aware that IES ever gave it's official support to the LUMINOUSGEOMETRY tag,
and I don't know of any manufacturer's that included this information. After working on the format for
many months, I was rather disappointed that they declined to use it, so I'd be very happy to know otherwise.
The intent of MGF was to provide detail geometry for the fixture's appearance, but it does not technically
interact with the photometry. That would be handled by "imposter" geometry (an illum sphere or similar)
enclosing the MGF description.
I believe it was included in an early 1990s version of LM-63 (1992?), but it was not used, and removed in the
next version. 
Sympathies. I wish it had stuck; instead we are getting multiple proprietary formats, each with
their own problems.
Randolph M. Fritz
Luma
206.596.8625 d
···
-----Original Message-----
From: Greg Ward [mailto:[email protected]]
Sent: Wednesday, November 05, 2014 8:00 AM
To: Radiance general discussion
Subject: Re: [Radiance-general] IES files and MGF geometry
Hi Axel,
Regarding your actual problem of representing your luminous geometry as an open cylinder rather than two disks, you will need to do this by hand. The IES luminaire standard had some odd ways of specifying geometry, involving negative dimensions in the (height,width,depth) fields, and all geometry was assumed to be closed. The current source.cal file has projection calculations needed to convert candelas (as given in the IES file) to radiance (watts/sr/m^2) as needed for rendering, but only for closed cylinders. You would have to roll your own if you wanted to remove the end caps to have the correct factors in there. The current projected area is approximated as:
cylprojection = A2*A3*sqrt(1-Dz*Dz) + PI/4*A2*A2*abs(Dz);
This is only valid for far-field -- I don't have a local projection factor for cylinders in there, like I do for boxes. You probably need one in your case, but I'm not sure off-hand how to compute it. The far-field approximation for just the cylinder section would be the first term, above.
Hope this helps!
Cheers,
-Greg
From: Christopher Rush <[email protected]>
Subject: Re: [Radiance-general] IES files and MGF geometry
Date: November 5, 2014 7:14:18 AM PST
Do I understand that the problem is not generating geometry much taller than the actual lens, but rather that that it generates a cylinder with top and bottom circles, while only the shell of the cylinder is the actual light emitter? I had started to reply regarding adjusting the height in the IES file, but maybe someone else knows a solution for the top/bottom surface problem - which would be good to know.
++++++
From: "Guglielmetti, Robert" <[email protected]>
Subject: Re: [Radiance-general] IES files and MGF geometry
Date: November 5, 2014 7:41:17 AM PST
Ah, I "see". So you have this thing that throws down a great deal, so
a lot of the candelas toward nadir are being mapped to that bottom
ring in the ies2rad translation. My sense is that for the best result
you'd want to use the illum sphere with a large-ish radius < large
enough so that the output gets mapped to points on the sphere that
would fall outside the supporting post impostor geometry, but small
enough that the sphere is high enough off the ground that the projected light looks "right".
Obviously for critical illuminance calcs you could do one run with
just the emitters (which seem to have been used in the images on the
manufacturer's website), and then for visualization you could use the
illum sphere trick, or get fancy with lboxcorr...
-----Original Message-----
The product I'm looking at is this:
http://products.iguzzini.com/iway_round
which is why I want to get rid of the top and bottom bits of the
ies2rad geometry.
What I was hoping to be able to do with MGF is tell it what the
fitting looks like. In this particular case, I'd model 3 stacked
cylinders, enclosed with a disk at the top. Only the middle cylinder
would act as an emitter. Does that make sense?
Best
Axel
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi Greg,
I only know about this MGF embedding from the ies2rad man page, and
thought it might solve my problem:
" -i rad Ignore the crude geometry given by the IES input file and
use instead an illum
sphere with radius rad. This option may be useful
when the user wishes to add a
more accurate geometric description to the light
source model, though this need
is obviated by the recent LM-63-1995 specification,
which uses MGF detail geome-
try. (See -g option below.)"
This sounds rather more positive than the situation appears to be now. Oh well.
As you say--I would need near-field for my bollard. Thank for sending
the projection formula. With the NF-correction for boxes already in
the code, would a square bollard (again w/o bottom and top) be any
easier to describe? A square imposter is still a lot better than a
hovering crystal ball.
Many thanks
Best
Axel
···
On 5 November 2014 16:00, Greg Ward <[email protected]> wrote:
Hi Axel,
Regarding MGF, I wasn't aware that IES ever gave it's official support to the LUMINOUSGEOMETRY tag, and I don't know of any manufacturer's that included this information. After working on the format for many months, I was rather disappointed that they declined to use it, so I'd be very happy to know otherwise. The intent of MGF was to provide detail geometry for the fixture's appearance, but it does not technically interact with the photometry. That would be handled by "imposter" geometry (an illum sphere or similar) enclosing the MGF description.
Regarding your actual problem of representing your luminous geometry as an open cylinder rather than two disks, you will need to do this by hand. The IES luminaire standard had some odd ways of specifying geometry, involving negative dimensions in the (height,width,depth) fields, and all geometry was assumed to be closed. The current source.cal file has projection calculations needed to convert candelas (as given in the IES file) to radiance (watts/sr/m^2) as needed for rendering, but only for closed cylinders. You would have to roll your own if you wanted to remove the end caps to have the correct factors in there. The current projected area is approximated as:
cylprojection = A2*A3*sqrt(1-Dz*Dz) + PI/4*A2*A2*abs(Dz);
This is only valid for far-field -- I don't have a local projection factor for cylinders in there, like I do for boxes. You probably need one in your case, but I'm not sure off-hand how to compute it. The far-field approximation for just the cylinder section would be the first term, above.
Hope this helps!
Cheers,
-Greg
From: Christopher Rush <[email protected]>
Subject: Re: [Radiance-general] IES files and MGF geometry
Date: November 5, 2014 7:14:18 AM PST
Do I understand that the problem is not generating geometry much taller than the actual lens, but rather that that it generates a cylinder with top and bottom circles, while only the shell of the cylinder is the actual light emitter? I had started to reply regarding adjusting the height in the IES file, but maybe someone else knows a solution for the top/bottom surface problem - which would be good to know.
++++++
From: "Guglielmetti, Robert" <[email protected]>
Subject: Re: [Radiance-general] IES files and MGF geometry
Date: November 5, 2014 7:41:17 AM PST
Ah, I "see". So you have this thing that throws down a great deal, so a
lot of the candelas toward nadir are being mapped to that bottom ring in
the ies2rad translation. My sense is that for the best result you'd want
to use the illum sphere with a large-ish radius ‹ large enough so that the
output gets mapped to points on the sphere that would fall outside the
supporting post impostor geometry, but small enough that the sphere is
high enough off the ground that the projected light looks "right".
Obviously for critical illuminance calcs you could do one run with just
the emitters (which seem to have been used in the images on the
manufacturer's website), and then for visualization you could use the
illum sphere trick, or get fancy with lboxcorr...
-----Original Message-----
The product I'm looking at is this:
http://products.iguzzini.com/iway_round
which is why I want to get rid of the top and bottom bits of the
ies2rad geometry.
What I was hoping to be able to do with MGF is tell it what the
fitting looks like. In this particular case, I'd model 3 stacked
cylinders, enclosed with a disk at the top. Only the middle cylinder
would act as an emitter. Does that make sense?
Best
Axel
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi Axel,
Yes, as Randolph reminds me, LM-63 did have the geometry spec in there. All I remember is that it was never supported by anyone. At least we are using MGF in our XML specification for complex fenestration system BSDFs, so it's not a complete waste.
Regarding the local box correction, you could take out the third term "noneg(abs(Pz-Dz*Ts)-A4/2)*A2*A3" from the formula:
lboxprojection = ( noneg(abs(Px-Dx*Ts)-A2/2)*A3*A4 +
noneg(abs(Py-Dy*Ts)-A3/2)*A2*A4 +
noneg(abs(Pz-Dz*Ts)-A4/2)*A2*A3 ) / Ts;
I think that should work.
Cheers,
-Greg
···
From: Axel Jacobs <[email protected]>
Subject: Re: [Radiance-general] IES files and MGF geometry
Date: November 5, 2014 8:57:01 AM PST
Hi Greg,
I only know about this MGF embedding from the ies2rad man page, and
thought it might solve my problem:
" -i rad Ignore the crude geometry given by the IES input file and
use instead an illum
sphere with radius rad. This option may be useful
when the user wishes to add a
more accurate geometric description to the light
source model, though this need
is obviated by the recent LM-63-1995 specification,
which uses MGF detail geome-
try. (See -g option below.)"
This sounds rather more positive than the situation appears to be now. Oh well.
As you say--I would need near-field for my bollard. Thank for sending
the projection formula. With the NF-correction for boxes already in
the code, would a square bollard (again w/o bottom and top) be any
easier to describe? A square imposter is still a lot better than a
hovering crystal ball.
Many thanks
Best
Axel
Thanks, Greg. Will give this a try.
Best
Axel
···
On 5 November 2014 17:04, Greg Ward <[email protected]> wrote:
Hi Axel,
Yes, as Randolph reminds me, LM-63 did have the geometry spec in there. All I remember is that it was never supported by anyone. At least we are using MGF in our XML specification for complex fenestration system BSDFs, so it's not a complete waste.
Regarding the local box correction, you could take out the third term "noneg(abs(Pz-Dz*Ts)-A4/2)*A2*A3" from the formula:
lboxprojection = ( noneg(abs(Px-Dx*Ts)-A2/2)*A3*A4 +
noneg(abs(Py-Dy*Ts)-A3/2)*A2*A4 +
noneg(abs(Pz-Dz*Ts)-A4/2)*A2*A3 ) / Ts;
I think that should work.
Cheers,
-Greg
From: Axel Jacobs <[email protected]>
Subject: Re: [Radiance-general] IES files and MGF geometry
Date: November 5, 2014 8:57:01 AM PST
Hi Greg,
I only know about this MGF embedding from the ies2rad man page, and
thought it might solve my problem:
" -i rad Ignore the crude geometry given by the IES input file and
use instead an illum
sphere with radius rad. This option may be useful
when the user wishes to add a
more accurate geometric description to the light
source model, though this need
is obviated by the recent LM-63-1995 specification,
which uses MGF detail geome-
try. (See -g option below.)"
This sounds rather more positive than the situation appears to be now. Oh well.
As you say--I would need near-field for my bollard. Thank for sending
the projection formula. With the NF-correction for boxes already in
the code, would a square bollard (again w/o bottom and top) be any
easier to describe? A square imposter is still a lot better than a
hovering crystal ball.
Many thanks
Best
Axel
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hello again,
I've run some quick tests on with my bollard photometry. falsecolor
images below:
Unaltered IES file as it came from the manufacturer:
http://www.jaloxa.eu/pickup/mr84_li34_fc.jpg
This uses a short, capped cylinder. rvu complains about
"source aspect too small for cylinder xxx
aiming failure for light source xxx"
Looks weird.
sphere, generated with ies2rad's -i option:
http://www.jaloxa.eu/pickup/mr84_li34_sphere_fc.jpg
This is a little darker than the previous image.
box geometry with all 6 sides (edited IES file):
http://www.jaloxa.eu/pickup/mr84_li34_closed_box_fc.jpg
some 'streaky' artifacts that didn't show up in the sphere image.
box with top and bottom removed. Unaltered source.cal
http://www.jaloxa.eu/pickup/mr84_li34_open_box_fc.jpg
a little darker than the full box
box with top and bottom removed. source.cal edited as per Greg's instructions
http://www.jaloxa.eu/pickup/mr84_li34_open_box_fixed_fc.jpg
Looks identical to the previous picture.
I used the new ltview command for the previews, so the lower side of
the enclosing plane is much further away than the actual ground would
be. This might be the reason why the 'corrected' and 'uncorrected'
open boxes produce the same results. Equally, there is hardly any
downward or upward component. Virtually all of the emitted light is
projected into a narrow strip. It still seems as if the open box does
emit a little less light than its closed brother, even with the
correction in source.cal
Best
Axel
···
On 5 November 2014 17:19, Axel Jacobs <[email protected]> wrote:
Thanks, Greg. Will give this a try.
Best
Axel
On 5 November 2014 17:04, Greg Ward <[email protected]> wrote:
Hi Axel,
Yes, as Randolph reminds me, LM-63 did have the geometry spec in there. All I remember is that it was never supported by anyone. At least we are using MGF in our XML specification for complex fenestration system BSDFs, so it's not a complete waste.
Regarding the local box correction, you could take out the third term "noneg(abs(Pz-Dz*Ts)-A4/2)*A2*A3" from the formula:
lboxprojection = ( noneg(abs(Px-Dx*Ts)-A2/2)*A3*A4 +
noneg(abs(Py-Dy*Ts)-A3/2)*A2*A4 +
noneg(abs(Pz-Dz*Ts)-A4/2)*A2*A3 ) / Ts;
I think that should work.
Cheers,
-Greg
From: Axel Jacobs <[email protected]>
Subject: Re: [Radiance-general] IES files and MGF geometry
Date: November 5, 2014 8:57:01 AM PST
Hi Greg,
I only know about this MGF embedding from the ies2rad man page, and
thought it might solve my problem:
" -i rad Ignore the crude geometry given by the IES input file and
use instead an illum
sphere with radius rad. This option may be useful
when the user wishes to add a
more accurate geometric description to the light
source model, though this need
is obviated by the recent LM-63-1995 specification,
which uses MGF detail geome-
try. (See -g option below.)"
This sounds rather more positive than the situation appears to be now. Oh well.
As you say--I would need near-field for my bollard. Thank for sending
the projection formula. With the NF-correction for boxes already in
the code, would a square bollard (again w/o bottom and top) be any
easier to describe? A square imposter is still a lot better than a
hovering crystal ball.
Many thanks
Best
Axel
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hi Axel,
Interesting results. The correction of removing the third term for the local box correction would make the most difference in the upwards and downwards direction, so the sparse output there is why you don't see anything in your falsecolor comparison. You could try computing a difference image using src/cal/cal/picdiff.cal.
Also, the differences between using a large sphere and the lboxcorr won't be noticeable until your surfaces are up close. What did you set -dj to in your runs? This will also make a difference, and could show up artifacts in some of the simpler methods.
Cheers,
-Greg
···
From: Axel Jacobs <[email protected]>
Subject: Re: [Radiance-general] IES files and MGF geometry
Date: November 6, 2014 3:02:26 AM PST
Hello again,
I've run some quick tests on with my bollard photometry. falsecolor
images below:
Unaltered IES file as it came from the manufacturer:
http://www.jaloxa.eu/pickup/mr84_li34_fc.jpg
This uses a short, capped cylinder. rvu complains about
"source aspect too small for cylinder xxx
aiming failure for light source xxx"
Looks weird.
sphere, generated with ies2rad's -i option:
http://www.jaloxa.eu/pickup/mr84_li34_sphere_fc.jpg
This is a little darker than the previous image.
box geometry with all 6 sides (edited IES file):
http://www.jaloxa.eu/pickup/mr84_li34_closed_box_fc.jpg
some 'streaky' artifacts that didn't show up in the sphere image.
box with top and bottom removed. Unaltered source.cal
http://www.jaloxa.eu/pickup/mr84_li34_open_box_fc.jpg
a little darker than the full box
box with top and bottom removed. source.cal edited as per Greg's instructions
http://www.jaloxa.eu/pickup/mr84_li34_open_box_fixed_fc.jpg
Looks identical to the previous picture.
I used the new ltview command for the previews, so the lower side of
the enclosing plane is much further away than the actual ground would
be. This might be the reason why the 'corrected' and 'uncorrected'
open boxes produce the same results. Equally, there is hardly any
downward or upward component. Virtually all of the emitted light is
projected into a narrow strip. It still seems as if the open box does
emit a little less light than its closed brother, even with the
correction in source.cal
Best
Axel
Hi Greg,
the -dj is set by the rad command, which is behind ltview.
render= -av 0 0 0
INDIRECT= 0
QUALITY= Med
DETAIL= Low
VARIABILITY= Med
http://radiance-online.org/cgi-bin/viewcvs.cgi/ray/src/util/ltview.pl?view=markup
I was also thinking whether or not the intensity of the actual 'light'
material, as created by ies2rad, should be modified since the total
surface area is smaller with the top and bottom of the box removed.
But then, I guess you would have mentioned this.
I will re-run the images with rpict proper and do a diff, but won't be
able to do this until early next week.
Thank you for your help
Best
Axel
···
On 6 November 2014 15:52, Greg Ward <[email protected]> wrote:
Hi Axel,
Interesting results. The correction of removing the third term for the local box correction would make the most difference in the upwards and downwards direction, so the sparse output there is why you don't see anything in your falsecolor comparison. You could try computing a difference image using src/cal/cal/picdiff.cal.
Also, the differences between using a large sphere and the lboxcorr won't be noticeable until your surfaces are up close. What did you set -dj to in your runs? This will also make a difference, and could show up artifacts in some of the simpler methods.
Cheers,
-Greg
From: Axel Jacobs <[email protected]>
Subject: Re: [Radiance-general] IES files and MGF geometry
Date: November 6, 2014 3:02:26 AM PST
Hello again,
I've run some quick tests on with my bollard photometry. falsecolor
images below:
Unaltered IES file as it came from the manufacturer:
http://www.jaloxa.eu/pickup/mr84_li34_fc.jpg
This uses a short, capped cylinder. rvu complains about
"source aspect too small for cylinder xxx
aiming failure for light source xxx"
Looks weird.
sphere, generated with ies2rad's -i option:
http://www.jaloxa.eu/pickup/mr84_li34_sphere_fc.jpg
This is a little darker than the previous image.
box geometry with all 6 sides (edited IES file):
http://www.jaloxa.eu/pickup/mr84_li34_closed_box_fc.jpg
some 'streaky' artifacts that didn't show up in the sphere image.
box with top and bottom removed. Unaltered source.cal
http://www.jaloxa.eu/pickup/mr84_li34_open_box_fc.jpg
a little darker than the full box
box with top and bottom removed. source.cal edited as per Greg's instructions
http://www.jaloxa.eu/pickup/mr84_li34_open_box_fixed_fc.jpg
Looks identical to the previous picture.
I used the new ltview command for the previews, so the lower side of
the enclosing plane is much further away than the actual ground would
be. This might be the reason why the 'corrected' and 'uncorrected'
open boxes produce the same results. Equally, there is hardly any
downward or upward component. Virtually all of the emitted light is
projected into a narrow strip. It still seems as if the open box does
emit a little less light than its closed brother, even with the
correction in source.cal
Best
Axel
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
Hello again,
As promised, here are some more images of my box bollard. Definitions first:
'closed' ... actual 6-sided box, as generated by ie2rad
'open' ... the above, with the top and bottom removed
'open_fixed' ... the above, with a modified source.cal
The light sources in a test room:
http://www.jaloxa.eu/pickup/closed_box_f.jpg
http://www.jaloxa.eu/pickup/open_box_f.jpg
http://www.jaloxa.eu/pickup/open_box_fixed_f.jpg
There is no noticeable difference between 'open' and 'open_fixed'.
Both are slightly different to 'closed'.
Diff images:
$ pcomb -f picdiff.cal closed_box.hdr open_box_fixed.hdr \
> closed_v_fixed.hdr
etc
http://www.jaloxa.eu/pickup/closed_v_fixed_f.jpg
http://www.jaloxa.eu/pickup/closed_v_open_f.jpg
http://www.jaloxa.eu/pickup/open_v_fixed_f.jpg
'closed_v_open' and 'closed_v_fixed' are identical. The reason for
this might be that practically all of the light is emitted side-ways,
so that removing the top and bottom of the box makes no difference at
all. Equally, fiddling with source.cal as per Greg's advice
"Regarding the local box correction, you could take out the third term
"noneg(abs(Pz-Dz*Ts)-A4/2)*A2*A3" from the formula:
lboxprojection = ( noneg(abs(Px-Dx*Ts)-A2/2)*A3*A4 +
noneg(abs(Py-Dy*Ts)-A3/2)*A2*A4 +
noneg(abs(Pz-Dz*Ts)-A4/2)*A2*A3 ) / Ts;"
seemed to give identical results.
Not sure if this provides a general answer to my question, but in my
particular case, it appears to be safe to reduce the box to its four
sides, which probably only works because of the very special
photometry.
Best
Axel
···
On 06/11/14 16:42, Axel Jacobs wrote:
Hi Greg,
the -dj is set by the rad command, which is behind ltview.
render= -av 0 0 0
INDIRECT= 0
QUALITY= Med
DETAIL= Low
VARIABILITY= Med
http://radiance-online.org/cgi-bin/viewcvs.cgi/ray/src/util/ltview.pl?view=markup
I was also thinking whether or not the intensity of the actual 'light'
material, as created by ies2rad, should be modified since the total
surface area is smaller with the top and bottom of the box removed.
But then, I guess you would have mentioned this.
I will re-run the images with rpict proper and do a diff, but won't be
able to do this until early next week.
Thank you for your help
Best
Axel
On 6 November 2014 15:52, Greg Ward <[email protected]> wrote:
Hi Axel,
Interesting results. The correction of removing the third term for the local box correction would make the most difference in the upwards and downwards direction, so the sparse output there is why you don't see anything in your falsecolor comparison. You could try computing a difference image using src/cal/cal/picdiff.cal.
Also, the differences between using a large sphere and the lboxcorr won't be noticeable until your surfaces are up close. What did you set -dj to in your runs? This will also make a difference, and could show up artifacts in some of the simpler methods.
Cheers,
-Greg
From: Axel Jacobs <[email protected]>
Subject: Re: [Radiance-general] IES files and MGF geometry
Date: November 6, 2014 3:02:26 AM PST
Hello again,
I've run some quick tests on with my bollard photometry. falsecolor
images below:
Unaltered IES file as it came from the manufacturer:
http://www.jaloxa.eu/pickup/mr84_li34_fc.jpg
This uses a short, capped cylinder. rvu complains about
"source aspect too small for cylinder xxx
aiming failure for light source xxx"
Looks weird.
sphere, generated with ies2rad's -i option:
http://www.jaloxa.eu/pickup/mr84_li34_sphere_fc.jpg
This is a little darker than the previous image.
box geometry with all 6 sides (edited IES file):
http://www.jaloxa.eu/pickup/mr84_li34_closed_box_fc.jpg
some 'streaky' artifacts that didn't show up in the sphere image.
box with top and bottom removed. Unaltered source.cal
http://www.jaloxa.eu/pickup/mr84_li34_open_box_fc.jpg
a little darker than the full box
box with top and bottom removed. source.cal edited as per Greg's instructions
http://www.jaloxa.eu/pickup/mr84_li34_open_box_fixed_fc.jpg
Looks identical to the previous picture.
I used the new ltview command for the previews, so the lower side of
the enclosing plane is much further away than the actual ground would
be. This might be the reason why the 'corrected' and 'uncorrected'
open boxes produce the same results. Equally, there is hardly any
downward or upward component. Virtually all of the emitted light is
projected into a narrow strip. It still seems as if the open box does
emit a little less light than its closed brother, even with the
correction in source.cal
Best
Axel
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
