[Radiance-general] genskyvec with HDR sky view?

[Andy 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 <gregoryjward at gmail.com> wrote:

> Hi Achim,
>
> I'll answer inline again, making a bad formatting job look even worse....
>
> > From: "Achim Geissler" <achim.geissler at intergga.ch>
> > 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:gregoryjward at gmail.com]
> > 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 <achim.geissler at intergga.ch>
> >> 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 at intergga.ch
>
> _______________________________________________
> Radiance-general mailing list
> Radiance-general at radiance-online.org
> http://www.radiance-online.org/mailman/listinfo/radiance-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.radiance-online.org/pipermail/radiance-general/attachments/20160531/a9d6ff92/attachment-0001.html>