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]
https://www.radiance-online.org/mailman/listinfo/hdri
_______________________________________________
HDRI mailing list
[email protected]
https://www.radiance-online.org/mailman/listinfo/hdri
