Search All of the Math Forum:
Views expressed in these public forums are not endorsed by
NCTM or The Math Forum.


Math Forum
»
Discussions
»
Software
»
comp.softsys.matlab
Notice: We are no longer accepting new posts, but the forums will continue to be readable.
Topic:
Image registration: linear vs. cubic interp and objective function minimization
Replies:
4
Last Post:
Jul 19, 2012 5:42 AM



Luca
Posts:
77
Registered:
6/6/12


Re: Image registration: linear vs. cubic interp and objective function minimization
Posted:
Jul 18, 2012 12:54 PM


"Matt J" wrote in message <ju6lb7$in0$1@newscl01ah.mathworks.com>...
> I'm skeptical that linear interpolation is causing "local minima".
Nevertheless I can see them! If I plot my objective function along one parameter there are some local minima, around integer values of translation. Extremely thin, but present. How deep they are depends on how much I've smoothed my original image.
>More likely, it is because the Hessian is zero almost everywhere (because things are piecewise linear) and that creates convergence issues.
That can also be!
> Also, are you doing your own gradient calculation, or are you letting FMINUNC/FMINCON do it by finite difference?
No, in this case I'm letting fminunc do its own calculation by finite differences. I already found out the gradient for a different problem and that was hard enough! Here it's only 11 parameters.
>Cubic spline interpolation would probably run much faster if you do your own gradient calculation because the analytical SSD gradient would involve only 2 image interpolation/transforming operations, whereas by finite diff, FMINCON/FMINUNC has to do 2 image transformations for every one of your parameters. Note that there are FEX tools which let you compute the derivatives of cubic interpolators, e.g., > > http://www.mathworks.com/matlabcentral/fileexchange/24996splinederivative
Can do! I'll look into it. If it works well enough in 3D and it's not impossible to use I'll implement it!
> Having said all that, I would also like to add that reinventing image registration software in MATLAB is probably a foolhardy thing to do, when there are a number of expertly written, freely available, well optimized C/C++ registration packages out there, like ITK or > > > http://bigwww.epfl.ch/thevenaz/affine/ > http://bigwww.epfl.ch/thevenaz/registration/ > > Your time would probably be better spent interfacing these with MATLAB. Believe me, that if I could go back in time, that's what I would do.
You're probably right. But there are lots of issues. Copyright, even if it's not the first one. Then... My main interest/profession is not programming! I must deal with it every day but it's not my field of expertise. I just use it as a tool to solve problems that I find in my work. I'm quite sick of learning new programs every day! I have enough troubles using matlab properly, let alone learning ITK from scratch!! Another deal is interfacing the code you've found with the stream of your program. For example SPM has a very good affine registration in its package. But... I have my matlab matrix, I do some preliminar operations in my GUI... and then? I save this matrix in Niftii, load it in SPM, compute the registration, save the result in niftii, load this file in matlab in some complicate way and then reload it in my original gui? Too difficult! And completely not user friendly! I want to be able to write something where the user uses a single GUI from the beginning to the end.
BTW, I've looked into ITK, but it was too hard, for me, to use it. They have no out of the box function to do what I need. If would have to modify some part of the registration and write from scratch all the other surroundings needed for my specific problem. All things I did extremely easilly in matlab! At the end you are so desperate that it becomes easier to write everything from scratch! (affine registration and ssd are well defined object that can be written with less than 100 lines of matlab code!)
Actually... I was extremely surprised not to find any package working with 3D matrix in the file exchange. (let alone the one by Dirk J. Kroon... that has nonworking affine registration and compiled C files that do not work correctly for cubic interpolation).



