Hi Jan,
The limit on attachments is pretty small (50 KBytes or so). I'm the HDRI list administrator, though, so was able to "pass" your message. (Posters, please reply to this message rather than the original so as not to run up against the same roadblock.)
I am putting my comments inline, below. Hope that's not too confusing or hard to read...
From: Jan Wienold <[email protected]>
Date: June 28, 2017 8:01:42 AM PDT
opps, this message did not go through, the image was too big, so I send it directly to you.
cheers
Jan
Date: Wed, 28 Jun 2017 16:59:13 +0200
From: Jan Wienold <[email protected]>
To: [email protected]
Hi Greg,
thanks for this - it helps a bit, but I think I'm still doing sth wrong.
Originally I wanted to know the influence of mapping, if there is a high intense glare source at the border. I wanted to know, how much the error is, when a equidsolid-angle image is treated as vta without mapping. Using gensky was just an easy way to create a "patch" at the border of an image. If the sun disk is represented correctly or not, does not matter to me, I just want to see how this patch is mapped.
Then in the next step I realized that the number of pixels (between original and mapped) did not change for the 5° position and then I wanted to investigate a bit more - that's where I'm still stuck.
Now I have re-run my script generating 15000x15000 images.
What I do now:
1. Original image (assumed as equisolidangle): I calculate the solid angle per pixel simply by 2*pi/no_pixel_hemisphere (for a 15000x15000 this is 176714668). Then I count the pixels in that image for the patch and multiply by this value. So I get as result the solid angle of the patch in the original image.
2. Mapped image: I calculate the solid angle of the patch by your pcomb command (I also verified it by evalglare and got the same value +-0.2%, it was just 10min slower per image using evalglare;-)). The mapped image has a valid -vta view heady entry.
This part seems fine. I'm glad our calculations agree. There will be considerable round-off error from pcomb, which uses the RGBE format with its 8-bit mantissas.
Actually I expected them to be the same, but in my results they are not. I really don't know what I'm doing wrong. For the remapping, what does pcomb "expect" for the view entry in the header in the original image (which is equisolid)? I used -vta -vv 180 -vh 180. Maybe this is a mistake?
This is what I was trying to say about pcomb, but didn't explain very well. Since there is no standard Radiance view for "equi-solid-angle" projections, there is no way for pcomb to compute the correct solid angle per pixel in this comparison. If we had such a view, we wouldn't need fisheye_corr.cal.
Below you see the result of the calculations in 5° steps (the angle is counted from the border to the center):
Graphically it looks like this:
In my opinion the curves should more or less match, the "dropping" is just related to my "lazy" generation of the patch by gensky, but this is not important.
I am sorry for the short answer, but my flight is just boarding now. I will have to think on this a bit more.
···
-------- Forwarded Message --------
Thx for the help.
Cheers
Jan
+++++++++++++++++++++++++++++++
On 28/06/17 00:57, Gregory J. Ward wrote:
Hi Jan,
How are you calculating the solid angles in your table? I assume these are per-pixel, since the total should equal the actual solid angle of a 0.5° source. I use the following to calculate total solid angle as understood by pcomb:
pcomb -e 'lo=if(gi(1)-10,S(1),0)' input.hdr | pvalue -pG -h -H -d | total
This simply adds up all the solid angles corresponding to pixels greater than 10, which will just be the sun in your case.
I've noticed there's actually about a +/-5% error in the disk size using a 5000x5000 pixel rendering. If you increase this to 15000x15000, you can get this error down below 1% or so. This error stems from the on/off nature of the boundary and random sampling. To get more consistent results, I also recommend adding "-pj 0" to your rpict line.
What kind of differences are you actually expecting between these two calculations? Since you are using rpict to render the sky, the "uncorrected" fisheye is the one that will add up to the correct solar solid angle, which is about 6e-5 for a 0.5° source. The above pcomb command should give you this value for all of your sun positions in the uncorrected versions. I confirmed this from the 15000x15000 runs.
The "corrected" images will still be interpreted by pcomb as having "-vta" projections, so will yield incorrect estimates of the sun's solid angle. Had you fed them actual fisheye captures using an equi-solid-angle lens, then presumably they would end up agreeing again. Off-hand, I don't know how to generate such test images, but when I run the 15000x15000 images through the above pcomb command, I get the following ratios for the new over the original solid angles:
Angle modified/original
5° 1.00
15° 0.97
25° 0.96
45° 0.93
75° 0.91
I don't know what to do with this, however.
Cheers,
-Greg
From: Jan Wienold <[email protected]>
Date: June 27, 2017 10:00:50 AM PDT
Hi Greg,
the image is 5000x5000 pixels.
The sun is 225 pixels for the original and the corrected for the 5° position. I also tested other positions - the results are in the table below.
According to this, the ratio of the "sun" pixels change after 25°, which is the angle when the solid-angle for vta gets larger than the solid-angle of the equi-solid-angle projection.
In the table the column two and three are the amount of pixels for the sun for the two images, column 4 is a ratio for those two, the last column is the ratio of the two solid angles.
FYI, these are the scripts for producing the files:
for i in 5 15 25 45 75; do gensky -ang $i 0 +s >sk_$i.rad; oconv -f sk_$i.rad >sk_$i.oct; rpict -vp 0 0 0 -vd 0 0 1 -vu 0 -1 0 -vta -vv 180 -vh 180 -x 5000 -y 5000 -dc 0 -dj 0 -ps 0 sk_$i.oct >sk_$i.hdr & done
for i in 5 15 25 45 75; do pcomb -f /usr/local/radiance/lib/fisheye_corr.cal -o sk_$i.hdr | getinfo2 -a "VIEW= -vta -vh 180 -vv 180" >sk_$i"corr.hdr"; done
The solid angles I calculated with pcomb (and checked also with evalglare). The amount of pixels I calculated with pvalue -H -h -o -b image.hdr |awk '{if ($3>1) print $0}'|wc -l and checked also with evalglare.
cheers
Jan
