registering a stack - advice needed

[Kenneth Sloan-2]

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

[Kenneth Sloan-2]

I was hoping for an ImageJ-based option.  This application is heavily embedded in ImageJ.

But, thanks.

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

> On 22 Apr 2018, at 21:42 , [hidden email] wrote:
>
> On Sun, April 22, 2018 8:38 pm, Kenneth Sloan wrote:
> ...
>> So...bottom line: I'm looking for advice on other methods to try.
> ...
>
>
> AIR: http://air.bmap.ucla.edu/AIR5/
>
> Enjoy,
>
> Fred

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[CARL Philippe (LBP)]

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 : [phone]

-----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

[Gabriel Landini]

This is more of a related question/request than a solution to the original
topic.
Sometimes there appear to be "distracting" landmarks in some slices that might
not contribute to a proper alignment.

I wonder if there a way of restricting the SIFT search so it only considers
points inside a ROI (or a set of those) to then apply the transformation to
the whole slices?
I guess that a not-too-elegant way of doing this might be to clear outside all
ROIS, perform the SIFT alignment then apply the transformation to the original
stack, but would that work (maybe the artificial edges that are generated by
the clearing outside the ROIs act as new features?), and how to do this?
 
Regards
Gabriel

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

Interesting idea.

I think I would be satisfied if SIFT enforced the "maximum pixel movement"
restriction.  Perhaps I don't understand the semantics of this parameter?

It's not clear to me where this restriction is actually applied at the moment.
Certainly, *some* pixels move by a LOT when the image is rotated by 90deg!

The central idea is to strictly limit the amount of movement produced by
the transformation.

In my case, I think I could benefit from very elastic matching.  The images
vary due to translation, rotation, and some perspective changes.  But, the
changes are very small.  Large enough to require registration, but strictly limited.

I suppose the constraints are similar to matching overlapping areas of adjacent tiles
in a tiled image where the individual tiles are already in a good approximation to
their correct locations wrt each other.  I want a "tweak" - not an arbitrary
transformation.

The killer is that I see a real need for some rotation - but I need to limit it to (say)
20deg.  Limiting the transformation to "translation-only" prevents disaster, but
it also precludes useful improvement.

So...this seems to boil down to 2 questions:

a) can I convince SIFT to do this (short of limiting it to translation only), or
b) is there another method implemented for ImageJ that handles this situation
   better than SIFT

I'd *really* like this to be automatic, so methods that involve manually locating
landmarks are out.  If it comes to that, I already have my own code for that
type of registration.

Last question: is the fact that SIFT allows a 750x750 image to rotate by 90deg when
"max pixel movement" is set to 25 EXPECTED BEHAVIOR?  or, is this a bug?

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

> On 23 Apr 2018, at 03:43 , Gabriel Landini <[hidden email]> wrote:
>
> This is more of a related question/request than a solution to the original
> topic.
> Sometimes there appear to be "distracting" landmarks in some slices that might
> not contribute to a proper alignment.
>
> I wonder if there a way of restricting the SIFT search so it only considers
> points inside a ROI (or a set of those) to then apply the transformation to
> the whole slices?
> I guess that a not-too-elegant way of doing this might be to clear outside all
> ROIS, perform the SIFT alignment then apply the transformation to the original
> stack, but would that work (maybe the artificial edges that are generated by
> the clearing outside the ROIs act as new features?), and how to do this?
>
> Regards
> Gabriel
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

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 : [phone]
>
> -----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

[olivier-2]

I am doing a lot of live imaging with stuff floating in my medium. StackReg makes sometimes crazy moves. I have solved the problem by using Multistackreg (http://bradbusse.net/sciencedownloads.html). Registration is done on blurred or filtered images, transformation file is saved and used as template for registering raw images.
My2p

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Michael Schmid]

On 23/04/2018 16:20, Kenneth Sloan wrote:
 > ... 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.

Hi Kenneth,

one idea: if you want to do registration mainly based on dark features,
you could use a pixel value transformation that makes differences in the
dark areas appear with more contrast than those in bright areas, e.g.
the logarithm (Process>Math>Log, best convert to 32 bits before). You
could also try square root, which is "weaker" than log.

Michael

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi Ken,

> 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.

Why not enhance the SIFT plugins then? Give back to the community that has
given so much to you.

https://github.com/axtimwalde/mpicbg/blob/master/mpicbg_/src/main/java/SIFT_Align.java
https://github.com/axtimwalde/mpicbg/blob/master/mpicbg_/src/main/java/SIFT_ExtractPointRoi.java
https://help.github.com/articles/about-pull-requests/

Regards,
Curtis

--
Curtis Rueden
LOCI software architect - https://loci.wisc.edu/software
ImageJ2 lead, Fiji maintainer - https://imagej.net/User:Rueden
Did you know ImageJ has a forum? http://forum.imagej.net/


On Mon, Apr 23, 2018 at 9:20 AM, Kenneth Sloan <[hidden email]>
wrote:

> 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 : [phone]
> >
> > -----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
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Saalfeld, Stephan]

Hi Ken,

Please try

https://github.com/axtimwalde/mpicbg/blob/master/mpicbg/src/main/java/m
picbg/models/InterpolatedAffineModel2D.java

as the filterRansac model with 0.1 affine and 0.9 translation (or
something along those lines).
 
Then use the inliers to do an affine.

Some scripting required but there are many examples floating around in
this mailing list or elsewhere in the Internet (may be here

https://github.com/axtimwalde/fiji-scripts

).

Best,
Stephan


On Mon, 2018-04-23 at 09:20 -0500, Kenneth Sloan wrote:

> 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-pl
> > ugin
> > 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 : [phone]
> >
> > -----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

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Kenneth Sloan-2]

Thanks - I'll give it a try.

--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.

> On 24 Apr 2018, at 21:36 , Saalfeld, Stephan <[hidden email]> wrote:
>
> Hi Ken,
>
> Please try
>
> https://github.com/axtimwalde/mpicbg/blob/master/mpicbg/src/main/java/m
> picbg/models/InterpolatedAffineModel2D.java
>
> as the filterRansac model with 0.1 affine and 0.9 translation (or
> something along those lines).
>
> Then use the inliers to do an affine.
>
> Some scripting required but there are many examples floating around in
> this mailing list or elsewhere in the Internet (may be here
>
> https://github.com/axtimwalde/fiji-scripts
>
> ).
>
> Best,
> Stephan
>
>
> On Mon, 2018-04-23 at 09:20 -0500, Kenneth Sloan wrote:
>> 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-pl
>>> ugin
>>> 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 : [phone]
>>>
>>> -----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
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html