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