genskyvec with HDR sky view?

[Achim_Geissler]

Hi all,

after searching high and low without clear results apart from a lot of pointers that “everybody seems to be doing it” (so it should actually be easy and I am probably missing the forest due to seeing trees, as they say) a short question: The goal is to use HDR (fisheye) views of the sky for radiance calculations. All I could manage to date are pretty pictures with HDR skies. Ideally, the workflow would be “the same” as when using a sky from gensky or gendaylit. E.g., it would be nice to be able to generate the sky vectors (genskyvec) from the HDR sky view. Is that possible? How? Trying to simply pipe a sky definition along the lines of

void colorpict skyfunc_hdr
7 red green blue sky_image.hdr map_sky.cal u v
0
0

skyfunc_hdr glow sky_glow_hdr
0
0
4 1 1 1 0

sky_glow_hdr source sky_hdr
0
0
4 0 0 1 180

into genskyvec didn’t work - well, would have been too simple (the map_sky.cal is from the PhD by Coralie Cauwerts, 2013). The following approaches resulted in the “pretty pictures” (replacing “source” above)

sky_glow_hdr bubble sky_hdr
0
0
4 0 0 0 2000

or

!genbox sky_glow_hdr boxenv 2000 2000 1000 -i | xform -t -1000 -1000 -500

A further topic will be a “calibration” of the HDR sky views - we have global horizontal and diffuse horizontal radiation values available. The current idea of a (possibly slightly rough) method of calibration would be to use the HDR sky to calculate the corresponding sensor value with radiance and “somehow” introduce a scaling factor into the HDR sky such that the measured and calculated global horizontal radiation values tally.

Thanks for any hints & ideas!

Best
Achim

[email protected]

[Greg_Ward]

Hi Achim,

I wouldn't call what you are trying to do "easy," even if others have done it. Your HDR file has to be in the correct units or scaled by the right amount to get calibrated radiance values, and even then, the sun is usually out of range(clipped) and won't be properly sampled if it is a clear sky.

As you noted, such a sky cannot be given as input to genskyvec, which expects a very specific set of primitives output by gensky or gendaylit. Specifically, you need to name your colorpict pattern "skyfunc" and add a solar source if the sky is sunny. You could try to modify your description to match, but you'd have to look at the Perl script src/util/genskyvec.pl to figure out how to satisfy the input requirements.

Once you have a sky description, you can use rtrace with the -I option to compute hemispherical irradiance, from which you can create an adjustment factor to apply to your glow based on horizontal irradiance.

It's all possible, but the details are not very straightforward.

Best,
-Greg

···

From: Achim Geissler <[email protected]>
Date: May 27, 2016 12:29:35 PM PDT

Hi all,

after searching high and low without clear results apart from a lot of pointers that “everybody seems to be doing it” (so it should actually be easy and I am probably missing the forest due to seeing trees, as they say) a short question: The goal is to use HDR (fisheye) views of the sky for radiance calculations. All I could manage to date are pretty pictures with HDR skies. Ideally, the workflow would be “the same” as when using a sky from gensky or gendaylit. E.g., it would be nice to be able to generate the sky vectors (genskyvec) from the HDR sky view. Is that possible? How? Trying to simply pipe a sky definition along the lines of

void colorpict skyfunc_hdr
7 red green blue sky_image.hdr map_sky.cal u v
0
0

skyfunc_hdr glow sky_glow_hdr
0
0
4 1 1 1 0

sky_glow_hdr source sky_hdr
0
0
4 0 0 1 180

into genskyvec didn’t work - well, would have been too simple (the map_sky.cal is from the PhD by Coralie Cauwerts, 2013). The following approaches resulted in the “pretty pictures” (replacing “source” above)

sky_glow_hdr bubble sky_hdr
0
0
4 0 0 0 2000

or

!genbox sky_glow_hdr boxenv 2000 2000 1000 -i | xform -t -1000 -1000 -500

A further topic will be a “calibration” of the HDR sky views - we have global horizontal and diffuse horizontal radiation values available. The current idea of a (possibly slightly rough) method of calibration would be to use the HDR sky to calculate the corresponding sensor value with radiance and “somehow” introduce a scaling factor into the HDR sky such that the measured and calculated global horizontal radiation values tally.

Thanks for any hints & ideas!

Best
Achim

[email protected]

[Achim_Geissler]

Hi Greg,

thanks for the pointers. I am afraid, though, that I was unable to really
make heads or tails of them.
a) HDR file (Photosphere)
  i, the (test) HDR gives min/max values in falsecolor view of 39 to
2900, whatever the unit, there
  ii, it gives histogram min/max values for Luminance of 34.8 to
4.43E+06
  iii, it does not seem to be clipped
b) There is a sun (albeit behind a thin cloud cover). Simply adding a sun
definition to my sky description did not really change anything, though.
Also, at this point I do not know which r,g,b radiance values to use for the
solar "light" material and do these influence the result? And, actually, how
to exactly position the HDR so that the sun positions tally.
c) I took a look at the genskyvec.pl script, however, I am not perl-literate
so that is a bit difficult. I seem to be missing out on where this script

could< use values from the HDR file to generate the sky vectors. Part of

the code seems to be a copy of the setting up of patches from reinhart.cal.
Also, the "skyfunc glow skyglow" and "skyglow source sky" are written to the
(an) octree in the script. Can I ignore that? Or does that let me leave
these definitions out of my sky description? Which definition has precedent?
I can't really see where the "skybright.cal" values from a standard gensky
sky would come into play - this should be what is replaced by values from
the HDR?
d) using the sky description as below but with "skyfunc" gives
rpict: warning - compute error for colorpict "skyfunc"
rpict: Division by zero
when trying to generate a view of a scene.

I must admit the flow of data (input / output) in all the definitions is a
bit of a mystery, for me. I did find a kind of description for colorpict in
p_data.c, but that didn't really help, sadly. Looking at your code, I get
the feeling I am not literate in any programming language ... :o(

If you (or, of course, anyone else out there that has done this before) can
give any further help or tips, it would be much appreciated.

Best
Achim

···

-----Ursprüngliche Nachricht-----
Von: Greg Ward [mailto:[email protected]]
Gesendet: Samstag, 28. Mai 2016 01:27
An: Radiance general discussion
Betreff: Re: [Radiance-general] genskyvec with HDR sky view?

Hi Achim,

I wouldn't call what you are trying to do "easy," even if others have done
it. Your HDR file has to be in the correct units or scaled by the right
amount to get calibrated radiance values, and even then, the sun is usually
out of range(clipped) and won't be properly sampled if it is a clear sky.

As you noted, such a sky cannot be given as input to genskyvec, which
expects a very specific set of primitives output by gensky or gendaylit.
Specifically, you need to name your colorpict pattern "skyfunc" and add a
solar source if the sky is sunny. You could try to modify your description
to match, but you'd have to look at the Perl script src/util/genskyvec.pl to
figure out how to satisfy the input requirements.

Once you have a sky description, you can use rtrace with the -I option to
compute hemispherical irradiance, from which you can create an adjustment
factor to apply to your glow based on horizontal irradiance.

It's all possible, but the details are not very straightforward.

Best,
-Greg

From: Achim Geissler <[email protected]>
Date: May 27, 2016 12:29:35 PM PDT

Hi all,

after searching high and low without clear results apart from a lot of

pointers that “everybody seems to be doing it” (so it should actually be
easy and I am probably missing the forest due to seeing trees, as they say)
a short question: The goal is to use HDR (fisheye) views of the sky for
radiance calculations. All I could manage to date are pretty pictures with
HDR skies. Ideally, the workflow would be “the same” as when using a sky
from gensky or gendaylit. E.g., it would be nice to be able to generate the
sky vectors (genskyvec) from the HDR sky view. Is that possible? How? Trying
to simply pipe a sky definition along the lines of

void colorpict skyfunc_hdr
7 red green blue sky_image.hdr map_sky.cal u v
0
0

skyfunc_hdr glow sky_glow_hdr
0
0
4 1 1 1 0

sky_glow_hdr source sky_hdr
0
0
4 0 0 1 180

into genskyvec didn’t work - well, would have been too simple (the

map_sky.cal is from the PhD by Coralie Cauwerts, 2013). The following
approaches resulted in the “pretty pictures” (replacing “source” above)

sky_glow_hdr bubble sky_hdr
0
0
4 0 0 0 2000

or

!genbox sky_glow_hdr boxenv 2000 2000 1000 -i | xform -t -1000 -1000 -500

A further topic will be a “calibration” of the HDR sky views - we have

global horizontal and diffuse horizontal radiation values available. The
current idea of a (possibly slightly rough) method of calibration would be
to use the HDR sky to calculate the corresponding sensor value with radiance
and “somehow” introduce a scaling factor into the HDR sky such that the
measured and calculated global horizontal radiation values tally.

Thanks for any hints & ideas!

Best
Achim

[email protected]

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

[Greg_Ward]

Hi Achim,

I'll answer inline again, making a bad formatting job look even worse....

From: "Achim Geissler" <[email protected]>
Date: May 30, 2016 8:05:25 AM PDT

Hi Greg,

thanks for the pointers. I am afraid, though, that I was unable to really
make heads or tails of them.
a) HDR file (Photosphere)
  i, the (test) HDR gives min/max values in falsecolor view of 39 to
2900, whatever the unit, there
  ii, it gives histogram min/max values for Luminance of 34.8 to
4.43E+06
  iii, it does not seem to be clipped

I don't know what (i), (ii) and (iii) refer to, if anything. Are these particular processes you have tried? If so, what are they?

Typically, falsecolor and Photosphere report photometric values (i.e., radiance values times 179 lumens/watt efficacy).

b) There is a sun (albeit behind a thin cloud cover). Simply adding a sun
definition to my sky description did not really change anything, though.
Also, at this point I do not know which r,g,b radiance values to use for the
solar "light" material and do these influence the result? And, actually, how
to exactly position the HDR so that the sun positions tally.

If you have your sky turned the right way around, so that the Z-axis points up, Y-axis points north, and X-axis points east, then positioning the sun is a matter of running gensky with the appropriate date/time and global position parameters, and extracting the description it generates. You can adjust the solar radiance values to match the global-diffuse measured that day using the -R option to gensky.

c) I took a look at the genskyvec.pl script, however, I am not perl-literate
so that is a bit difficult. I seem to be missing out on where this script >could<
use values from the HDR file to generate the sky vectors. Part of
the code seems to be a copy of the setting up of patches from reinhart.cal.
Also, the "skyfunc glow skyglow" and "skyglow source sky" are written to the
(an) octree in the script. Can I ignore that? Or does that let me leave
these definitions out of my sky description? Which definition has precedent?
I can't really see where the "skybright.cal" values from a standard gensky
sky would come into play - this should be what is replaced by values from
the HDR?

I'm not suggesting you rewrite genskyvec. Rather, I'm suggesting that you prepare a sky file it will accept and run it on that file. If this doesn't make sense, then I suggest you give up.

d) using the sky description as below but with "skyfunc" gives
rpict: warning - compute error for colorpict "skyfunc"
rpict: Division by zero
when trying to generate a view of a scene.

I don't know why globally replacing "skyfunc_hdr" with "skyfunc" in your file should cause new errors. You must have done something else, or the original run would have generated the same errors. I don't know what's in "map_sky.cal", which is the likely cause.

I must admit the flow of data (input / output) in all the definitions is a
bit of a mystery, for me. I did find a kind of description for colorpict in
p_data.c, but that didn't really help, sadly. Looking at your code, I get
the feeling I am not literate in any programming language ... :o(

Well, it's not particularly transparent, I will grant you. There's this back-and-forth between the ray tracing and the scene description, such that when a material is intersected, it queries its modifiers, which calls back to your map_sky.cal file in a rather convoluted fashion.

You should look through Chapter 4 of "Rendering with Radiance." Starting at Section 4.1.4, we talk about how the interaction between rendering and .cal files operates.

···

If you (or, of course, anyone else out there that has done this before) can
give any further help or tips, it would be much appreciated.

Best
Achim

-----Ursprüngliche Nachricht-----
Von: Greg Ward [mailto:[email protected]]
Gesendet: Samstag, 28. Mai 2016 01:27
An: Radiance general discussion
Betreff: Re: [Radiance-general] genskyvec with HDR sky view?

Hi Achim,

I wouldn't call what you are trying to do "easy," even if others have done
it. Your HDR file has to be in the correct units or scaled by the right
amount to get calibrated radiance values, and even then, the sun is usually
out of range(clipped) and won't be properly sampled if it is a clear sky.

As you noted, such a sky cannot be given as input to genskyvec, which
expects a very specific set of primitives output by gensky or gendaylit.
Specifically, you need to name your colorpict pattern "skyfunc" and add a
solar source if the sky is sunny. You could try to modify your description
to match, but you'd have to look at the Perl script src/util/genskyvec.pl to
figure out how to satisfy the input requirements.

Once you have a sky description, you can use rtrace with the -I option to
compute hemispherical irradiance, from which you can create an adjustment
factor to apply to your glow based on horizontal irradiance.

It's all possible, but the details are not very straightforward.

Best,
-Greg

From: Achim Geissler <[email protected]>
Date: May 27, 2016 12:29:35 PM PDT

Hi all,

after searching high and low without clear results apart from a lot of

pointers that “everybody seems to be doing it” (so it should actually be
easy and I am probably missing the forest due to seeing trees, as they say)
a short question: The goal is to use HDR (fisheye) views of the sky for
radiance calculations. All I could manage to date are pretty pictures with
HDR skies. Ideally, the workflow would be “the same” as when using a sky
from gensky or gendaylit. E.g., it would be nice to be able to generate the
sky vectors (genskyvec) from the HDR sky view. Is that possible? How? Trying
to simply pipe a sky definition along the lines of

void colorpict skyfunc_hdr
7 red green blue sky_image.hdr map_sky.cal u v
0
0

skyfunc_hdr glow sky_glow_hdr
0
0
4 1 1 1 0

sky_glow_hdr source sky_hdr
0
0
4 0 0 1 180

into genskyvec didn’t work - well, would have been too simple (the

map_sky.cal is from the PhD by Coralie Cauwerts, 2013). The following
approaches resulted in the “pretty pictures” (replacing “source” above)

sky_glow_hdr bubble sky_hdr
0
0
4 0 0 0 2000

or

!genbox sky_glow_hdr boxenv 2000 2000 1000 -i | xform -t -1000 -1000 -500

A further topic will be a “calibration” of the HDR sky views - we have

global horizontal and diffuse horizontal radiation values available. The
current idea of a (possibly slightly rough) method of calibration would be
to use the HDR sky to calculate the corresponding sensor value with radiance
and “somehow” introduce a scaling factor into the HDR sky such that the
measured and calculated global horizontal radiation values tally.

Thanks for any hints & ideas!

Best
Achim

[email protected]

[Andrew_McNeil]

> d) using the sky description as below but with "skyfunc" gives
> rpict: warning - compute error for colorpict "skyfunc"
> rpict: Division by zero
> when trying to generate a view of a scene.
I don't know why globally replacing "skyfunc_hdr" with "skyfunc" in your
file should cause new errors. You must have done something else, or the
original run would have generated the same errors. I don't know what's in
"map_sky.cal", which is the likely cause.

Maybe this has something to do with your image only being 180 degrees and
genskyvec creating a 360 degree source?
I'd suggest testing by temporarily changing line 120 of genkskyvec.pl from:
print OCONV "skyglow source sky 0 0 4 0 0 1 360\n";

to:
print OCONV "skyglow source sky 0 0 4 0 0 1 180\n";

If this works your ground patch will be zero, so you'll have to do
something about that.

Andy

···

On Tue, May 31, 2016 at 3:17 PM, Greg Ward <[email protected]> wrote:

Hi Achim,

I'll answer inline again, making a bad formatting job look even worse....

> From: "Achim Geissler" <[email protected]>
> Date: May 30, 2016 8:05:25 AM PDT
>
> Hi Greg,
>
> thanks for the pointers. I am afraid, though, that I was unable to really
> make heads or tails of them.
> a) HDR file (Photosphere)
> i, the (test) HDR gives min/max values in falsecolor view of 39 to
> 2900, whatever the unit, there
> ii, it gives histogram min/max values for Luminance of 34.8 to
> 4.43E+06
> iii, it does not seem to be clipped

I don't know what (i), (ii) and (iii) refer to, if anything. Are these
particular processes you have tried? If so, what are they?

Typically, falsecolor and Photosphere report photometric values (i.e.,
radiance values times 179 lumens/watt efficacy).

> b) There is a sun (albeit behind a thin cloud cover). Simply adding a sun
> definition to my sky description did not really change anything, though.
> Also, at this point I do not know which r,g,b radiance values to use for
the
> solar "light" material and do these influence the result? And, actually,
how
> to exactly position the HDR so that the sun positions tally.

If you have your sky turned the right way around, so that the Z-axis
points up, Y-axis points north, and X-axis points east, then positioning
the sun is a matter of running gensky with the appropriate date/time and
global position parameters, and extracting the description it generates.
You can adjust the solar radiance values to match the global-diffuse
measured that day using the -R option to gensky.

> c) I took a look at the genskyvec.pl script, however, I am not
perl-literate
> so that is a bit difficult. I seem to be missing out on where this
script >could<
> use values from the HDR file to generate the sky vectors. Part of
> the code seems to be a copy of the setting up of patches from
reinhart.cal.
> Also, the "skyfunc glow skyglow" and "skyglow source sky" are written to
the
> (an) octree in the script. Can I ignore that? Or does that let me leave
> these definitions out of my sky description? Which definition has
precedent?
> I can't really see where the "skybright.cal" values from a standard
gensky
> sky would come into play - this should be what is replaced by values from
> the HDR?

I'm not suggesting you rewrite genskyvec. Rather, I'm suggesting that you
prepare a sky file it will accept and run it on that file. If this doesn't
make sense, then I suggest you give up.

> d) using the sky description as below but with "skyfunc" gives
> rpict: warning - compute error for colorpict "skyfunc"
> rpict: Division by zero
> when trying to generate a view of a scene.

I don't know why globally replacing "skyfunc_hdr" with "skyfunc" in your
file should cause new errors. You must have done something else, or the
original run would have generated the same errors. I don't know what's in
"map_sky.cal", which is the likely cause.

> I must admit the flow of data (input / output) in all the definitions is
a
> bit of a mystery, for me. I did find a kind of description for colorpict
in
> p_data.c, but that didn't really help, sadly. Looking at your code, I get
> the feeling I am not literate in any programming language ... :o(

Well, it's not particularly transparent, I will grant you. There's this
back-and-forth between the ray tracing and the scene description, such that
when a material is intersected, it queries its modifiers, which calls back
to your map_sky.cal file in a rather convoluted fashion.

You should look through Chapter 4 of "Rendering with Radiance." Starting
at Section 4.1.4, we talk about how the interaction between rendering and
.cal files operates.

> If you (or, of course, anyone else out there that has done this before)
can
> give any further help or tips, it would be much appreciated.
>
> Best
> Achim
>
>
> -----Ursprüngliche Nachricht-----
> Von: Greg Ward [mailto:[email protected]]
> Gesendet: Samstag, 28. Mai 2016 01:27
> An: Radiance general discussion
> Betreff: Re: [Radiance-general] genskyvec with HDR sky view?
>
> Hi Achim,
>
> I wouldn't call what you are trying to do "easy," even if others have
done
> it. Your HDR file has to be in the correct units or scaled by the right
> amount to get calibrated radiance values, and even then, the sun is
usually
> out of range(clipped) and won't be properly sampled if it is a clear sky.
>
> As you noted, such a sky cannot be given as input to genskyvec, which
> expects a very specific set of primitives output by gensky or gendaylit.
> Specifically, you need to name your colorpict pattern "skyfunc" and add a
> solar source if the sky is sunny. You could try to modify your
description
> to match, but you'd have to look at the Perl script src/util/
genskyvec.pl to
> figure out how to satisfy the input requirements.
>
> Once you have a sky description, you can use rtrace with the -I option to
> compute hemispherical irradiance, from which you can create an adjustment
> factor to apply to your glow based on horizontal irradiance.
>
> It's all possible, but the details are not very straightforward.
>
> Best,
> -Greg
>
>> From: Achim Geissler <[email protected]>
>> Date: May 27, 2016 12:29:35 PM PDT
>>
>> Hi all,
>>
>> after searching high and low without clear results apart from a lot of
> pointers that “everybody seems to be doing it” (so it should actually be
> easy and I am probably missing the forest due to seeing trees, as they
say)
> a short question: The goal is to use HDR (fisheye) views of the sky for
> radiance calculations. All I could manage to date are pretty pictures
with
> HDR skies. Ideally, the workflow would be “the same” as when using a sky
> from gensky or gendaylit. E.g., it would be nice to be able to generate
the
> sky vectors (genskyvec) from the HDR sky view. Is that possible? How?
Trying
> to simply pipe a sky definition along the lines of
>>
>> void colorpict skyfunc_hdr
>> 7 red green blue sky_image.hdr map_sky.cal u v
>> 0
>> 0
>>
>> skyfunc_hdr glow sky_glow_hdr
>> 0
>> 0
>> 4 1 1 1 0
>>
>> sky_glow_hdr source sky_hdr
>> 0
>> 0
>> 4 0 0 1 180
>>
>> into genskyvec didn’t work - well, would have been too simple (the
> map_sky.cal is from the PhD by Coralie Cauwerts, 2013). The following
> approaches resulted in the “pretty pictures” (replacing “source” above)
>>
>> sky_glow_hdr bubble sky_hdr
>> 0
>> 0
>> 4 0 0 0 2000
>>
>> or
>>
>> !genbox sky_glow_hdr boxenv 2000 2000 1000 -i | xform -t -1000 -1000
-500
>>
>> A further topic will be a “calibration” of the HDR sky views - we have
> global horizontal and diffuse horizontal radiation values available. The
> current idea of a (possibly slightly rough) method of calibration would
be
> to use the HDR sky to calculate the corresponding sensor value with
radiance
> and “somehow” introduce a scaling factor into the HDR sky such that the
> measured and calculated global horizontal radiation values tally.
>>
>> Thanks for any hints & ideas!
>>
>> Best
>> Achim
>>
>> [email protected]

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

[Achim_Geissler]

Hi Greg,

sorry to be somehow seemingly rubbing you the wrong way - I can't remember
you ever telling anybody else simply to "give up" :o( . It is definitely not
intentional (and I may note here that I am not a native English
speaker/writer).

The formatting was O.K. with html mail format. Whatever.

The Photosphere stuff was simply to try to give some information on the HDR
in respond to your statements in regard to same (kind of "prove" that it is
actually a Radiance readable HDR ...).

The comments on orienting the HDR are noted. I accept that if I do it right,
it should be correct ;o)

I wasn't planning to rewrite genskyvec.pl, but you have me confused on how I
should "prepare a sky file it will accept" - which is clearly my goal -
without understanding at least partially how it works / what the data flow
is / what it needs.

Actually, the number of the warnings increased significantly and no result
was obtained. With skyfunc_hdr a (not very useful) result was generated with
"some" identical warning messages.

@Andy: Incidentally, this is in regard to one step before tackling genskyvec
again, I am trying to generate a view of a scene via "sky_glow source sky"
based on the HDR ... the scene has a ground plane, but does have a "hole"
between this and the sky (which works with "normal" skies). I'll try your
suggestion for the sky definition, thanks!

Skymap.cal is

···

===
u = 1 - (0.5 + DDx *r);
v = 0.5 + DDy *r;

r = if(DD, 0.707106781*(sin(acos(DDz)/2))/DD,0);

DD = sqrt(DDx*DDx + DDy*DDy);

DDy = Py*norm;
DDx = Px*norm;
DDz = Pz*norm;

norm = 1/sqrt(Py*Py + Px*Px + Pz*Pz);

I'll go back to RWR again and see what I can learn.

Thanks.

Best
Achim

-----Ursprüngliche Nachricht-----
Von: Greg Ward [mailto:[email protected]]
Gesendet: Mittwoch, 1. Juni 2016 00:18
An: Radiance general discussion
Betreff: Re: [Radiance-general] genskyvec with HDR sky view?

Hi Achim,

I'll answer inline again, making a bad formatting job look even worse....

From: "Achim Geissler" <[email protected]>
Date: May 30, 2016 8:05:25 AM PDT

Hi Greg,

thanks for the pointers. I am afraid, though, that I was unable to
really make heads or tails of them.
a) HDR file (Photosphere)
  i, the (test) HDR gives min/max values in falsecolor view of 39 to
2900, whatever the unit, there
  ii, it gives histogram min/max values for Luminance of 34.8 to
4.43E+06
  iii, it does not seem to be clipped

I don't know what (i), (ii) and (iii) refer to, if anything. Are these
particular processes you have tried? If so, what are they?

Typically, falsecolor and Photosphere report photometric values (i.e.,
radiance values times 179 lumens/watt efficacy).

b) There is a sun (albeit behind a thin cloud cover). Simply adding a
sun definition to my sky description did not really change anything,

though.

Also, at this point I do not know which r,g,b radiance values to use
for the solar "light" material and do these influence the result? And,
actually, how to exactly position the HDR so that the sun positions tally.

If you have your sky turned the right way around, so that the Z-axis points
up, Y-axis points north, and X-axis points east, then positioning the sun is
a matter of running gensky with the appropriate date/time and global
position parameters, and extracting the description it generates. You can
adjust the solar radiance values to match the global-diffuse measured that
day using the -R option to gensky.

c) I took a look at the genskyvec.pl script, however, I am not
perl-literate so that is a bit difficult. I seem to be missing out on
where this script >could< use values from the HDR file to generate the
sky vectors. Part of the code seems to be a copy of the setting up of

patches from reinhart.cal.

Also, the "skyfunc glow skyglow" and "skyglow source sky" are written
to the
(an) octree in the script. Can I ignore that? Or does that let me
leave these definitions out of my sky description? Which definition has

precedent?

I can't really see where the "skybright.cal" values from a standard
gensky sky would come into play - this should be what is replaced by
values from the HDR?

I'm not suggesting you rewrite genskyvec. Rather, I'm suggesting that you
prepare a sky file it will accept and run it on that file. If this doesn't
make sense, then I suggest you give up.

d) using the sky description as below but with "skyfunc" gives
rpict: warning - compute error for colorpict "skyfunc"
rpict: Division by zero
when trying to generate a view of a scene.

I don't know why globally replacing "skyfunc_hdr" with "skyfunc" in your
file should cause new errors. You must have done something else, or the
original run would have generated the same errors. I don't know what's in
"map_sky.cal", which is the likely cause.

I must admit the flow of data (input / output) in all the definitions
is a bit of a mystery, for me. I did find a kind of description for
colorpict in p_data.c, but that didn't really help, sadly. Looking at
your code, I get the feeling I am not literate in any programming
language ... :o(

Well, it's not particularly transparent, I will grant you. There's this
back-and-forth between the ray tracing and the scene description, such that
when a material is intersected, it queries its modifiers, which calls back
to your map_sky.cal file in a rather convoluted fashion.

You should look through Chapter 4 of "Rendering with Radiance." Starting at
Section 4.1.4, we talk about how the interaction between rendering and .cal
files operates.

If you (or, of course, anyone else out there that has done this
before) can give any further help or tips, it would be much appreciated.

Best
Achim

-----Ursprüngliche Nachricht-----
Von: Greg Ward [mailto:[email protected]]
Gesendet: Samstag, 28. Mai 2016 01:27
An: Radiance general discussion
Betreff: Re: [Radiance-general] genskyvec with HDR sky view?

Hi Achim,

I wouldn't call what you are trying to do "easy," even if others have
done it. Your HDR file has to be in the correct units or scaled by
the right amount to get calibrated radiance values, and even then, the
sun is usually out of range(clipped) and won't be properly sampled if it

is a clear sky.

As you noted, such a sky cannot be given as input to genskyvec, which
expects a very specific set of primitives output by gensky or gendaylit.
Specifically, you need to name your colorpict pattern "skyfunc" and
add a solar source if the sky is sunny. You could try to modify your
description to match, but you'd have to look at the Perl script
src/util/genskyvec.pl to figure out how to satisfy the input requirements.

Once you have a sky description, you can use rtrace with the -I option
to compute hemispherical irradiance, from which you can create an
adjustment factor to apply to your glow based on horizontal irradiance.

It's all possible, but the details are not very straightforward.

Best,
-Greg

From: Achim Geissler <[email protected]>
Date: May 27, 2016 12:29:35 PM PDT

Hi all,

after searching high and low without clear results apart from a lot
of

pointers that “everybody seems to be doing it” (so it should actually
be easy and I am probably missing the forest due to seeing trees, as
they say) a short question: The goal is to use HDR (fisheye) views of
the sky for radiance calculations. All I could manage to date are
pretty pictures with HDR skies. Ideally, the workflow would be “the
same” as when using a sky from gensky or gendaylit. E.g., it would be
nice to be able to generate the sky vectors (genskyvec) from the HDR
sky view. Is that possible? How? Trying to simply pipe a sky
definition along the lines of

void colorpict skyfunc_hdr
7 red green blue sky_image.hdr map_sky.cal u v
0
0

skyfunc_hdr glow sky_glow_hdr
0
0
4 1 1 1 0

sky_glow_hdr source sky_hdr
0
0
4 0 0 1 180

into genskyvec didn’t work - well, would have been too simple (the

map_sky.cal is from the PhD by Coralie Cauwerts, 2013). The following
approaches resulted in the “pretty pictures” (replacing “source”
above)

sky_glow_hdr bubble sky_hdr
0
0
4 0 0 0 2000

or

!genbox sky_glow_hdr boxenv 2000 2000 1000 -i | xform -t -1000 -1000
-500

A further topic will be a “calibration” of the HDR sky views - we
have

global horizontal and diffuse horizontal radiation values available.
The current idea of a (possibly slightly rough) method of calibration
would be to use the HDR sky to calculate the corresponding sensor
value with radiance and “somehow” introduce a scaling factor into the
HDR sky such that the measured and calculated global horizontal radiation

values tally.

Thanks for any hints & ideas!

Best
Achim

[email protected]

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

[Andrew_McNeil]

@Andy: Incidentally, this is in regard to one step before tackling genskyvec

again, I am trying to generate a view of a scene via "sky_glow source sky"
based on the HDR ... the scene has a ground plane, but does have a "hole"
between this and the sky (which works with "normal" skies). I'll try your
suggestion for the sky definition, thanks!

Oh, I didn't realize it was a cal file issue. Have you considered using
fisheye.cal? It is distributed with the radiance auxiliary files (get them
here:
http://radiance-online.org/download-install/radiance-source-code/un-official-head-version
look in here: ray/lib/fisheye.cal). Here's how I use it, which I found
somewhere else along the way:

void colorpict skypict
11 red green blue sky_image.hdr fisheye.cal fish_u fish_v -rx 90 -rz 180
0
0

skypict glow skyglow
0
0
4 1 1 1 0

skyglow source sky
0
0
4 0 0 1 180

Andy

···

On Wed, Jun 1, 2016 at 1:08 AM, Achim Geissler <[email protected]> wrote:

Hi Greg,

sorry to be somehow seemingly rubbing you the wrong way - I can't remember
you ever telling anybody else simply to "give up" :o( . It is definitely
not
intentional (and I may note here that I am not a native English
speaker/writer).

The formatting was O.K. with html mail format. Whatever.

The Photosphere stuff was simply to try to give some information on the HDR
in respond to your statements in regard to same (kind of "prove" that it is
actually a Radiance readable HDR ...).

The comments on orienting the HDR are noted. I accept that if I do it
right,
it should be correct ;o)

I wasn't planning to rewrite genskyvec.pl, but you have me confused on
how I
should "prepare a sky file it will accept" - which is clearly my goal -
without understanding at least partially how it works / what the data flow
is / what it needs.

Actually, the number of the warnings increased significantly and no result
was obtained. With skyfunc_hdr a (not very useful) result was generated
with
"some" identical warning messages.

@Andy: Incidentally, this is in regard to one step before tackling
genskyvec
again, I am trying to generate a view of a scene via "sky_glow source sky"
based on the HDR ... the scene has a ground plane, but does have a "hole"
between this and the sky (which works with "normal" skies). I'll try your
suggestion for the sky definition, thanks!

Skymap.cal is

u = 1 - (0.5 + DDx *r);
v = 0.5 + DDy *r;

r = if(DD, 0.707106781*(sin(acos(DDz)/2))/DD,0);

DD = sqrt(DDx*DDx + DDy*DDy);

DDy = Py*norm;
DDx = Px*norm;
DDz = Pz*norm;

norm = 1/sqrt(Py*Py + Px*Px + Pz*Pz);

I'll go back to RWR again and see what I can learn.

Thanks.

Best
Achim

-----Ursprüngliche Nachricht-----
Von: Greg Ward [mailto:[email protected]]
Gesendet: Mittwoch, 1. Juni 2016 00:18
An: Radiance general discussion
Betreff: Re: [Radiance-general] genskyvec with HDR sky view?

Hi Achim,

I'll answer inline again, making a bad formatting job look even worse....

> From: "Achim Geissler" <[email protected]>
> Date: May 30, 2016 8:05:25 AM PDT
>
> Hi Greg,
>
> thanks for the pointers. I am afraid, though, that I was unable to
> really make heads or tails of them.
> a) HDR file (Photosphere)
> i, the (test) HDR gives min/max values in falsecolor view of 39 to
> 2900, whatever the unit, there
> ii, it gives histogram min/max values for Luminance of 34.8 to
> 4.43E+06
> iii, it does not seem to be clipped

I don't know what (i), (ii) and (iii) refer to, if anything. Are these
particular processes you have tried? If so, what are they?

Typically, falsecolor and Photosphere report photometric values (i.e.,
radiance values times 179 lumens/watt efficacy).

> b) There is a sun (albeit behind a thin cloud cover). Simply adding a
> sun definition to my sky description did not really change anything,
though.
> Also, at this point I do not know which r,g,b radiance values to use
> for the solar "light" material and do these influence the result? And,
> actually, how to exactly position the HDR so that the sun positions
tally.

If you have your sky turned the right way around, so that the Z-axis points
up, Y-axis points north, and X-axis points east, then positioning the sun
is
a matter of running gensky with the appropriate date/time and global
position parameters, and extracting the description it generates. You can
adjust the solar radiance values to match the global-diffuse measured that
day using the -R option to gensky.

> c) I took a look at the genskyvec.pl script, however, I am not
> perl-literate so that is a bit difficult. I seem to be missing out on
> where this script >could< use values from the HDR file to generate the
> sky vectors. Part of the code seems to be a copy of the setting up of
patches from reinhart.cal.
> Also, the "skyfunc glow skyglow" and "skyglow source sky" are written
> to the
> (an) octree in the script. Can I ignore that? Or does that let me
> leave these definitions out of my sky description? Which definition has
precedent?
> I can't really see where the "skybright.cal" values from a standard
> gensky sky would come into play - this should be what is replaced by
> values from the HDR?

I'm not suggesting you rewrite genskyvec. Rather, I'm suggesting that you
prepare a sky file it will accept and run it on that file. If this doesn't
make sense, then I suggest you give up.

> d) using the sky description as below but with "skyfunc" gives
> rpict: warning - compute error for colorpict "skyfunc"
> rpict: Division by zero
> when trying to generate a view of a scene.

I don't know why globally replacing "skyfunc_hdr" with "skyfunc" in your
file should cause new errors. You must have done something else, or the
original run would have generated the same errors. I don't know what's in
"map_sky.cal", which is the likely cause.

> I must admit the flow of data (input / output) in all the definitions
> is a bit of a mystery, for me. I did find a kind of description for
> colorpict in p_data.c, but that didn't really help, sadly. Looking at
> your code, I get the feeling I am not literate in any programming
> language ... :o(

Well, it's not particularly transparent, I will grant you. There's this
back-and-forth between the ray tracing and the scene description, such that
when a material is intersected, it queries its modifiers, which calls back
to your map_sky.cal file in a rather convoluted fashion.

You should look through Chapter 4 of "Rendering with Radiance." Starting
at
Section 4.1.4, we talk about how the interaction between rendering and .cal
files operates.

> If you (or, of course, anyone else out there that has done this
> before) can give any further help or tips, it would be much appreciated.
>
> Best
> Achim
>
>
> -----Ursprüngliche Nachricht-----
> Von: Greg Ward [mailto:[email protected]]
> Gesendet: Samstag, 28. Mai 2016 01:27
> An: Radiance general discussion
> Betreff: Re: [Radiance-general] genskyvec with HDR sky view?
>
> Hi Achim,
>
> I wouldn't call what you are trying to do "easy," even if others have
> done it. Your HDR file has to be in the correct units or scaled by
> the right amount to get calibrated radiance values, and even then, the
> sun is usually out of range(clipped) and won't be properly sampled if it
is a clear sky.
>
> As you noted, such a sky cannot be given as input to genskyvec, which
> expects a very specific set of primitives output by gensky or gendaylit.
> Specifically, you need to name your colorpict pattern "skyfunc" and
> add a solar source if the sky is sunny. You could try to modify your
> description to match, but you'd have to look at the Perl script
> src/util/genskyvec.pl to figure out how to satisfy the input
requirements.
>
> Once you have a sky description, you can use rtrace with the -I option
> to compute hemispherical irradiance, from which you can create an
> adjustment factor to apply to your glow based on horizontal irradiance.
>
> It's all possible, but the details are not very straightforward.
>
> Best,
> -Greg
>
>> From: Achim Geissler <[email protected]>
>> Date: May 27, 2016 12:29:35 PM PDT
>>
>> Hi all,
>>
>> after searching high and low without clear results apart from a lot
>> of
> pointers that “everybody seems to be doing it” (so it should actually
> be easy and I am probably missing the forest due to seeing trees, as
> they say) a short question: The goal is to use HDR (fisheye) views of
> the sky for radiance calculations. All I could manage to date are
> pretty pictures with HDR skies. Ideally, the workflow would be “the
> same” as when using a sky from gensky or gendaylit. E.g., it would be
> nice to be able to generate the sky vectors (genskyvec) from the HDR
> sky view. Is that possible? How? Trying to simply pipe a sky
> definition along the lines of
>>
>> void colorpict skyfunc_hdr
>> 7 red green blue sky_image.hdr map_sky.cal u v
>> 0
>> 0
>>
>> skyfunc_hdr glow sky_glow_hdr
>> 0
>> 0
>> 4 1 1 1 0
>>
>> sky_glow_hdr source sky_hdr
>> 0
>> 0
>> 4 0 0 1 180
>>
>> into genskyvec didn’t work - well, would have been too simple (the
> map_sky.cal is from the PhD by Coralie Cauwerts, 2013). The following
> approaches resulted in the “pretty pictures” (replacing “source”
> above)
>>
>> sky_glow_hdr bubble sky_hdr
>> 0
>> 0
>> 4 0 0 0 2000
>>
>> or
>>
>> !genbox sky_glow_hdr boxenv 2000 2000 1000 -i | xform -t -1000 -1000
>> -500
>>
>> A further topic will be a “calibration” of the HDR sky views - we
>> have
> global horizontal and diffuse horizontal radiation values available.
> The current idea of a (possibly slightly rough) method of calibration
> would be to use the HDR sky to calculate the corresponding sensor
> value with radiance and “somehow” introduce a scaling factor into the
> HDR sky such that the measured and calculated global horizontal radiation
values tally.
>>
>> Thanks for any hints & ideas!
>>
>> Best
>> Achim
>>
>> [email protected]

_______________________________________________
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

[Achim_Geissler]

Hi Andy,

that worked like a charm, thanks! The .cal file I was using originated from a source using “specific” fisheye lenses … hmm. More work to do.

You haven’t ever used a HDR sky with rcontrib, by the way?

Best

Achim

···

Von: Andy McNeil [mailto:[email protected]]
Gesendet: Mittwoch, 1. Juni 2016 17:00
An: Radiance general discussion
Betreff: Re: [Radiance-general] genskyvec with HDR sky view?

@Andy: Incidentally, this is in regard to one step before tackling genskyvec
again, I am trying to generate a view of a scene via "sky_glow source sky"
based on the HDR ... the scene has a ground plane, but does have a "hole"
between this and the sky (which works with "normal" skies). I'll try your
suggestion for the sky definition, thanks!

Oh, I didn't realize it was a cal file issue. Have you considered using fisheye.cal? It is distributed with the radiance auxiliary files (get them here:http://radiance-online.org/download-install/radiance-source-code/un-official-head-version look in here: ray/lib/fisheye.cal). Here's how I use it, which I found somewhere else along the way:

void colorpict skypict

11 red green blue sky_image.hdr fisheye.cal fish_u fish_v -rx 90 -rz 180

0

0

skypict glow skyglow

0

0

4 1 1 1 0

skyglow source sky

0

0

4 0 0 1 180

Andy

On Wed, Jun 1, 2016 at 1:08 AM, Achim Geissler <[email protected]> wrote:

Hi Greg,

sorry to be somehow seemingly rubbing you the wrong way - I can't remember
you ever telling anybody else simply to "give up" :o( . It is definitely not
intentional (and I may note here that I am not a native English
speaker/writer).

The formatting was O.K. with html mail format. Whatever.

The Photosphere stuff was simply to try to give some information on the HDR
in respond to your statements in regard to same (kind of "prove" that it is
actually a Radiance readable HDR ...).

The comments on orienting the HDR are noted. I accept that if I do it right,
it should be correct ;o)

I wasn't planning to rewrite genskyvec.pl, but you have me confused on how I
should "prepare a sky file it will accept" - which is clearly my goal -
without understanding at least partially how it works / what the data flow
is / what it needs.

Actually, the number of the warnings increased significantly and no result
was obtained. With skyfunc_hdr a (not very useful) result was generated with
"some" identical warning messages.

@Andy: Incidentally, this is in regard to one step before tackling genskyvec
again, I am trying to generate a view of a scene via "sky_glow source sky"
based on the HDR ... the scene has a ground plane, but does have a "hole"
between this and the sky (which works with "normal" skies). I'll try your
suggestion for the sky definition, thanks!

Skymap.cal is

u = 1 - (0.5 + DDx *r);
v = 0.5 + DDy *r;

r = if(DD, 0.707106781*(sin(acos(DDz)/2))/DD,0);

DD = sqrt(DDx*DDx + DDy*DDy);

DDy = Py*norm;
DDx = Px*norm;
DDz = Pz*norm;

norm = 1/sqrt(Py*Py + Px*Px + Pz*Pz);

I'll go back to RWR again and see what I can learn.

Thanks.

Best
Achim

-----Ursprüngliche Nachricht-----
Von: Greg Ward [mailto:[email protected]]
Gesendet: Mittwoch, 1. Juni 2016 00:18

An: Radiance general discussion
Betreff: Re: [Radiance-general] genskyvec with HDR sky view?

Hi Achim,

I'll answer inline again, making a bad formatting job look even worse....

From: "Achim Geissler" <[email protected]>
Date: May 30, 2016 8:05:25 AM PDT

Hi Greg,

thanks for the pointers. I am afraid, though, that I was unable to
really make heads or tails of them.
a) HDR file (Photosphere)
      i, the (test) HDR gives min/max values in falsecolor view of 39 to
2900, whatever the unit, there
      ii, it gives histogram min/max values for Luminance of 34.8 to
4.43E+06
      iii, it does not seem to be clipped

I don't know what (i), (ii) and (iii) refer to, if anything. Are these
particular processes you have tried? If so, what are they?

Typically, falsecolor and Photosphere report photometric values (i.e.,
radiance values times 179 lumens/watt efficacy).

b) There is a sun (albeit behind a thin cloud cover). Simply adding a
sun definition to my sky description did not really change anything,

though.

Also, at this point I do not know which r,g,b radiance values to use
for the solar "light" material and do these influence the result? And,
actually, how to exactly position the HDR so that the sun positions tally.

If you have your sky turned the right way around, so that the Z-axis points
up, Y-axis points north, and X-axis points east, then positioning the sun is
a matter of running gensky with the appropriate date/time and global
position parameters, and extracting the description it generates. You can
adjust the solar radiance values to match the global-diffuse measured that
day using the -R option to gensky.

c) I took a look at the genskyvec.pl script, however, I am not
perl-literate so that is a bit difficult. I seem to be missing out on
where this script >could< use values from the HDR file to generate the
sky vectors. Part of the code seems to be a copy of the setting up of

patches from reinhart.cal.

Also, the "skyfunc glow skyglow" and "skyglow source sky" are written
to the
(an) octree in the script. Can I ignore that? Or does that let me
leave these definitions out of my sky description? Which definition has

precedent?

I can't really see where the "skybright.cal" values from a standard
gensky sky would come into play - this should be what is replaced by
values from the HDR?

I'm not suggesting you rewrite genskyvec. Rather, I'm suggesting that you
prepare a sky file it will accept and run it on that file. If this doesn't
make sense, then I suggest you give up.

d) using the sky description as below but with "skyfunc" gives
rpict: warning - compute error for colorpict "skyfunc"
rpict: Division by zero
when trying to generate a view of a scene.

I don't know why globally replacing "skyfunc_hdr" with "skyfunc" in your
file should cause new errors. You must have done something else, or the
original run would have generated the same errors. I don't know what's in
"map_sky.cal", which is the likely cause.

I must admit the flow of data (input / output) in all the definitions
is a bit of a mystery, for me. I did find a kind of description for
colorpict in p_data.c, but that didn't really help, sadly. Looking at
your code, I get the feeling I am not literate in any programming
language ... :o(

Well, it's not particularly transparent, I will grant you. There's this
back-and-forth between the ray tracing and the scene description, such that
when a material is intersected, it queries its modifiers, which calls back
to your map_sky.cal file in a rather convoluted fashion.

You should look through Chapter 4 of "Rendering with Radiance." Starting at
Section 4.1.4, we talk about how the interaction between rendering and .cal
files operates.

If you (or, of course, anyone else out there that has done this
before) can give any further help or tips, it would be much appreciated.

Best
Achim

-----Ursprüngliche Nachricht-----
Von: Greg Ward [mailto:[email protected]]
Gesendet: Samstag, 28. Mai 2016 01:27
An: Radiance general discussion
Betreff: Re: [Radiance-general] genskyvec with HDR sky view?

Hi Achim,

I wouldn't call what you are trying to do "easy," even if others have
done it. Your HDR file has to be in the correct units or scaled by
the right amount to get calibrated radiance values, and even then, the
sun is usually out of range(clipped) and won't be properly sampled if it

is a clear sky.

As you noted, such a sky cannot be given as input to genskyvec, which
expects a very specific set of primitives output by gensky or gendaylit.
Specifically, you need to name your colorpict pattern "skyfunc" and
add a solar source if the sky is sunny. You could try to modify your
description to match, but you'd have to look at the Perl script
src/util/genskyvec.pl to figure out how to satisfy the input requirements.

Once you have a sky description, you can use rtrace with the -I option
to compute hemispherical irradiance, from which you can create an
adjustment factor to apply to your glow based on horizontal irradiance.

It's all possible, but the details are not very straightforward.

Best,
-Greg

From: Achim Geissler <[email protected]>
Date: May 27, 2016 12:29:35 PM PDT

Hi all,

after searching high and low without clear results apart from a lot
of

pointers that “everybody seems to be doing it” (so it should actually
be easy and I am probably missing the forest due to seeing trees, as
they say) a short question: The goal is to use HDR (fisheye) views of
the sky for radiance calculations. All I could manage to date are
pretty pictures with HDR skies. Ideally, the workflow would be “the
same” as when using a sky from gensky or gendaylit. E.g., it would be
nice to be able to generate the sky vectors (genskyvec) from the HDR
sky view. Is that possible? How? Trying to simply pipe a sky
definition along the lines of

void colorpict skyfunc_hdr
7 red green blue sky_image.hdr map_sky.cal u v
0
0

skyfunc_hdr glow sky_glow_hdr
0
0
4 1 1 1 0

sky_glow_hdr source sky_hdr
0
0
4 0 0 1 180

into genskyvec didn’t work - well, would have been too simple (the

map_sky.cal is from the PhD by Coralie Cauwerts, 2013). The following
approaches resulted in the “pretty pictures” (replacing “source”
above)

sky_glow_hdr bubble sky_hdr
0
0
4 0 0 0 2000

or

!genbox sky_glow_hdr boxenv 2000 2000 1000 -i | xform -t -1000 -1000
-500

A further topic will be a “calibration” of the HDR sky views - we
have

global horizontal and diffuse horizontal radiation values available.
The current idea of a (possibly slightly rough) method of calibration
would be to use the HDR sky to calculate the corresponding sensor
value with radiance and “somehow” introduce a scaling factor into the
HDR sky such that the measured and calculated global horizontal radiation

values tally.

Thanks for any hints & ideas!

Best
Achim

[email protected]

_______________________________________________
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

[Andrew_McNeil]

You haven’t ever used a HDR sky with rcontrib, by the way?

Yes, I have. I'm working for Terrestrial Light: http://terrestriallight.com/
which makes HDR cameras for building control systems.

···

On Wed, Jun 1, 2016 at 8:48 AM, Achim Geissler <[email protected]> wrote:

Hi Andy,

that worked like a charm, thanks! The .cal file I was using originated
from a source using “specific” fisheye lenses … hmm. More work to do.

You haven’t ever used a HDR sky with rcontrib, by the way?

Best

Achim

*Von:* Andy McNeil [mailto:[email protected]]
*Gesendet:* Mittwoch, 1. Juni 2016 17:00

*An:* Radiance general discussion
*Betreff:* Re: [Radiance-general] genskyvec with HDR sky view?

@Andy: Incidentally, this is in regard to one step before tackling
genskyvec
again, I am trying to generate a view of a scene via "sky_glow source sky"
based on the HDR ... the scene has a ground plane, but does have a "hole"
between this and the sky (which works with "normal" skies). I'll try your
suggestion for the sky definition, thanks!

Oh, I didn't realize it was a cal file issue. Have you considered using
fisheye.cal? It is distributed with the radiance auxiliary files (get them
here:
http://radiance-online.org/download-install/radiance-source-code/un-official-head-version
look in here: ray/lib/fisheye.cal). Here's how I use it, which I found
somewhere else along the way:

void colorpict skypict

11 red green blue sky_image.hdr fisheye.cal fish_u fish_v -rx 90 -rz 180

0

0

skypict glow skyglow

0

0

4 1 1 1 0

skyglow source sky

0

0

4 0 0 1 180

Andy

On Wed, Jun 1, 2016 at 1:08 AM, Achim Geissler <[email protected]> > wrote:

Hi Greg,

sorry to be somehow seemingly rubbing you the wrong way - I can't remember
you ever telling anybody else simply to "give up" :o( . It is definitely
not
intentional (and I may note here that I am not a native English
speaker/writer).

The formatting was O.K. with html mail format. Whatever.

The Photosphere stuff was simply to try to give some information on the HDR
in respond to your statements in regard to same (kind of "prove" that it is
actually a Radiance readable HDR ...).

The comments on orienting the HDR are noted. I accept that if I do it
right,
it should be correct ;o)

I wasn't planning to rewrite genskyvec.pl, but you have me confused on
how I
should "prepare a sky file it will accept" - which is clearly my goal -
without understanding at least partially how it works / what the data flow
is / what it needs.

Actually, the number of the warnings increased significantly and no result
was obtained. With skyfunc_hdr a (not very useful) result was generated
with
"some" identical warning messages.

@Andy: Incidentally, this is in regard to one step before tackling
genskyvec
again, I am trying to generate a view of a scene via "sky_glow source sky"
based on the HDR ... the scene has a ground plane, but does have a "hole"
between this and the sky (which works with "normal" skies). I'll try your
suggestion for the sky definition, thanks!

Skymap.cal is

u = 1 - (0.5 + DDx *r);
v = 0.5 + DDy *r;

r = if(DD, 0.707106781*(sin(acos(DDz)/2))/DD,0);

DD = sqrt(DDx*DDx + DDy*DDy);

DDy = Py*norm;
DDx = Px*norm;
DDz = Pz*norm;

norm = 1/sqrt(Py*Py + Px*Px + Pz*Pz);

I'll go back to RWR again and see what I can learn.

Thanks.

Best
Achim

-----Ursprüngliche Nachricht-----
Von: Greg Ward [mailto:[email protected]]
Gesendet: Mittwoch, 1. Juni 2016 00:18

An: Radiance general discussion
Betreff: Re: [Radiance-general] genskyvec with HDR sky view?

Hi Achim,

I'll answer inline again, making a bad formatting job look even worse....

> From: "Achim Geissler" <[email protected]>
> Date: May 30, 2016 8:05:25 AM PDT
>
> Hi Greg,
>
> thanks for the pointers. I am afraid, though, that I was unable to
> really make heads or tails of them.
> a) HDR file (Photosphere)
> i, the (test) HDR gives min/max values in falsecolor view of 39 to
> 2900, whatever the unit, there
> ii, it gives histogram min/max values for Luminance of 34.8 to
> 4.43E+06
> iii, it does not seem to be clipped

I don't know what (i), (ii) and (iii) refer to, if anything. Are these
particular processes you have tried? If so, what are they?

Typically, falsecolor and Photosphere report photometric values (i.e.,
radiance values times 179 lumens/watt efficacy).

> b) There is a sun (albeit behind a thin cloud cover). Simply adding a
> sun definition to my sky description did not really change anything,
though.
> Also, at this point I do not know which r,g,b radiance values to use
> for the solar "light" material and do these influence the result? And,
> actually, how to exactly position the HDR so that the sun positions
tally.

If you have your sky turned the right way around, so that the Z-axis points
up, Y-axis points north, and X-axis points east, then positioning the sun
is
a matter of running gensky with the appropriate date/time and global
position parameters, and extracting the description it generates. You can
adjust the solar radiance values to match the global-diffuse measured that
day using the -R option to gensky.

> c) I took a look at the genskyvec.pl script, however, I am not
> perl-literate so that is a bit difficult. I seem to be missing out on
> where this script >could< use values from the HDR file to generate the
> sky vectors. Part of the code seems to be a copy of the setting up of
patches from reinhart.cal.
> Also, the "skyfunc glow skyglow" and "skyglow source sky" are written
> to the
> (an) octree in the script. Can I ignore that? Or does that let me
> leave these definitions out of my sky description? Which definition has
precedent?
> I can't really see where the "skybright.cal" values from a standard
> gensky sky would come into play - this should be what is replaced by
> values from the HDR?

I'm not suggesting you rewrite genskyvec. Rather, I'm suggesting that you
prepare a sky file it will accept and run it on that file. If this doesn't
make sense, then I suggest you give up.

> d) using the sky description as below but with "skyfunc" gives
> rpict: warning - compute error for colorpict "skyfunc"
> rpict: Division by zero
> when trying to generate a view of a scene.

I don't know why globally replacing "skyfunc_hdr" with "skyfunc" in your
file should cause new errors. You must have done something else, or the
original run would have generated the same errors. I don't know what's in
"map_sky.cal", which is the likely cause.

> I must admit the flow of data (input / output) in all the definitions
> is a bit of a mystery, for me. I did find a kind of description for
> colorpict in p_data.c, but that didn't really help, sadly. Looking at
> your code, I get the feeling I am not literate in any programming
> language ... :o(

Well, it's not particularly transparent, I will grant you. There's this
back-and-forth between the ray tracing and the scene description, such that
when a material is intersected, it queries its modifiers, which calls back
to your map_sky.cal file in a rather convoluted fashion.

You should look through Chapter 4 of "Rendering with Radiance." Starting
at
Section 4.1.4, we talk about how the interaction between rendering and .cal
files operates.

> If you (or, of course, anyone else out there that has done this
> before) can give any further help or tips, it would be much appreciated.
>
> Best
> Achim
>
>
> -----Ursprüngliche Nachricht-----
> Von: Greg Ward [mailto:[email protected]]
> Gesendet: Samstag, 28. Mai 2016 01:27
> An: Radiance general discussion
> Betreff: Re: [Radiance-general] genskyvec with HDR sky view?
>
> Hi Achim,
>
> I wouldn't call what you are trying to do "easy," even if others have
> done it. Your HDR file has to be in the correct units or scaled by
> the right amount to get calibrated radiance values, and even then, the
> sun is usually out of range(clipped) and won't be properly sampled if it
is a clear sky.
>
> As you noted, such a sky cannot be given as input to genskyvec, which
> expects a very specific set of primitives output by gensky or gendaylit.
> Specifically, you need to name your colorpict pattern "skyfunc" and
> add a solar source if the sky is sunny. You could try to modify your
> description to match, but you'd have to look at the Perl script
> src/util/genskyvec.pl to figure out how to satisfy the input
requirements.
>
> Once you have a sky description, you can use rtrace with the -I option
> to compute hemispherical irradiance, from which you can create an
> adjustment factor to apply to your glow based on horizontal irradiance.
>
> It's all possible, but the details are not very straightforward.
>
> Best,
> -Greg
>
>> From: Achim Geissler <[email protected]>
>> Date: May 27, 2016 12:29:35 PM PDT
>>
>> Hi all,
>>
>> after searching high and low without clear results apart from a lot
>> of
> pointers that “everybody seems to be doing it” (so it should actually
> be easy and I am probably missing the forest due to seeing trees, as
> they say) a short question: The goal is to use HDR (fisheye) views of
> the sky for radiance calculations. All I could manage to date are
> pretty pictures with HDR skies. Ideally, the workflow would be “the
> same” as when using a sky from gensky or gendaylit. E.g., it would be
> nice to be able to generate the sky vectors (genskyvec) from the HDR
> sky view. Is that possible? How? Trying to simply pipe a sky
> definition along the lines of
>>
>> void colorpict skyfunc_hdr
>> 7 red green blue sky_image.hdr map_sky.cal u v
>> 0
>> 0
>>
>> skyfunc_hdr glow sky_glow_hdr
>> 0
>> 0
>> 4 1 1 1 0
>>
>> sky_glow_hdr source sky_hdr
>> 0
>> 0
>> 4 0 0 1 180
>>
>> into genskyvec didn’t work - well, would have been too simple (the
> map_sky.cal is from the PhD by Coralie Cauwerts, 2013). The following
> approaches resulted in the “pretty pictures” (replacing “source”
> above)
>>
>> sky_glow_hdr bubble sky_hdr
>> 0
>> 0
>> 4 0 0 0 2000
>>
>> or
>>
>> !genbox sky_glow_hdr boxenv 2000 2000 1000 -i | xform -t -1000 -1000
>> -500
>>
>> A further topic will be a “calibration” of the HDR sky views - we
>> have
> global horizontal and diffuse horizontal radiation values available.
> The current idea of a (possibly slightly rough) method of calibration
> would be to use the HDR sky to calculate the corresponding sensor
> value with radiance and “somehow” introduce a scaling factor into the
> HDR sky such that the measured and calculated global horizontal radiation
values tally.
>>
>> Thanks for any hints & ideas!
>>
>> Best
>> Achim
>>
>> [email protected]

_______________________________________________
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

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

[Greg_Ward]

Hi Achim,

I apologize for being snippy in my response. It must be because I am feeling a little out of depth on this topic, myself. I am glad that Andy and others are willing to help, as they know more about it than I do.

It does help when you provide example inputs, commands you have run, and what was unexpected about your results. Too many questions without specifics can be overwhelming. If your mail was sent as HTML, it got stripped before getting to me. I think our mailing list manager may be to blame. Best just to compose in standard text format.

To create a sky that genskyvec will accept, it should be sufficient to take the output of gensky and replace the skyfunc definition with your colorpict modifier. I don't think it cares about the primitive type (i.e., "brightfunc" versus "colorpict").

I agree that you should not use skymap.cal, which assumes local geometry. A hemispherical source will not set the Px, Py, and Pz variables properly.

Cheers,
-Greg

···

From: "Achim Geissler" <[email protected]>
Date: June 1, 2016 1:08:31 AM PDT

Hi Greg,

sorry to be somehow seemingly rubbing you the wrong way - I can't remember
you ever telling anybody else simply to "give up" :o( . It is definitely not
intentional (and I may note here that I am not a native English
speaker/writer).

The formatting was O.K. with html mail format. Whatever.

The Photosphere stuff was simply to try to give some information on the HDR
in respond to your statements in regard to same (kind of "prove" that it is
actually a Radiance readable HDR ...).

The comments on orienting the HDR are noted. I accept that if I do it right,
it should be correct ;o)

I wasn't planning to rewrite genskyvec.pl, but you have me confused on how I
should "prepare a sky file it will accept" - which is clearly my goal -
without understanding at least partially how it works / what the data flow
is / what it needs.

Actually, the number of the warnings increased significantly and no result
was obtained. With skyfunc_hdr a (not very useful) result was generated with
"some" identical warning messages.

@Andy: Incidentally, this is in regard to one step before tackling genskyvec
again, I am trying to generate a view of a scene via "sky_glow source sky"
based on the HDR ... the scene has a ground plane, but does have a "hole"
between this and the sky (which works with "normal" skies). I'll try your
suggestion for the sky definition, thanks!

Skymap.cal is

u = 1 - (0.5 + DDx *r);
v = 0.5 + DDy *r;

r = if(DD, 0.707106781*(sin(acos(DDz)/2))/DD,0);

DD = sqrt(DDx*DDx + DDy*DDy);

DDy = Py*norm;
DDx = Px*norm;
DDz = Pz*norm;

norm = 1/sqrt(Py*Py + Px*Px + Pz*Pz);

I'll go back to RWR again and see what I can learn.

Thanks.

Best
Achim

-----Ursprüngliche Nachricht-----
Von: Greg Ward [mailto:[email protected]]
Gesendet: Mittwoch, 1. Juni 2016 00:18
An: Radiance general discussion
Betreff: Re: [Radiance-general] genskyvec with HDR sky view?

Hi Achim,

I'll answer inline again, making a bad formatting job look even worse....

From: "Achim Geissler" <[email protected]>
Date: May 30, 2016 8:05:25 AM PDT

Hi Greg,

thanks for the pointers. I am afraid, though, that I was unable to
really make heads or tails of them.
a) HDR file (Photosphere)
  i, the (test) HDR gives min/max values in falsecolor view of 39 to
2900, whatever the unit, there
  ii, it gives histogram min/max values for Luminance of 34.8 to
4.43E+06
  iii, it does not seem to be clipped

I don't know what (i), (ii) and (iii) refer to, if anything. Are these
particular processes you have tried? If so, what are they?

Typically, falsecolor and Photosphere report photometric values (i.e.,
radiance values times 179 lumens/watt efficacy).

b) There is a sun (albeit behind a thin cloud cover). Simply adding a
sun definition to my sky description did not really change anything,

though.

Also, at this point I do not know which r,g,b radiance values to use
for the solar "light" material and do these influence the result? And,
actually, how to exactly position the HDR so that the sun positions tally.

If you have your sky turned the right way around, so that the Z-axis points
up, Y-axis points north, and X-axis points east, then positioning the sun is
a matter of running gensky with the appropriate date/time and global
position parameters, and extracting the description it generates. You can
adjust the solar radiance values to match the global-diffuse measured that
day using the -R option to gensky.

c) I took a look at the genskyvec.pl script, however, I am not
perl-literate so that is a bit difficult. I seem to be missing out on
where this script >could< use values from the HDR file to generate the
sky vectors. Part of the code seems to be a copy of the setting up of

patches from reinhart.cal.

Also, the "skyfunc glow skyglow" and "skyglow source sky" are written
to the
(an) octree in the script. Can I ignore that? Or does that let me
leave these definitions out of my sky description? Which definition has

precedent?

I can't really see where the "skybright.cal" values from a standard
gensky sky would come into play - this should be what is replaced by
values from the HDR?

I'm not suggesting you rewrite genskyvec. Rather, I'm suggesting that you
prepare a sky file it will accept and run it on that file. If this doesn't
make sense, then I suggest you give up.

d) using the sky description as below but with "skyfunc" gives
rpict: warning - compute error for colorpict "skyfunc"
rpict: Division by zero
when trying to generate a view of a scene.

I don't know why globally replacing "skyfunc_hdr" with "skyfunc" in your
file should cause new errors. You must have done something else, or the
original run would have generated the same errors. I don't know what's in
"map_sky.cal", which is the likely cause.

I must admit the flow of data (input / output) in all the definitions
is a bit of a mystery, for me. I did find a kind of description for
colorpict in p_data.c, but that didn't really help, sadly. Looking at
your code, I get the feeling I am not literate in any programming
language ... :o(

Well, it's not particularly transparent, I will grant you. There's this
back-and-forth between the ray tracing and the scene description, such that
when a material is intersected, it queries its modifiers, which calls back
to your map_sky.cal file in a rather convoluted fashion.

You should look through Chapter 4 of "Rendering with Radiance." Starting at
Section 4.1.4, we talk about how the interaction between rendering and .cal
files operates.

If you (or, of course, anyone else out there that has done this
before) can give any further help or tips, it would be much appreciated.

Best
Achim

-----Ursprüngliche Nachricht-----
Von: Greg Ward [mailto:[email protected]]
Gesendet: Samstag, 28. Mai 2016 01:27
An: Radiance general discussion
Betreff: Re: [Radiance-general] genskyvec with HDR sky view?

Hi Achim,

I wouldn't call what you are trying to do "easy," even if others have
done it. Your HDR file has to be in the correct units or scaled by
the right amount to get calibrated radiance values, and even then, the
sun is usually out of range(clipped) and won't be properly sampled if it

is a clear sky.

As you noted, such a sky cannot be given as input to genskyvec, which
expects a very specific set of primitives output by gensky or gendaylit.
Specifically, you need to name your colorpict pattern "skyfunc" and
add a solar source if the sky is sunny. You could try to modify your
description to match, but you'd have to look at the Perl script
src/util/genskyvec.pl to figure out how to satisfy the input requirements.

Once you have a sky description, you can use rtrace with the -I option
to compute hemispherical irradiance, from which you can create an
adjustment factor to apply to your glow based on horizontal irradiance.

It's all possible, but the details are not very straightforward.

Best,
-Greg

From: Achim Geissler <[email protected]>
Date: May 27, 2016 12:29:35 PM PDT

Hi all,

after searching high and low without clear results apart from a lot
of

pointers that “everybody seems to be doing it” (so it should actually
be easy and I am probably missing the forest due to seeing trees, as
they say) a short question: The goal is to use HDR (fisheye) views of
the sky for radiance calculations. All I could manage to date are
pretty pictures with HDR skies. Ideally, the workflow would be “the
same” as when using a sky from gensky or gendaylit. E.g., it would be
nice to be able to generate the sky vectors (genskyvec) from the HDR
sky view. Is that possible? How? Trying to simply pipe a sky
definition along the lines of

void colorpict skyfunc_hdr
7 red green blue sky_image.hdr map_sky.cal u v
0
0

skyfunc_hdr glow sky_glow_hdr
0
0
4 1 1 1 0

sky_glow_hdr source sky_hdr
0
0
4 0 0 1 180

into genskyvec didn’t work - well, would have been too simple (the

map_sky.cal is from the PhD by Coralie Cauwerts, 2013). The following
approaches resulted in the “pretty pictures” (replacing “source”
above)

sky_glow_hdr bubble sky_hdr
0
0
4 0 0 0 2000

or

!genbox sky_glow_hdr boxenv 2000 2000 1000 -i | xform -t -1000 -1000
-500

A further topic will be a “calibration” of the HDR sky views - we
have

global horizontal and diffuse horizontal radiation values available.
The current idea of a (possibly slightly rough) method of calibration
would be to use the HDR sky to calculate the corresponding sensor
value with radiance and “somehow” introduce a scaling factor into the
HDR sky such that the measured and calculated global horizontal radiation

values tally.

Thanks for any hints & ideas!

Best
Achim

[Achim_Geissler]

Hi Greg,

all clear, thanks.

Now I’m rolling. The basic problem was that I had tried to be too smart and combined the angmap.cal from Paul Debevec with the one from Coralie Cauwerts and ended up with the Px, Py and Pz that, as you write, are not set for a “source” (a fact that I will try to understand, by and by). Now genskyvec has no problem with my HDR skies both with “fisheye.cal” and a corrected “map_sky.cal”. Perfect. Now the actual work can begin ;o)

Thanks for your time, Greg and Andy!

Best
Achim

P.S: I assume I will be back at some point, though …

P.P.S.: @Andy: terrestriallight looks very interesting!!

···

On 01 Jun 2016, at 19:44, Greg Ward <[email protected]> wrote:

Hi Achim,

I apologize for being snippy in my response. It must be because I am feeling a little out of depth on this topic, myself. I am glad that Andy and others are willing to help, as they know more about it than I do.

It does help when you provide example inputs, commands you have run, and what was unexpected about your results. Too many questions without specifics can be overwhelming. If your mail was sent as HTML, it got stripped before getting to me. I think our mailing list manager may be to blame. Best just to compose in standard text format.

To create a sky that genskyvec will accept, it should be sufficient to take the output of gensky and replace the skyfunc definition with your colorpict modifier. I don't think it cares about the primitive type (i.e., "brightfunc" versus "colorpict").

I agree that you should not use skymap.cal, which assumes local geometry. A hemispherical source will not set the Px, Py, and Pz variables properly.

Cheers,
-Greg

From: "Achim Geissler" <[email protected]>
Date: June 1, 2016 1:08:31 AM PDT

Hi Greg,

sorry to be somehow seemingly rubbing you the wrong way - I can't remember
you ever telling anybody else simply to "give up" :o( . It is definitely not
intentional (and I may note here that I am not a native English
speaker/writer).

The formatting was O.K. with html mail format. Whatever.

The Photosphere stuff was simply to try to give some information on the HDR
in respond to your statements in regard to same (kind of "prove" that it is
actually a Radiance readable HDR ...).

The comments on orienting the HDR are noted. I accept that if I do it right,
it should be correct ;o)

I wasn't planning to rewrite genskyvec.pl, but you have me confused on how I
should "prepare a sky file it will accept" - which is clearly my goal -
without understanding at least partially how it works / what the data flow
is / what it needs.

Actually, the number of the warnings increased significantly and no result
was obtained. With skyfunc_hdr a (not very useful) result was generated with
"some" identical warning messages.

@Andy: Incidentally, this is in regard to one step before tackling genskyvec
again, I am trying to generate a view of a scene via "sky_glow source sky"
based on the HDR ... the scene has a ground plane, but does have a "hole"
between this and the sky (which works with "normal" skies). I'll try your
suggestion for the sky definition, thanks!

Skymap.cal is

u = 1 - (0.5 + DDx *r);
v = 0.5 + DDy *r;

r = if(DD, 0.707106781*(sin(acos(DDz)/2))/DD,0);

DD = sqrt(DDx*DDx + DDy*DDy);

DDy = Py*norm;
DDx = Px*norm;
DDz = Pz*norm;

norm = 1/sqrt(Py*Py + Px*Px + Pz*Pz);

I'll go back to RWR again and see what I can learn.

Thanks.

Best
Achim

-----Ursprüngliche Nachricht-----
Von: Greg Ward [mailto:[email protected]]
Gesendet: Mittwoch, 1. Juni 2016 00:18
An: Radiance general discussion
Betreff: Re: [Radiance-general] genskyvec with HDR sky view?

Hi Achim,

I'll answer inline again, making a bad formatting job look even worse....

From: "Achim Geissler" <[email protected]>
Date: May 30, 2016 8:05:25 AM PDT

Hi Greg,

thanks for the pointers. I am afraid, though, that I was unable to
really make heads or tails of them.
a) HDR file (Photosphere)
  i, the (test) HDR gives min/max values in falsecolor view of 39 to
2900, whatever the unit, there
  ii, it gives histogram min/max values for Luminance of 34.8 to
4.43E+06
  iii, it does not seem to be clipped

I don't know what (i), (ii) and (iii) refer to, if anything. Are these
particular processes you have tried? If so, what are they?

Typically, falsecolor and Photosphere report photometric values (i.e.,
radiance values times 179 lumens/watt efficacy).

b) There is a sun (albeit behind a thin cloud cover). Simply adding a
sun definition to my sky description did not really change anything,

though.

Also, at this point I do not know which r,g,b radiance values to use
for the solar "light" material and do these influence the result? And,
actually, how to exactly position the HDR so that the sun positions tally.

If you have your sky turned the right way around, so that the Z-axis points
up, Y-axis points north, and X-axis points east, then positioning the sun is
a matter of running gensky with the appropriate date/time and global
position parameters, and extracting the description it generates. You can
adjust the solar radiance values to match the global-diffuse measured that
day using the -R option to gensky.

c) I took a look at the genskyvec.pl script, however, I am not
perl-literate so that is a bit difficult. I seem to be missing out on
where this script >could< use values from the HDR file to generate the
sky vectors. Part of the code seems to be a copy of the setting up of

patches from reinhart.cal.

Also, the "skyfunc glow skyglow" and "skyglow source sky" are written
to the
(an) octree in the script. Can I ignore that? Or does that let me
leave these definitions out of my sky description? Which definition has

precedent?

I can't really see where the "skybright.cal" values from a standard
gensky sky would come into play - this should be what is replaced by
values from the HDR?

I'm not suggesting you rewrite genskyvec. Rather, I'm suggesting that you
prepare a sky file it will accept and run it on that file. If this doesn't
make sense, then I suggest you give up.

d) using the sky description as below but with "skyfunc" gives
rpict: warning - compute error for colorpict "skyfunc"
rpict: Division by zero
when trying to generate a view of a scene.

I don't know why globally replacing "skyfunc_hdr" with "skyfunc" in your
file should cause new errors. You must have done something else, or the
original run would have generated the same errors. I don't know what's in
"map_sky.cal", which is the likely cause.

I must admit the flow of data (input / output) in all the definitions
is a bit of a mystery, for me. I did find a kind of description for
colorpict in p_data.c, but that didn't really help, sadly. Looking at
your code, I get the feeling I am not literate in any programming
language ... :o(

Well, it's not particularly transparent, I will grant you. There's this
back-and-forth between the ray tracing and the scene description, such that
when a material is intersected, it queries its modifiers, which calls back
to your map_sky.cal file in a rather convoluted fashion.

You should look through Chapter 4 of "Rendering with Radiance." Starting at
Section 4.1.4, we talk about how the interaction between rendering and .cal
files operates.

If you (or, of course, anyone else out there that has done this
before) can give any further help or tips, it would be much appreciated.

Best
Achim

-----Ursprüngliche Nachricht-----
Von: Greg Ward [mailto:[email protected]]
Gesendet: Samstag, 28. Mai 2016 01:27
An: Radiance general discussion
Betreff: Re: [Radiance-general] genskyvec with HDR sky view?

Hi Achim,

I wouldn't call what you are trying to do "easy," even if others have
done it. Your HDR file has to be in the correct units or scaled by
the right amount to get calibrated radiance values, and even then, the
sun is usually out of range(clipped) and won't be properly sampled if it

is a clear sky.

As you noted, such a sky cannot be given as input to genskyvec, which
expects a very specific set of primitives output by gensky or gendaylit.
Specifically, you need to name your colorpict pattern "skyfunc" and
add a solar source if the sky is sunny. You could try to modify your
description to match, but you'd have to look at the Perl script
src/util/genskyvec.pl to figure out how to satisfy the input requirements.

Once you have a sky description, you can use rtrace with the -I option
to compute hemispherical irradiance, from which you can create an
adjustment factor to apply to your glow based on horizontal irradiance.

It's all possible, but the details are not very straightforward.

Best,
-Greg

From: Achim Geissler <[email protected]>
Date: May 27, 2016 12:29:35 PM PDT

Hi all,

after searching high and low without clear results apart from a lot
of

pointers that “everybody seems to be doing it” (so it should actually
be easy and I am probably missing the forest due to seeing trees, as
they say) a short question: The goal is to use HDR (fisheye) views of
the sky for radiance calculations. All I could manage to date are
pretty pictures with HDR skies. Ideally, the workflow would be “the
same” as when using a sky from gensky or gendaylit. E.g., it would be
nice to be able to generate the sky vectors (genskyvec) from the HDR
sky view. Is that possible? How? Trying to simply pipe a sky
definition along the lines of

void colorpict skyfunc_hdr
7 red green blue sky_image.hdr map_sky.cal u v
0
0

skyfunc_hdr glow sky_glow_hdr
0
0
4 1 1 1 0

sky_glow_hdr source sky_hdr
0
0
4 0 0 1 180

into genskyvec didn’t work - well, would have been too simple (the

map_sky.cal is from the PhD by Coralie Cauwerts, 2013). The following
approaches resulted in the “pretty pictures” (replacing “source”
above)

sky_glow_hdr bubble sky_hdr
0
0
4 0 0 0 2000

or

!genbox sky_glow_hdr boxenv 2000 2000 1000 -i | xform -t -1000 -1000
-500

A further topic will be a “calibration” of the HDR sky views - we
have

global horizontal and diffuse horizontal radiation values available.
The current idea of a (possibly slightly rough) method of calibration
would be to use the HDR sky to calculate the corresponding sensor
value with radiance and “somehow” introduce a scaling factor into the
HDR sky such that the measured and calculated global horizontal radiation

values tally.

Thanks for any hints & ideas!

Best
Achim

_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general

[email protected]