Greg, Alstan,
You were both right; I just realized that the fact I saw the view info in the header didn't mean that pcomb did recognize it. It was indeed indented therefore ignored. Putting it in back in the third row made everything work like a charm! Thank you both for your prompt and enlightening responses! Best Iason ---------------------------------------------------------------------- Message: 1 Date: Sun, 13 Nov 2016 01:10:03 +0000 From: Iason Konstantzos <[email protected]> To: "[email protected]" <[email protected]> Subject: [HDRI] Domain errors with incidence and solid angles during overflow correction Message-ID: <sn2pr0801mb225598c1a75ef9042af1bdfcc6...@sn2pr0801mb2255.namprd08.prod.outlook.com> Content-Type: text/plain; charset="iso-8859-1" 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.radiance-online.org/pipermail/hdri/attachments/20161113/6b89cfb5/attachment-0001.html> ------------------------------ Message: 2 Date: Sat, 12 Nov 2016 18:26:51 -0800 From: "Gregory J. Ward" <[email protected]> To: High Dynamic Range Imaging <[email protected]> Subject: Re: [HDRI] Domain errors with incidence and solid angles during overflow correction Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.radiance-online.org/pipermail/hdri/attachments/20161112/243b2db9/attachment-0001.html> ------------------------------ Message: 3 Date: Sun, 13 Nov 2016 13:34:02 +0800 From: "J. Alstan Jakubiec" <[email protected]> To: [email protected] Subject: Re: [HDRI] Domain errors with incidence and solid angles during overflow correction Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8"; Format="flowed" 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>, Full - Improving the Accuracy of Measurements in Daylit ...<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> asd.sutd.edu.sg PLEA 2016 Los Angeles - 36th International Conference on Passive and Low Energy Architecture. Cities, Buildings, People: Towards Regenerative Environments 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.radiance-online.org/pipermail/hdri/attachments/20161113/054e271c/attachment.html> ------------------------------ Subject: Digest Footer _______________________________________________ HDRI mailing list [email protected] http://www.radiance-online.org/mailman/listinfo/hdri ------------------------------ End of HDRI Digest, Vol 86, Issue 1 ***********************************
_______________________________________________ HDRI mailing list [email protected] http://www.radiance-online.org/mailman/listinfo/hdri
