Am 27.07.2018 um 22:55 schrieb [email protected]:
The limitations also make it necessary that hugin / panotools have to
provide different lens models, as rectangular and fisheye lenses
cannot be unified. With two more odd polynomials they could. It is
amazing how well a Taylor series with four odd terms can approximate
tan()...
The abc lens correction model is not used to correct fisheye distortion
directly. Instead it is used to correct the deviation from an ideal
fisheye. In original panotools this was the R = f * theta model only.
hugin added four other fisheye-like models, you can choose from the lens
type dropdown.
You criticized that the current formula is phenomenology only. But
that's what it's all about. Panorama stitching is about solving real
problems, not providing the best theoretical model. The current model
showed it's abilities by stitching millions of panoramas (literally) and
where it failed to do so properly it was due to other factors, not a
theoretically sub-optimal lens correction model.
Parallax is the most common problem, chromatic aberration and lens blur
are others. Not to speak from too little features for control points,
incapable control point generators and last but not least user inability.
As long as you don't provide an error estimation you only can start to
show that the lens correction model is insufficient if you ruled out
other reasons for alignment problems. First was parallax. Then I showed
that the current model can correct your images well into the corners,
provided you put enough control points there, even though there is heavy
lens blur. This shows that the model actually can correct your images,
if you feed it the right parameters.
Getting those parameters is the next problem. You probably understand
better than me how the optimizer works and why it sometimes doesn't get
the correct parameters, although there are seemingly enough control
points. A more sophisticated model would suffer from this problem
probably to a heavier extent due to overfitting.
While under ideal conditions it might be possible to place enough points
throughout the overlap to satisfy a sophisticated lens correction this
is not possible for most real world panoramas. The optimizer must be
still able to generate reliable results, even if there are insufficient
points. I guess, Helmut Dersch choose this model because it generates
stable optimizer results (you can ask him, he's still active:
https://webuser.hs-furtwangen.de/~dersch/ ) BTW.: Furtwangen is a true
university (Hochschule) now, it was a Fachhochschule years ago.
As far as I know Autopano Pro uses a lens correction model like you
propose. But Autopano is not famous for it's better stitched panoramas.
Both other big players (hugin and PTGui) use the panotools model and are
equally successful.
With all that one shot solutions (theta, gear360 etc) and drone cameras
panorama shooting has reached the main stream. The big problem there is
not lens correction, but unavoidable parallax. This is the next hurdle
panorama stitching needs to take, not lens correction.
--
Erik Krause
http://www.erik-krause.de
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/4953fb77-8bc4-654b-b47f-a87b44359ef8%40gmx.de.
For more options, visit https://groups.google.com/d/optout.
