Hello everyone,
I have been doing some tests in order to apply the methodology for overflow correction covered in this year's paper by Jakubiec et al. using pcomb, as for example:
pcomb -e "lo=L ? Sang ? cosCor; L=179 ? li(1);
Sang=S(1); cosCor=Dy(1);" -o masked.hdr
pvalue -d -b -h -H
total
However, I keep getting "domain error" messages for both the S(n) and Dy(n) functions in my images. My first thought was something's wrong with the headers, but the view information looks correct having the full 180 degrees span of my Sigma lens.
Images are created by HDRgen using response function obtained by Photosphere, and are square-cropped, and resized to 800x800, and otherwise work fine, in terms of validating luminances or illuminances over Evalglare (at least the ones that don't contain the sun).
I'm getting the same domain errors in terms of solid angles when I try to extract a mapping of solid angles, using something like: cat image.hdr |pcomb -e 'solidangl=S(1); ro=omega; go=omega; bo=omega' -o - > solid_angles.hdr
If anybody has any hints or ideas, I'd greatly appreciate it, as I think that with careful use (no specular reflections etc.), overflow correction can be a great solution over the alternatives for direct sun measurements.
Thanks in advance,
Iason Konstantzos
Hi Iason,
Can you send the output of "getinfo" for the picture that you are feeding to pcomb? My suspicion is that you performed the cropping operation caused the view parameters are being shifted or modified and are not being recognized by pcomb. This will generate the domain error you are seeing.
Cheers,
-Greg
···
From: Iason Konstantzos <[email protected]>
Date: November 12, 2016 5:10:03 PM PST
Hello everyone,
I have been doing some tests in order to apply the methodology for overflow correction covered in this year's paper by Jakubiec et al. using pcomb, as for example:
pcomb ‐e "lo=L ∗ Sang ∗ cosCor; L=179 ∗ li(1);
Sang=S(1); cosCor=Dy(1);" ‐o masked.hdr
> pvalue ‐d ‐b ‐h ‐H
> total
However, I keep getting "domain error" messages for both the S(n) and Dy(n) functions in my images. My first thought was something's wrong with the headers, but the view information looks correct having the full 180 degrees span of my Sigma lens.
Images are created by HDRgen using response function obtained by Photosphere, and are square-cropped, and resized to 800x800, and otherwise work fine, in terms of validating luminances or illuminances over Evalglare (at least the ones that don't contain the sun).
I'm getting the same domain errors in terms of solid angles when I try to extract a mapping of solid angles, using something like: cat image.hdr |pcomb -e 'solidangl=S(1); ro=omega;
go=omega; bo=omega' -o - > solid_angles.hdr
If anybody has any hints or ideas, I'd greatly appreciate it, as I think that with careful use (no specular reflections etc.), overflow correction can be a great solution over the alternatives for direct sun measurements.
Thanks in advance,
Iason Konstantzos
Hello Iason,
If you are following the steps in the paper <http://asd.sutd.edu.sg/dcc/papers/Jakubiec-Inanici-Van-Den-Wymelenberg_2016_Improving-the-Accuracy-of-Measurements-in-Daylit-Interior-Scenes-Using-HDR.pdf>, when you mask the image with the command,
pcomb ‐e "lo=mask ∗ li(1); mask=if(li(2)‐.1,1,0);" ‐o image.hdr ‐o
mask.hdr > image_masked.hdr
All of the nice things you put in the header before, like the view type (-vta -vv 180 -vh 180), get commented out. This keeps the luminance data but eradicates view information; therefore, the S(1) and Dy(1) functions don't work as they are view-dependent.
You need to somehow re-add the view information to the image header, which is a bit of a drag. We were doing everything in the paper with some really simple Python scripts. In case its helpful to you, I'm including a code snippet used below. Basically what it does is to write a new .hdr file with the header information applied on the third line.
# append view information
tmpfile = open("masked.hdr", "rb")
outfile = open("masked_with-view.hdr", "wb")
for (n,line) in enumerate(tmpfile):
outfile.write(line)
if n == 2:
outfile.write("VIEW= -vta -vh 180 -vv 180\n")
tmpfile.close()
outfile.close()
# remove tmp hdr file missing view information
os.remove("masked.hdr")
You can also achieve this manually with a text editor such as Notepad++ or whatever is your favorite as long as it can write in binary formats. The red part is what I inserted into the images.
#?RADIANCE
CAPDATE= 2015:02:04 09:30:51
GMT= 2015:02:04 01:30:51*
VIEW= -vta -vh 180 -vv 180*
(You will see that the commented information is identified as a
tab indent in the .hdr file.)
Best regards,
Alstan
···
On 11/13/2016 10:26 AM, Gregory J. Ward wrote:
Hi Iason,
Can you send the output of "getinfo" for the picture that you are feeding to pcomb? My suspicion is that you performed the cropping operation caused the view parameters are being shifted or modified and are not being recognized by pcomb. This will generate the domain error you are seeing.
Cheers,
-Greg
*From: *Iason Konstantzos <[email protected] <mailto:[email protected]>>
*Date: *November 12, 2016 5:10:03 PM PST
*
Hello everyone,
I have been doing some tests in order to apply the methodology for overflow correction covered in this year's paper by Jakubiec et al. using pcomb, as for example:
pcomb ‐e "lo=L ∗ Sang ∗ cosCor; L=179 ∗ li(1);
Sang=S(1); cosCor=Dy(1);" ‐o masked.hdr
> pvalue ‐d ‐b ‐h ‐H
> total
However, I keep getting "domain error" messages for both the S(n) and Dy(n) functions in my images. My first thought was something's wrong with the headers, but the view information looks correct having the full 180 degrees span of my Sigma lens.
Images are created by HDRgen using response function obtained by Photosphere, and are square-cropped, and resized to 800x800, and otherwise work fine, in terms of validating luminances or illuminances over Evalglare (at least the ones that don't contain the sun).
I'm getting the same domain errors in terms of solid angles when I try to extract a mapping of solid angles, using something like: /cat image.hdr |pcomb -e 'solidangl=S(1); ro=omega; go=omega; bo=omega' -o - > solid_angles.hdr/
If anybody has any hints or ideas, I'd greatly appreciate it, as I think that with careful use (no specular reflections etc.), overflow correction can be a great solution over the alternatives for direct sun measurements.
Thanks in advance,
Iason Konstantzos
_______________________________________________
HDRI mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/hdri