[HDRI] fisheye-correction

Discussion:

Jan Wienold

2017-06-27 14:06:03 UTC

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

Gregory J. Ward

2017-06-27 16:13:23 UTC

Permalink

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

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 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

Jan Wienold

2017-06-27 17:00:50 UTC

Permalink

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

Post by Gregory J. Ward
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

*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 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
https://www.radiance-online.org/mailman/listinfo/hdri

Gregory J. Ward

2017-06-27 22:57:06 UTC

Permalink

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

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.
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

Post by Gregory J. Ward
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

Jan Wienold

2017-06-28 14:59:13 UTC

Permalink

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

Post by Gregory J. Ward
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
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
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

*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.
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

Post by Gregory J. Ward
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

*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 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
https://www.radiance-online.org/mailman/listinfo/hdri

Gregory J. Ward

2017-06-28 19:17:42 UTC

Permalink

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...

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
-------- Forwarded Message --------
Date: Wed, 28 Jun 2017 16:59:13 +0200
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.
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.

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.

Thx for the help.
Cheers
Jan
+++++++++++++++++++++++++++++++

Post by Gregory J. Ward
Hi Jan,
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.
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

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.
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

Gregory J. Ward

2017-06-29 08:18:52 UTC

Permalink

Hi Jan,

I spent some more time on this on my flight, and realized that the problem is with pcomb, not any of your calculations or assumptions.

Basically, pcomb operates by keeping a certain cache of scanline buffers above and below the current one, and is therefore limited as to how far it can reach up & down in y when using the offsets that fisheye_corr.cal relies on to distort the input image. I actually increased this buffer reach from whatever it was to +/- 63 scanlines. Unfortunately, this still isn't enough in your 15000x15000 image (or even the original 5000x5000 one). Our tests were not performed on such large images. I suppose I should increase src/px/pcomb.c's WINSIZ constant further, and just accept the memory cost. Originally, I was only thinking of local resampling kernels and the like.

What happens when you ask for a pixel that is too far up or down in y, it gives the closest scanline it has, which gives the wrong distortion in this case. If your sun were moving right-left instead of top-bottom, you wouldn't suffer this limitation of pcomb. I verified this by passing your image through protate prior to pcomb:

protate sk_$i.hdr | pcomb -f fisheye_corr.cal -o - | getinfo -a "VIEW= -vta -vh 180 -vv 180" >sk_$i"corr.hdr"

We then get good agreement using your comparison method, within a 2% or so, which is about what I would expect using an 8-bit mantissa allowing for cumulative error.

Cheers,
-Greg

Date: June 28, 2017 7:59:13 AM PDT
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.
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?
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

Jan Wienold

2017-06-29 10:50:26 UTC

Permalink

Hi Greg,

thank you so much - you solved the paradoxon of the solid angle ;-):-)!
I was already doubting the first law of thermodynamics... I'm glad it
is just a too small buffer setting in the pcomb-code.

Since several people experience actually discrepancies between measured
illuminance and calculated from the image (and actually all of them have
full frame cameras with a large resolution), it would be good to know
WHEN you updated pcomb to the WINSIZ to 63. This might be an partial
explanation for the problems they experienced. Many people work on
windows and probably still use an old pcomb version and just downloaded
the fisheye_corr.cal.

Also it would be good to know until which image size the current version
works properly.
For the 15000 image, it was not just at the border where the deviation
occurred - also in the centre there was a deviation of the solid angle
of more than 20%.

I will do a new test with several resolutions and different WINSIZ
settings, as soon as I'm back from my mandatory safety training... and
sure 2% deviation is totally fine.

Thanks again for the help!

Cheers
Jan

Post by Gregory J. Ward
Hi Jan,
I spent some more time on this on my flight, and realized that the
problem is with pcomb, not any of your calculations or assumptions.
Basically, pcomb operates by keeping a certain cache of scanline
buffers above and below the current one, and is therefore limited as
to how far it can reach up & down in y when using the offsets that
fisheye_corr.cal relies on to distort the input image. I actually
increased this buffer reach from whatever it was to +/- 63 scanlines.
Unfortunately, this still isn't enough in your 15000x15000 image (or
even the original 5000x5000 one). Our tests were not performed on
such large images. I suppose I should increase src/px/pcomb.c's
WINSIZ constant further, and just accept the memory cost. Originally,
I was only thinking of local resampling kernels and the like.
What happens when you ask for a pixel that is too far up or down in y,
it gives the closest scanline it has, which gives the wrong distortion
in this case. If your sun were moving right-left instead of
top-bottom, you wouldn't suffer this limitation of pcomb. I verified
protate sk_$i.hdr | pcomb -f fisheye_corr.cal -o - | getinfo -a "VIEW=
-vta -vh 180 -vv 180" >sk_$i"corr.hdr"
We then get good agreement using your comparison method, within a 2%
or so, which is about what I would expect using an 8-bit mantissa
allowing for cumulative error.
Cheers,
-Greg

*Date: *June 28, 2017 7:59:13 AM PDT
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.
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
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

_______________________________________________
HDRI mailing list
https://www.radiance-online.org/mailman/listinfo/hdri

Jan Wienold

2017-06-29 18:53:26 UTC

Permalink

Hi Greg,

I tested now again for 5000x5000 and 15000x15000 two WINSIZ setting (127
and 1027):

for 127 I get a max deviation of the patch solid angle of 11% for the
5000x5000 and 18% for the 15000x15000.

for the 1027 : 8% for the 5000x5000 and 5% 15000x15000. The memory usage
was in both case not really big - never more than 900kB (compared to
evalglare this is nothing... the 15000x15000 resulted in 14GB..)

I think this is fine now... for many angles the error is also much
smaller. I'm glad we solved this problem - thanks again!

I have to say that my previous table was generated with a pcomb version
from the 5.0 release, using a setting of 64 for WINSIZ...

I was not aware of the needed update of pcomb when using the
fisheye_corr.cal. I'm usually running the official release on our server
for "production" for all users and not the head release - but maybe I
should change this philosophy.

Cheers

Jan

_______________________________________________
HDRI mailing list
https://www.radiance-online.org/mailman/listinfo/hdri

Gregory J. Ward

2017-06-30 01:37:54 UTC

Permalink

Hi Jan,

Thanks for the excellent follow-up on this. I should have thought about the pcomb buffer issue earlier, as David Geisler-Moroder and I did identify it early on as a potential source of error late last July. I believe I updated the buffer size at that time, though I can't check because I am blocked from radiance-online.org from where I am in Myanmar, or else the site is down at the moment.

As to watching for important changes in Radiance, I usually put them in the ReleaseNotes document, though I didn't mention this one it seems. You can save the link below and check it periodically, or I can put you on the list of e-mails to get CVS check-in notices if you really want to hear what's going on.

http://www.radiance-online.org/cgi-bin/viewcvs.cgi/ray/doc/notes/ReleaseNotes

As for pcomb, I am thinking about redesigning it so I don't have this buffer limitation. I could borrow the LRU scanline replacement code I developed for findglare and avoid this issue altogether. Simply increasing the buffer size isn't a full solution, as we would need to increase it to the full image size to avoid all such bugs, which would be prohibitive if you were to give pcomb a large number of images....

Cheers,
-Greg

Date: June 30, 2017 1:23:26 AM GMT+06:30
Hi Greg,
for 127 I get a max deviation of the patch solid angle of 11% for the 5000x5000 and 18% for the 15000x15000.
for the 1027 : 8% for the 5000x5000 and 5% 15000x15000. The memory usage was in both case not really big - never more than 900kB (compared to evalglare this is nothing... the 15000x15000 resulted in 14GB..)
I think this is fine now... for many angles the error is also much smaller. I'm glad we solved this problem - thanks again!
I have to say that my previous table was generated with a pcomb version from the 5.0 release, using a setting of 64 for WINSIZ...
I was not aware of the needed update of pcomb when using the fisheye_corr.cal. I'm usually running the official release on our server for "production" for all users and not the head release - but maybe I should change this philosophy.
Cheers
Jan

Post by Gregory J. Ward
Hi Jan,
I spent some more time on this on my flight, and realized that the problem is with pcomb, not any of your calculations or assumptions.
Basically, pcomb operates by keeping a certain cache of scanline buffers above and below the current one, and is therefore limited as to how far it can reach up & down in y when using the offsets that fisheye_corr.cal relies on to distort the input image. I actually increased this buffer reach from whatever it was to +/- 63 scanlines. Unfortunately, this still isn't enough in your 15000x15000 image (or even the original 5000x5000 one). Our tests were not performed on such large images. I suppose I should increase src/px/pcomb.c's WINSIZ constant further, and just accept the memory cost. Originally, I was only thinking of local resampling kernels and the like.
protate sk_$i.hdr | pcomb -f fisheye_corr.cal -o - | getinfo -a "VIEW= -vta -vh 180 -vv 180" >sk_$i"corr.hdr"
We then get good agreement using your comparison method, within a 2% or so, which is about what I would expect using an 8-bit mantissa allowing for cumulative error.
Cheers,
-Greg