Bug 536 – Locking a Tile is ignored

Bug 536 - Locking a Tile is ignored


Summary:	Locking a Tile is ignored

Status:	RESOLVED INVALID

Product:	Fiji
Classification:	Unclassified
Component:	TrakEM2
Version:	unspecified
Hardware:	PC Linux

Importance:	P5 enhancement
Assigned To:	Stephan Saalfeld

URL:

Depends on:
Blocks:

Reported:	2012-12-03 11:13 CST by Stephan Preibisch
Modified:	2014-06-23 21:04 CDT
CC List:	2 users (show)

See Also:

Description Stephan Preibisch 2012-12-03 11:13:18 CST

I first align all images in a section using "Montage all images in this section". I call "least squares" on a translation model and consecutively a regularized affine as Saalfeld showed to me. Sometimes one or two images at the end cannot be aligned, they are usually only connected to one tile and have very little content.

I found parameters to align it using SIFT, but it does not work on the entire section as they are too relaxed regarding minNumCorrespondences and inlierRatio. Therefore I fix the one tile that it is only connected to and align the pair, which works. However, now the transformation of the fixed one is reset as well, it seems as only the initial translation survives, but not the regularized affine. I guess that should not be the case.

Thanks a lot for looking into it.
Steffi

Comment 1 Stephan Saalfeld 2012-12-03 13:55:07 CST

Hi Steffi,

did you choose a translation model to align the tiles?  If so, then
this is not a bug but a consequence of TrakEM2's design that includes two independent transformations per each image tile, an arbitrary transformation and an affine transformation.  Linear alignment deals with the affine part which is independent from non-linear transformations.  It is implemented to use the original images instead of transformed images which makes sense in most situations (not creating rotated rectangles with large uncovered areas, not creating excessively large mipmaps, re-using features and matches).  Changing this is possible but seriously impacts how the whole system is working (e.g. you would re-extract all features and point matches for what you just did on Friday, affine montage after translation montage).  It is also time-consuming and I currently lack that time.

So much to the rebuff ;)---you can of course workaround it.  The easiest way is (at least I believe that this should work), to use an affine transformation for the montaging step.  If you want something else, you use an affine transformation that is regularized by the transformation model that you actually want (e.g. translation) with lambda=1.0.

Another option is to move the affine transformation into the coordinate transformation stack (creating rotated rectangles with large uncovered areas, creating excessively large mipmaps, loosing all features and matches ;)).  There is no button yet in TrakEM2 to do this but the following Beanshell snippet does it for all selected patches, if the coordinate transformation stack is empty (which, for you, is the case):

for (patch:Display.getFront().getSelection().getSeleced()){
  affine = patch.getAffineTransform();
  ct = new mpicbg.trakem2.transform.AffineModel2D();
  ct.set(affine);
  patch.setAffineTransform(new java.awt.geom.AffineTransform());
  patch.setCoordinateTransform(ct);
  patch.updateMipMaps();
}

I will later reveal how to do it if the coordinate transformation stack is not empty.

Comment 2 Stephan Preibisch 2012-12-04 10:14:57 CST

Thanks Stephan, computing the regularized affine right away works perfectly. At least for me that is the way to go!

Comment 3 Stephan Saalfeld 2012-12-04 22:20:58 CST

Perfect.  Closing as WONTFIX because this is not a bug.

Comment 4 Curtis Rueden 2014-06-23 21:04:45 CDT

Somehow this issue was never closed out. So I'm closing it as INVALID which is the status to use when the bug reported is not actually a bug.