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.
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?
Below you see the result of the calculations in 5° steps (the angle is
counted from the border to the center):
angle No of Pixels of patch before remapping No of Pixels of patch
after remapping solid_angle_before_remapping (equisolidangle)
solid_angle_after_remapping (equidistant) Deviation of solid angle
[°] [sr] [sr] [%]
5 2028 2028 7.21E-05 6.00E-05 17%
10 1864 1928 6.63E-05 5.79E-05 13%
15 1778 1850 6.32E-05 5.77E-05 9%
20 1695 1772 6.03E-05 5.74E-05 5%
25 1622 1700 5.77E-05 5.69E-05 1%
30 1562 1652 5.55E-05 5.69E-05 -2%
35 1485 1590 5.28E-05 5.58E-05 -6%
40 1431 1548 5.09E-05 5.51E-05 -8%
45 1402 1524 4.98E-05 5.54E-05 -11%
50 1358 1484 4.83E-05 5.49E-05 -14%
55 1321 1448 4.70E-05 5.46E-05 -16%
60 1310 1436 4.66E-05 5.50E-05 -18%
65 1271 1402 4.52E-05 5.40E-05 -20%
70 1259 1388 4.48E-05 5.41E-05 -21%
75 1254 1384 4.46E-05 5.44E-05 -22%
80 1239 1366 4.41E-05 5.41E-05 -23%
85 1237 1364 4.40E-05 5.43E-05 -23%
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.
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:
Anglemodified/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] <mailto:[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.
angle [°] Pix-Sun-org Pix-Sun-corr Pixel-Ratio solid angle vta
solid angle equi-dist. Solid-Angle-Ratio
5 225 225 1.00 2.654E-07 3.20E-07 0.83
15 204 204 1.00 2.915E-07 3.20E-07 0.91
25 189 187 1.01 3.157E-07 3.20E-07 0.99
45 167 159 1.05 3.548E-07 3.20E-07 1.11
75 151 138 1.09 3.902E-07 3.20E-07 1.22
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
On 27/06/17 18:13, Gregory J. Ward wrote:
Hi Jan,
What is the resolution of your image, and how many pixels does the
sun cover? Could this be simply due to quantization error? The
function moves pixels around, not changing their magnitude, and the
accuracy can never be better than +/- 1/(number of pixels in sun).
Cheers,
-Greg
*From: *Jan Wienold <[email protected] <mailto:[email protected]>>
*Date: *June 27, 2017 7:06:03 AM PDT
Hi all,
I'm a bit puzzled by the result of applying fisheye_corr.cal to an
fish-eye image.
I have a simple example:
I created a fish-eye image with a sun at 5 degree altitude and kept
the sky black (just the sun). Let's assume now this image is
equi-solid-angle and we want to transfer it to a equi-distant (-vta).
For this I applied /pcomb -f fisheye_corr.cal -o fisheye.hdr >
corrected.hdr/.
In the next step I counted the amount of pixels for the sun in the
two images. They are exactly the same! What has changed is only
the position in the image. Neither the size of the sun nor the
luminance has changed.
But: The difference between the solid angles of a pixel at 85° from
the center between equi-solid-angle and equi-distant projection is
around 20%! (in my example the solid angle per pixel for a
5000x5000 image at 85° is: 3.2e-7sr vs 2.58e-7sr)
I would have expected also a change in size, accounting for the
difference in solid angles per pixel for the different projection
methods, the luminance of course should be the same.
Am I doing sth. wrong?
thx for the help.
Jan
_______________________________________________
HDRI mailing list
[email protected]
https://www.radiance-online.org/mailman/listinfo/hdri
_______________________________________________
HDRI mailing list
[email protected]
https://www.radiance-online.org/mailman/listinfo/hdri
