hugin-devs team mailing list archive
-
hugin-devs team
-
Mailing list archive
-
Message #00972
[Bug 696668] Re: smart optimisation in the assistant is non-optimal
** Description changed:
The stages of the existing smart optimisation that happen when you use
Align... in the Assistant tab are:
First it optimises just positions, if the final panorama is 360° then it
will optimise field of view of the photos in the next step.
It looks at the spread of control points and either optimises just 'b'
or 'a,b,c' lens parameters depending on this spread.
If the photos are wider than 60° then d,e will be optimised too.
It does some checks with the result of this second step, if the
v,a,b,c,d,e parameters are not credible then it backs out and optimises
the project again but with less parameters.
(from SmartOptimise::smartOptimize in
src/hugin_base/algorithms/optimizer/PTOptimizer.cpp)
Looking at this code, some of the default thresholds and heuristics
could be better:
I think it is safe to optimise field of view if the panorama is greater
than about 150° (and if the panorama is not a single stack).
The a,b,c thresholds are much too high.
High a,b,c values can be an indication that the lens type is incorrect,
perhaps at this point it would be useful to run another optimisation
with fisheye/rectilinear and see which gives the best results.
The straighten function is run but this doesn't work unless there is
some horizontal spread of photos (i.e. a vertical panorama fails) see
Bug #679282 (sf-2851956)
a,b,c,d,e should never be optimised when the initial alignment indicates
that we have a single stack (i.e. the assistant is currently broken with
all single stack projects).
The d,e threshold should be a proportion of the photo width rather than
a pixel value.
Photometric optimisation is always performed, but this is almost always
a mess unless there is a good geometrical alignment. So if the alignment
is bad, then photometric optimisation should be skipped.
+
+ Photometric alignment needs significant vignetting and/or bracketed
+ exposures to be able to calculate the camera response curve, 'bad'
+ response curves result in 'banding' or 'posterisation' artefacts. The
+ Assistant tab could be refined to back-out of photometric alignment if
+ the vignetting turns out to be low or there is no EV variation.
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/696668
Title:
smart optimisation in the assistant is non-optimal
Status in Hugin - Panorama Tools GUI:
Triaged
Bug description:
The stages of the existing smart optimisation that happen when you use
Align... in the Assistant tab are:
First it optimises just positions, if the final panorama is 360° then
it will optimise field of view of the photos in the next step.
It looks at the spread of control points and either optimises just 'b'
or 'a,b,c' lens parameters depending on this spread.
If the photos are wider than 60° then d,e will be optimised too.
It does some checks with the result of this second step, if the
v,a,b,c,d,e parameters are not credible then it backs out and
optimises the project again but with less parameters.
(from SmartOptimise::smartOptimize in
src/hugin_base/algorithms/optimizer/PTOptimizer.cpp)
Looking at this code, some of the default thresholds and heuristics
could be better:
I think it is safe to optimise field of view if the panorama is
greater than about 150° (and if the panorama is not a single stack).
The a,b,c thresholds are much too high.
High a,b,c values can be an indication that the lens type is
incorrect, perhaps at this point it would be useful to run another
optimisation with fisheye/rectilinear and see which gives the best
results.
The straighten function is run but this doesn't work unless there is
some horizontal spread of photos (i.e. a vertical panorama fails) see
Bug #679282 (sf-2851956)
a,b,c,d,e should never be optimised when the initial alignment
indicates that we have a single stack (i.e. the assistant is currently
broken with all single stack projects).
The d,e threshold should be a proportion of the photo width rather
than a pixel value.
Photometric optimisation is always performed, but this is almost
always a mess unless there is a good geometrical alignment. So if the
alignment is bad, then photometric optimisation should be skipped.
Photometric alignment needs significant vignetting and/or bracketed
exposures to be able to calculate the camera response curve, 'bad'
response curves result in 'banding' or 'posterisation' artefacts. The
Assistant tab could be refined to back-out of photometric alignment if
the vignetting turns out to be low or there is no EV variation.
References