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