Add support for IMOD (.mod) files

[mlinkert]

See file in data/imod/jean-marc/.

Some documentation is also available at:

​http://bio3d.colorado.edu/imod/doc/asciispec.html
​http://bio3d.colorado.edu/imod/doc/binspec.html

[jburel]

Moved from sprint 2011-12-13 (4)

[mlinkert]

The tricky thing about this particular format is that the files don't contain raw pixel data, but rather shape data (a set of points + rendering information). There are a few ways to handle this:

1. Store all of the shapes as OME Shape elements. This means that Bio-Formats will always return completely black image planes, and it is up to whatever client software to handle drawing the shapes correctly.
2. Set the pixel data to correspond to whatever points and colors are stored, optionally storing the remaining shape information in Shape elements.
3. Attempt to render the shapes into an image using all of the shape information. The images returned by Bio-Formats will then more or less match what is displayed in IMOD.

I suspect that (3) is nicest for users, but (1) or (2) is more appropriate from an implementation perspective. I really don't know enough about how this data is used, though. Any opinions?

[jmoore]

Without knowing how they are used either, I would think 1+3 would be the best solution, i.e. pixel data should be generated but the shapes should be preserved.

[cxallan]

Taking into account the intent of Bio-Formats, which is not to provide a visualization framework but a data access library I would argue that (3) and possibly even (2) is not its responsibility. Furthermore, even if (3) were attempted I would think the best we could hope for would be a rather trivial implementation, the number of potential features such an API would have to implement is staggering.

I do however think that given (1) a generic library that converted from OME ROI and Shape elements to Java2D instances for the purposes of drawing would be useful to Bio-Formats, OMERO and Bio-Formats ImageJ plugin users. Jean-Marie, does OMERO.insight currently translate the OME ROI and Shape instances to Java 2D instances, some sort of wrapper instances or to JHotDraw instances?

[wmoore]

I would go for 1. Rendering is going to be meaningless since you'll have open shapes, lines, points etc that don't translate into volumes/voxels.

[jburel]

Moved from sprint 2012-01-17 (6)

[jmoore]

Moved from sprint 2012-01-31 (7)

[jburel]

Moved from sprint 2012-02-14 (8)

[mlinkert]

See ​http://github.com/openmicroscopy/bioformats/pull/13.

[jburel]

Moved from sprint 2012-02-28 (9)

[jburel]

Moved from sprint 2012-03-13 (10)

[jburel]

Moved from sprint 2012-03-27 (11)

[jburel]

Moved from sprint 2012-04-10 (12)

[jburel]

Moved from sprint 2012-04-24 (13)