henrypinkard
commented
5 years ago 1) It could be usable with some minor modification, but it's not the cleanest or most sensibly designed code. The reason is the Magellan viewer is essentially a hacked version of the Micro-Manager 1.4 viewer (which itself is hacked from an ImageJ display window). For this reason, there are a lot of distinct functionalities that aren't well abstracted from one another. For example, all the contrast controls are contained within the display window. It also has some optimizations with acquisition control that may not be well abstracted (e.g. drawing overlays of large tiled regions to be imaged). I first found out about ClearVolume when the I was just about finished with the Magellan viewer, so I haven't tried it personally, though I think it would be a cool addition. However, a lot of Magellan's functionality relies on interacting with 2D slices of data, so a 2D viewer is more practical in many instances. In many cases the Magellan viewer simply extends the Micromanager 1.4 code. One key addition is ZoomableVirtualStack.java, which allows the viewer to request down sampled image data at the appropriate resolution. I believe most of the dependencies are in that imagedisplay package.
2) Yes, they are quite different. In short, Magellan is optimized for speed of acquisition and data integrity, and BDV (to the best of my knowledge) is optimized for speed of displaying arbitrary 2D slices. The Magellan format is essentially a wrapper of multiple versions of the Micro-manager multipage tiff format--one for each resolution level. In fact, you can probably open each of the subfolders (i.e. a different resolution) in a Magellan dataset in Micro-manager. BDV is able to open Magellan files because of an XML file that describes how to dynamically convert data to what BDV is expecting, though, last I checked this wasn't working. BDV has it's own native format that uses HDF5 (I think), but in my experiments with writing to HDF5 at acquisition time it slowed down write speeds. Agree that it would be great to add multiresolution saving to Micro-Manager, but Magellan's ability to do this depends on a standardized behavior of laying out rows and columns of tiled images, which Micro-Manager has no formalized version of. The multiresolution format class should be well abstracted from the rest of the code and is quite robust--I've personally collected ~40 TB of data with it with no issues. The master class is here. If you want to use it to store new data, you just have to pass in an appropriate summary metadata JSONObject. You should be able to copy this code to get an idea of what fields you need to fill in. Then you're going to use this function to add images, and finally call this one then this one when finished. For generating per-image metadata when adding images to storage, you can copy this code
3) No not really. A good number of bug fixes. But all the package names have changed, which is a bit of a pain. There's a feature in Magellan developed against the 2.0 APIs that automatically calculates the affine transform matrix between stage coordinates and pixel coordinates for good stitching, but you probably couldn't use that as is anyway because of the deskewing stuff you need. Probably your best bet is to copy the most up to date Magellan code, then change package names and imports as needed in order to make it work with 1.4 API
jondaniels
A few questions regarding re-use of parts of the µMagellan code in a separate µManager plugin. I appreciate some pointers to get me going in the right direction.
1) Viewer: I understand µMagellan has its own viewer code. To what extent is the µMagellan viewer separate and usable from the outside the µMagellan plugin? Less importantly, in 2.0 gamma there is ClearVolume; have you considered it as a viewer?
2) File format: Are there important differences between Magellan's multi-resolution format and BDV's format? I know BDV can open Magellan files but it seems better yet if they used the identical format. I would love to see multi-resolution become a first-class file saving option within µManager and that raises the question of the format specifics.
3) 1.4 vs. 2.0: Has anything significant changed with µMagellan when porting to 2.0 besides updating the calls to µManager API? I understand current development has migrated to 2.0, but I'm initially interested in using parts of µMagellan in 1.4.