[SciPy-User] fmin and step size

[Daniel Lepage]

FWIW, I've usually seen bundle adjustment done with the
Levenberg-Marquardt algorithm. If your data has any structure to it
(hard edges, corners, etc.) your optimization will be much faster if
you first detect these features and then solve for the transformation
using just these features (SIFT features are often used for this, but
may be overkill if your images are all roughly the same scale). OpenCV
provides some tools for this; see
<http://opencv.willowgarage.com/documentation/python/index.html> if
you want to call it from python (scikits.image also wraps some of
OpenCV).

HTH,
Dan Lepage

On Mon, Apr 4, 2011 at 5:54 PM, Christoph Gohlke <cgohlke at uci.edu> wrote:
>
>
> On 4/4/2011 2:18 PM, Chris Weisiger wrote:
>> Right, now my data slicing is working, I need to bend
>> scipy.optimize.fmin to my will. My goal here is to take two images of
>> the same sample taken from slightly different perspectives, and find the
>> transformation that causes one to overlap the other. The cost function
>> takes in four parameters (X translate, Y translate, rotation, zoom),
>> applies them to a 2D slice of data, and gets the correlation coefficient
>> between that transformed slice and a reference slice. By maximizing this
>> (minimizing 1 - correlation coefficient) I should be able to use fmin to
>> align the two slices precisely. I'm not worried about Z alignment at
>> this time. There are also other potential transformations (e.g. skew)
>> but their influence for our data is small enough that it can be ignored.
>>
>> The problem I'm seeing is that I don't have any influence over fmin's
>> initial step size. Its first step with rotation is .00025, when the
>> actual needed rotation is more than 1. Thus it always gets stuck in a
>> local minimum that is far from the actual minimum. Similarly, the zoom
>> parameter should never stray more than maybe .1 away from 1, but I
>> frequently end up with absurd zoom amounts (even negative zoom). Of
>> course I can eliminate that by making infinite cost for anything with
>> zoom greater than some cutoff, but I suspect then I'd just end up with a
>> local minimum along the cutoff edge.
>>
>> Some Googling suggested that I try fmin_powell and use the "direc"
>> parameter, but it's not clear how that's supposed to be used. If I pass
>> in e.g. [5, 5, 2, .01] then I would naively expect it to try only small
>> zoom changes but relatively large X/Y/rotate changes, but the first time
>> it calls the cost function with parameters different than the initial
>> guess of [52.0, 27.0, 0.0, 1.0], I get [57.0, 32.0, 5.0, 6.0], so it's
>> stepping 5 (the largest value in direc) in all four parameters.
>>
>> Any advice would be lovely.
>>
>> -Chris
>>
>>
>
> If skew is not relevant you could use "An FFT-based technique for
> translation, rotation, and scale-invariant image registration"
> <http://dx.doi.org/10.1109/83.506761>.
>
> Christoph
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>