http://imagej.273.s1.nabble.com/registering-a-stack-advice-needed-tp5020546p5020563.html
> own. I don't really want to do that, but I suppose it's an option.
> Thanks for your comments.
>
> I've been using SIFT in a number of projects.
>
> Limiting it to "translation only" eliminates the disasters,
> but I really need a SMALL amount of scaling and rotation.
>
> The core question is: how can I get a small amount
> of scaling and rotation, without giving SIFT license
> to rotate by 90deg?
>
> I'm willing to try other methods. My constraints are:
> *ImageJ implementation
> *translation, scale, rotation, perhaps elastic deformation - but all
> LIMITED
> *automatic (no user interaction)
>
> To be clear, the images in the current stacks are not in any particular
> order - there is no systematic drift. Just a bunch of images of the
> same scene, taken at different times using different imaging modalities.
>
> The gray-level differences are major - but the primary source of useful
> registration features are uniformly DARK compared with the surrounding
> area.
>
> In a way, this is not unlike ancient stereo-pair matching problems from the
> 1970's - the two images may vary in perspective, but matching features
> should lie in a small horizontal band.
>
> Hmmm...I'm drifting perilously close to feeling the urge to roll my own.
> I don't really want to do that, but I suppose it's an option.
>
> SIFT does so many other things very well; I'm loathe to abandon it.
>
>
> --
> Kenneth Sloan
>
[hidden email]
> Vision is the art of seeing what is invisible to others.
>
>
>
>
>
> > On 23 Apr 2018, at 03:21 , Philippe CARL <
[hidden email]>
> wrote:
> >
> > Dear Kenneth,
> > I had/have similar applications for which I took quite some time before
> > finding a stable and reproducible solution.
> > So first I started with the TurboReg and StackReg solutions:
> >
http://bigwww.epfl.ch/thevenaz/turboreg/> >
http://bigwww.epfl.ch/thevenaz/stackreg/> > to later on move over the JavaSIFT:
> >
http://fly.mpi-cbg.de/~saalfeld/Projects/javasift.html> >
https://imagej.net/Feature_Extraction> > which more often gave me better results but there were cases (similarly
> to
> > what you reported) where for whatever reason the algorithm was giving
> crazy
> > results.
> > And now I use the Slice Alignment plugin:
> >
https://sites.google.com/site/qingzongtseng/template-matching-ij-plugin> > which in my case (I have nevertheless to precise that I have only
> > translation transformations, i.e. no scaling and rotation) is giving me
> good
> > results.
> > And given that this Slice Alignment plugin is only applying translation
> > transformations, I would recommend you to try to first apply it on your
> > pictures followed then by the SIFT algorithm in order to take care the
> > rotation and scaling transformations.
> > Good luck!!!
> > My best regards,
> > Philippe
> >
> > Philippe CARL
> > Laboratoire de Bioimagerie et Pathologies
> > UMR 7021 CNRS - Université de Strasbourg
> > Faculté de Pharmacie
> > 74 route du Rhin
> > 67401 ILLKIRCH
> > Tel : +33(0)3 68 85 41 84
> >
> > -----Message d'origine-----
> > De : ImageJ Interest Group [mailto:
[hidden email]] De la part de
> > Kenneth Sloan
> > Envoyé : lundi 23 avril 2018 03:38
> > À :
[hidden email]
> > Objet : registering a stack - advice needed
> >
> > I have an application which needs to do MINOR corrections to images in
> > a Stack in order to register them. The modifications involve
> TRANSLATION,
> > some ROTATION, and SCALING (perhaps anisotropic).
> >
> > So far, SIFT has been what I've been using.
> >
> > My problem is that all of the above transformations are small - but I
> > don't know how to limit the allowed ROTATION (in particular). ROTATION
> > is the problem child, because the one way that SIFT produces ridiculous
> > results is to rotate a given image by 90deg - presumably because it finds
> > some accidental arrangement of features that makes it look like this is a
> > good
> > idea.
> >
> > SIFT allows you to specify a limit on the number of pixels to MOVE - but
> > this does not
> > seem to constrain the ROTATION.
> >
> > So...bottom line: I'm looking for advice on other methods to try.
> >
> > The key requirement is that I'd like to allow TRANSLATION, anisotropic
> > SCALE,
> > and ROTATION - even arbitrary local warping. BUT, I would also like to
> put
> > strict limits on "how much" of each is allowed.
> >
> > As a rough guideline - I'd say that I need to limit:
> >
> > TRANSLATION - no more than 25 pixels (in a 750x750 image)
> > SCALE - in the range [.9, 1.1] in x and y (independent)
> > ROTATION - no more than 10deg
> >
> > Now...I naively thought that specifying "25 pixels max" would do the
> trick,
> > but I occasionally see results where the image is rotated 90deg, and
> > "matching features"
> > are hundreds of pixels apart. Is this expected? or is it a bug?
> >
> >
> > I can supply an example pair of images that exhibits this behavior - on
> > request.
> >
> >
> > My current workaround is to specify "translation only" with a maximum of
> 25
> > pixels of motion,
> > and am living with the slight inaccuracies due to the lack of scaling &
> > rotation. As noted
> > above, the (spatial) differences between images in the stack are small,
> so
> > this is
> > not a tragedy. [the gray-scale differences can be huge - this is
> > "multi-modal imaging".
> >
> > --
> > Kenneth Sloan
> >
[hidden email]
> > Vision is the art of seeing what is invisible to others.
> >
> > --
> > ImageJ mailing list:
http://imagej.nih.gov/ij/list.html> >
> > --
> > ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>