[SciPy-User] fmin and step size

Chris Weisiger cweisiger at msg.ucsf.edu
Mon Apr 4 18:23:30 EDT 2011


I should have thought of this. Obvious in hindsight. I'll give it a shot.
The FT-based alignment also looks interesting, Christoph; I'll have to take
a look at it.

Thanks!

-Chris

On Mon, Apr 4, 2011 at 2:46 PM, David Baddeley
<david_baddeley at yahoo.com.au>wrote:

> Silly suggestion, but can you rescale the parameters so that they're all in
> the same ballpark (eg express translation as a fraction of the total image
> width, and rotation as a fraction of 2pi)?
>
> cheers,
> David
>
> ------------------------------
> *From:* Chris Weisiger <cweisiger at msg.ucsf.edu>
> *To:* SciPy Users List <scipy-user at scipy.org>
> *Sent:* Tue, 5 April, 2011 9:18:07 AM
> *Subject:* [SciPy-User] fmin and step size
>
> 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
>
>
>
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20110404/89b58b38/attachment.html>


More information about the SciPy-User mailing list