Elastix parameters presets

[DSbioimaging]

Hi it is me again with another documentation question/issue. I went through the elastix manual another time and I started looking at the different parameters presets listed in the code and reading what actually ends up in the final parameters file. I am still very much a novice at this though.

These are my observations:

• Default initializes the registration with by aligning the center of mass of the intensity files, it uses a smoothing pyramid without resizing, this is done on every channel of the image (assuming equal weights)
• CLEM basically the same as default but skips the center of mass initialization, it tends to work better for me when having an initial transformation file (e.g. one made in Big Warp)
• Henning, this is one looks quite different from the others (also not listed in the UI, weird). It is using a recursive image pyramid, to my understanding that means smoothing+scaling. There are no channel weights though, is it working on a channel only? An average?

I am looking into this because I am working with pretty big (by my standards) stitched grids taking 3-4GB each. Registration takes 120+GB of memory which my computer barely covers (not without some swapping though) and it has been pretty brutal on SSD write cycles too. To make it worse, what I have been doing on single ZStacks so far is not working all that well. I tried downscaling the stacks so they would have 20 and 30% of their pixels in XY and Z respectively. This has improved things somewhat but I am still encountering failure cases and there is the matter of changing the pixel size and voxel spacing in the transformation file to use transformix on the original stack.

To my understanding, the Henning profile would downscale my data and hopefully guide the registration using lower scales without the need for a few millions spatial samples. Am I on the wrong track? As a side note, would it take a huge amount of work to implement the option to use a custom parameters file or a set of specific overrides (e.g. type of pyramid) for the default profile(s)? I like having the convenience of the wrapper dealing with file writing on disk for me. :)

Thanks again for releasing this and sorry for the constant issue opening.

[tischi]

Dear @DSbiomedAU,

I am really sorry for getting back to you so late about this!

For very big data I think the best we have in the plugin is the Gaussian smoothing sigma, where I think we actually downsample the image, so that should help with the performance.

Your approach of externally downsampling the data, learning the registration and then applying it to the full resolution is something that we also do, but not using the Fiji plugin but a python wrapper of elastix. My colleague @sebgoti may be able to help you there. Please let us know if this still is a concern.

In general, I feel that applying elastix to very big image data is a discussion that concerns many people and I would prefer to have this discussion on https://forum.image.sc/ Thus, if you don't mind, please open a thread there and ping me with @Christian_Tischer.

Again, in general, if you want to be more flexible I recommend either using the command line binary or the python wrapper: https://forum.image.sc/t/installing-simpleelastix-in-python/71959/31

[DSbioimaging]

Dear Christian, no worries for the delay, at this point I am just eating up tons of support time by discussing features that were probably not in the original scope of the wrapper.

I have stopped focusing on Elastix at the moment since my colleagues are very happy with BigWarp and there is a pressing deadline to focus on for the next months (ie wrapping up my PhD). The landmark registration gives OK results but takes time though.

I also experimented on initializing Elastix with a BigWarp transform to take care of the big shifts but I definitely got different results from just using the BigWarp-transformed stack as the initial moving image. It is my understanding that Elastix handles the initial transform either additively or multiplicatively. I think the wrapper uses the second and I'm guessing this is why the behavior is different than expected.

I'd love to spend more time on this! In any case, the wrapper worked beautifully on other data and I hope it will get published soon.