Bug 355 – TrakEM2 skips some random patches during mipmap update

Bug 355 - TrakEM2 skips some random patches during mipmap update


Summary:	TrakEM2 skips some random patches during mipmap update

Status:	RESOLVED FIXED

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

Importance:	P2 normal
Assigned To:	Albert Cardona

URL:

Depends on:
Blocks:

Reported:	2011-08-23 14:27 CDT by Stephan Saalfeld
Modified:	2011-08-25 21:32 CDT
CC List:	0 users

See Also:

Attachments
a random mipmap was not updated? (1.06 MB, image/png) 2011-08-23 14:28 CDT, Stephan Saalfeld
Project->update mipmaps (selected images) fixes the issue (995.06 KB, image/png) 2011-08-23 14:29 CDT, Stephan Saalfeld

Description Stephan Saalfeld 2011-08-23 14:27:41 CDT

ElasticLayerAlignment and ElasticMontage eventually assign a new transformation to each patch and then update the mipmaps.  I found a small number of patches not being updated after the process had been finished.  An explicit update of the patch's mipmaps fixes the problem, so the transformation data and bounding boxes are correct, just the mipmap is wrong.  See attached screenshot for what I mean before and after manual mipmap update.

I report this bug before further investigating whether this was a cache issue or an actual left-over mipmap on disc.  In any case, the bug is significant due to affecting snapshot generation which is required for further alignments (it also looks bad).

Both alignment routines show this bug when transformations were updated sequentially in a single thread, followed by a single threaded loop triggering the then multi-threaded mipmaps update.

Comment 1 Stephan Saalfeld 2011-08-23 14:28:56 CDT

Created attachment 52
a random mipmap was not updated?

Comment 2 Stephan Saalfeld 2011-08-23 14:29:44 CDT

Created attachment 53
Project->update mipmaps (selected images) fixes the issue

Comment 3 Stephan Saalfeld 2011-08-25 19:40:43 CDT

Got it.  The bug was due to MovingLeastSquaresTransform(2) not being thread-safe to provide optimal performance.  Nevertheless, it was used by TrakEM2 as if it was.  I have fixed this for now by overriding the questionable method synchronizing the problematic part, but I am still undecided if not creating a new object at this place is a better idea.  For creating a =new object at this place, we will need to introduce a M newInstance() method to Model<M>, copy() is too heavy-weight.  The fix is pushed into branch 'elastic-align' which should be merged into master soon.

Comment 4 Albert Cardona 2011-08-25 21:32:42 CDT

Thanks! I am glad you found it.