# fisheye-correction

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

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

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]

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.

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

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]

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

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

···

From: Jan Wienold <[email protected]>
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.

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

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

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

···

On 29/06/17 10:18, Gregory J.Ward wrote:

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

*From: *Jan Wienold <[email protected] <mailto:[email protected]>>

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

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

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

_______________________________________________
HDRI mailing list
[email protected]

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

···

On 29/06/17 10:18, Gregory J.Ward wrote:

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

*From: *Jan Wienold <[email protected] <mailto:[email protected]>>

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

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

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

_______________________________________________
HDRI mailing list
[email protected]

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.

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

···

From: Jan Wienold <[email protected]>
Date: June 30, 2017 1:23:26 AM GMT+06:30

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

On 29/06/17 10:18, Gregory J.Ward wrote:

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

From: Jan Wienold <[email protected]>
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.

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

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