Skip to content, Skip to search

Changes

TrakEM2

316 bytes removed, 27 January
For importing large collections of images and editing them immediately afterwards: update link: Jython Scripting moved to Jython Scripting Examples a while ago
{{Infobox| software = ImageJ| name = TrakEM2| author = Albert Cardona<br />Stephan Saalfeld| maintainer = Albert Cardona ([mailtoComponentStats:sapristi@gmailsc.com])<br />Stephan Saalfeld| filename = fiji:TrakEM2_.jar (Included in Fiji) | source = {{GitHub | org=trakem2 | repo=TrakEM2}}| released = May 2006| latest version = 1.0c (2014)| status = active| category = [[:Category:Registration|Registration]], [[:Category:Segmentation|Segmentation]], [[:Category:Image annotation|Image annotation]], [[:Category:Plugins|Plugins]], [[:Category:Neuroanatomy|Neuroanatomy]]| website = [http://www.ini.uzh.ch/~acardona/trakem2.html TrakEM2 news and documentation]}}TrakEM2 is an ImageJ plugin for morphological data mining, three-dimensional modeling and image stitching, registration, editing and annotation.
See [http://www.ini.uzh.ch/~acardona/snapshots.html TrakEM2 snapshots] for an overview.
{{TOC|small}}
== Features ==
To set the script to all images, save the above to a file named "whatever.bsh" (notice the filename extension ".bsh") and then right-click on the TrakEM2 canvas and choose "Script - Set preprocessor script layer-wise", and choose the whole range of layers. This will set the script to every image of every layer, and trigger mipmap regeneration for every image. When TrakEM2 loads the image, the script will run on the image before TrakEM2 ever sees its contents.
The preprocessor script gives you maximum power: do whatever you want with the image. For example, [[Jython ScriptingExamples#Correct_illumination_in_a_stack:_apply_the_illumination_of_one_slice_to_all_others | normalize the image]] relative to a known good mean and standard deviation for your data set.
=== For regenerating mipmaps the fastest possible ===
=== Faster XML loading and less memory consumption with larger search quadtree buckets ===
Besides choosing an appropriate mipmap generation strategy for large images, make sure that you set as well the bucket size appropriately.
What is a bucket in TrakEM2: each layer (each section) has an internal octree [https://en.wikipedia.org/wiki/Quadtree quadtree] to be able to find an object (e.g. an image) under the mouse, or to be able to quickly find images that overlap with other images. In other words, to be able to perform fast spatial queries such as finding the list of all images that intersect a given rectangle. If the bucket size is small (the default is 4096 pixels on the side, and a bucket is then a square of 4096x4096 pixels, which could be considered quite small), then in combination with a very large canvas size there will be way too many buckets generated. <b>Will take a lot of time and also consume a lot of memory</b>.
If the bucket size is small your sections only have about 100 images each, and images are somewhat large (the default is 4096 pixels on the sidesay, and a bucket is then a square each has dimensions of 4096x4096 8096x8096 pixels, which could be considered quite small), then in combination with set the bucket size to a very large canvas size much larger value than the default, for example to 100000. Effectively there will be way too many buckets generated. Will take a lot of time and also consume a lot of memoryonly one bucket.
If your sections only have about 100 images eachSmall buckets make sense when there are many small objects in a layer or many small zdisplayable objects. In that situation, and images are somewhat large (saysuch as a single image per layer, 8096x8096)but many smaller Ball or Pipe or AreaList objects on it, then set go for the default bucket size (4096) or smaller. Otherwise, go for big or even very big, effectively removing the buckets functionality and reducing to a much larger value than the defaultlist search, which is just fine for example to 100000. Effectively there will be only one bucketsmall lists of images like about 100.
Small buckets make sense when there are many small objects in When registering/aligning a layer or many small zdisplayable objects. Otherwisecollection of 400,000 images spread over 5, go for big or even very big000 sections, effectively removing it makes sense to make the buckets functionality and reducing to list searchlarge (like 40960, 10x the default, which is just fine for small lists of images like about 100or even larger than that).
Setting the bucket size to a large value will reduce XML loading time *<b>a lot*</b>.
To set the bucket size, right-click and choose "Display - Properties ..." and write in the bucket size value.
Bureaucrat, emailconfirmed, incoming, administrator, uploaders
707
edits