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