[CREATE] [hugin-ptx] Re: Lens correction database

[Pablo d'Angelo]

Hi Bruno,


Bruno Postle wrote:
> On Fri 11-May-2007 at 00:48 +0200, Pablo d'Angelo wrote:
>> The idea is that people who want to correct their lens take some 
>> test shots, and use hugin to estimate the required calibration 
>> parameters. These are then sent (hugin projects and original 
>> images) to a lens database coordinator, where they are checked for 
>> plausibility and incorporated into the database.
> 
> This is a lot of ongoing work for whoever does this checking, it's 
> also a repetitive task without much reward and requires considerable 
> user input too.  Another way of going about this might be do it all 
> with code:
> 
> hugin is the ideal tool for calibrating lenses, but there are lots 
> of ways of doing this within hugin, most of them are incidental to 
> the main task of stitching panoramas.
> 
> It ought to be possible to be able to upload lens/camera parameters 
> directly from hugin, perhaps via a simple http POST to a preset but 
> configurable URI.
 >
> During the stitching process, hugin evaluates the quality of the 
> optimisation by calculating error distances, why not improve this 
> with some extra checks and give the user an option to upload the 
> results from _all_ good optimisation passes.

I like this idea.

This could happen through uploading an anonymized pto file (image filenames 
etc. removed) to some central server. Since often multiple optimisation will 
be done before the final panorama is created, it might be a better idea to
upload the data when the user actually renders the panorama.

> eg. a field of view calculation is only credible if field of view 
> was actually optimised and there are a large number of well-spread 
> control points involved with a low error distance.
> 
> Then the task of compiling the distributable database is statistical 
> analysis of this collected raw data, removing outliers, averaging 
> and interpolating.

The drawback of deriving these parameters from ordinary panoramas are 
inaccuracies due to parallax errors, moving objects etc. I suspect many
users of hugin are satisfied with panoramas that do not lead to a good 
calibration. So some effort needs to be spend on determining a good way
to reject those. Maybe some simple rules based on distribution of the points 
and the might be enough, but that needs to be evaluated.

The good thing is that both the "manual" calibration approach and this 
upload based approach can be combined :-) So we can start with
the calibration based one, and later add the more automatic, upload
based approach.

ciao
   Pablo