Fixes and improvements to SCIFIO MicromanagerFormat

Dear Micromanager/scifio users,

The recent Fiji update that included a jump to pom 29.x.x (Congratulations btw!!) and to SCIFIO 0.41.0 seems to have broken the scifio MicromanagerFormat reader. Now when opening micromanager image sequences with scifio turned on using File>Open, the video opens but the same image is shown for all timepoints. So when scrolling back and forth nothing changes.

This behavior seems to be caused by the openPlane method in the reader in the MicromanagerFormat class. I went ahead and created a pull request with some small corrections that appear to address this issue. At least, when I open micromanager videos now I can see all timepoints:

Is anyone else using the scifio micromanager reader? Did you notice any issues like this or otherwise?

Beyond this recent bug, we have encountered several other small issues when using micromanager 1.4.23 20150917 with the scifio reader. We have created a modified version of the MicromanagerFormat and MicromanagerTranslator classes to address these issues (

Here is a summary of a few of the changes we have made:

  1. The date format is not correct for our files. We changed to "yyyy-MM-dd HH:mm:ss Z” from the current setting on master of "EEE MMM dd HH:mm:ss zzz yyyy”
  2. Micromanager metadata.txt files contain a lot of very useful plane specific fields. We keep track of lasers that are on and off and powers, among other things, as plane specific fields. Unfortunately, it seems that SCIFIO squashes these plane specific fields and dumps everything into a single Map accessed in Metadata method getTable(). To ensure that plane specific information is retained, we add Maps for each plane that contain all fields. Then during translation to OME, we add these as MapAnnotations so this plane specific information is still retained in the OME record. At the moment, we used arbitrary and somewhat awkward keys ("“MMAllFileKey-” + imageIndex + “-” + Z + “-” + C + “-” + T"). But the MapAnnotations in OME also need some kind of keys like this to work. Does anyone have any suggestions about a better why to keep track of plane specific information in SCIFIO? We will keep thinking about more elegant solutions…
  3. We also made some small changes so the translator still works even if the pixel units are not set. In general, scifio also squashes a lot of the units, but this is not specific to micromanager. It would be great to have scifio respect units. I think there is already an issue on the scifio repo about this.
  4. Unfortunately, the current reader sets all positions to null when the metadata file is closed. This prevents translation later as a separate step after working with videos in Fiji for a while by retrieving the metadata from the image. So at the moment only scripts that both read in the video and directly translate to OME would work. We have modified to reader to retain the position information so that translation to OME can be done at any time with currently open videos. Do you know why this was introduced. Was it to conserve memory. Our positions are usually very small, so we haven’t have an issue just keeping them in memory and translating later.
  5. We also inserted a preference setting that will flip the Z and T if Z > T. It can be turned on and off as well. We use this to correct data collected on Z when in fact it should have been collected on T. I don’t think this is of general interest, but figured I would mention it.

We can only read micromanager 1 files, but would like to make changes so the reader can handle both micromanager 1 and 2 files.

Thanks to the magic of scijava services we have been able to insert our reader with higher priority than the default, so we get all these fixes.

I am just wondering if any of these changes are interesting for other users of this reader? Does anyone have specific types of micromanager metadata that is not parsed well?

I think it would be great to make some improvements to the MicromanagerFormat in SCIFIO. I am happy to collect ideas and make another pull request with the changes. I think it would be important to gather some different test datasets to make sure the changes don’t break anything.

Please let me know if you have any thoughts about this.