Rebuilding AreaLists from trakEM2 .xml file



Hi Everyone,

We are trying to extract AreaLists from .xml files to load into VTK for some further analysis that we don’t want to run in ImageJ. When we draw the arealists that we have managed to extract from the xml, each layer is represented as a dotted line that describes the contour of the segmented region. Could someone tell me how these dotted lines are derived from the original segmentated area so we can reconstruct the full AreaLists from them?

Also, as an aside, we are very curious as to why layer IDs are presented as multiples of 3, except for the first layer, which is 5, followed by 9, 12, 15, 18 etc. Just curious.

Thank you!



Hi @cksalmo,

Clarifying questions:

How / where (what program) are you drawing them? It sounds like you already got the arealists from the xml somehow…? How did you do it?

Usually I use:
Export > Arealists as labels (tif)
and process the result as necessary (vtk should be able to handle tifs).



Hey @bogovicj,

We extracted the set of points that describes each area in each layer of an AreaList using a python script, and then plotted those points in VTK. We originally thought that the list of points contained every point in each area list, but it is simplified to describe just the contours of the arealist in each layer. Hence why we want to know how they are simplified.

Also for some reason VTK has had some trouble handling 16bit tiffs and so we have avoided using them, opting instead for PNGs. This is most likely something that could be sorted out with some minor fiddling. But regardless, when we export all AreaLists as Labels, the resulting tiff file only identifies the arealists with pixel values, and we lose our user defined unique IDs that we set as the areas are segmented.

The reason we are hoping to extract the arealists from the xml is that all the info we need (ie oid, user defined ID, plus parameters) see to be there; AND we are operating in multiple labs and want to be able to trade files back and forth more easily - which will be much quicker with the xmls instead of the image files.

In conclusion that main thing we want to do is export a single file with all arealists maintaining their OIDs and our user defined IDs.

Thanks for your help!


Where did the python script come from?
I.e. is it online somewhere? and is it “official” (written by a TrakEm2 author)?

That script will have a clue as to what’s happening.
The thing is, AreaLists can be exported in many different ways.


We wrote the script ourselves so not official (I don’t currently have access to it otherwise I post it). And just to be extra clear, we extracted the points list from the xml alone. We didn’t use ImageJ at all, or access the xml from the ImageJ end, we just parsed the the xml text, extracted the points list from every layer in each arealist and ploted those points. The result was the above-mentioned dotted lines. Apparently there is some transformation applied to the list of points recorded in the xml that would allow one to draw the uninterrupted line describing the boundary of each area. Its that transformation that I was hoping to understand.

Thanks for the tips on exporting arealists though! It seems from what you are saying that it may be best to work through ImageJ rather than trying to extract the relevant info from the xml. So we’ll have a look at some of the functions in the link you sent.

Thanks again!



Cool, keep us posted.

If you know that the transform is an affine (for example) then it may not be too tricky.
E.g., one of my trakem2 xml’s has the line


associated with a patch, which tells you that it is translated in y.

Trakem2 supports a wide variety of transforms though, so in the general case, you may have to dig through appropriate java code to see how they are applied. In that case, working through trakem2/imagej will probably be easier/faster as you say.

If you do get that script working, it’d be nice if you made it public so others can benefit too! :smile:

Good luck,


Yes - actually the xy location of every arealist is encoded as an affine transform from the origin. That one was pretty straightforward. The arealists themselves however are compressed somehow by excluding most of the pixel locations from the arealist text. Less clear how precisely that is done.

But yes, will keep you all posted! Thanks again for the help.