Transform structure

[pkaifosh]

Ben (@poolio) has suggested that we use an abstract Transformation class to define the interface for the various possible ways in which images may be transformed to correct for motion artifacts. This would help to clean up a number of parts of the code and improve flexibility going forward.

I have started sketching this in transfrom.py, included in commit 28ee215.

[poolio]

@freeman-lab has been working on similar refactoring in thunder-project/thunder#74. We spent some time designing the alignment interface offline. Some of it is Spark-specific but the splitting of methods for registration from transformations and their application is pretty general.

[pkaifosh]

Thanks for the pointer, @poolio. I notice that the apply() method doesn't take a grid argument. What is the idea here?

@freeman-lab: What do you think the best way to go forward with this to make things as compatible as possible? Ideally any method developed in SIMA could be imported and run in Thunder. To start, we could mimic the Thunder classes as closely as possible. Any suggestions?

[poolio]

I was thinking that when we add more advanced alignment techniques to thunder, they could take a grid argument that would be used by map_coordinate. When using Spark we could generate a grid on-demand, broadcast it to each worker, or generate it once for each worker (using mapParititons). I wanted to benchmark each of these techniques before adding it in.

[poolio]

@pkaifosh, I wanted to point you to thunder-project/thunder#100. It's an implementation of Lucas-Kanade registration. There's no dependency on Spark in any of that code (other than the RegistrationMethod) base class, so it should be really easy to use this in something like SIMA. You would just have to pull out the code from getTransform. Any comments on that PR would be welcome!