search

ukoethe / vigra

a generic C++ library for image analysis
http://ukoethe.github.io/vigra/
Other
412 stars 191 forks source link

unify Volume-Import #72

Open jschleic opened 13 years ago

jschleic commented 13 years ago

Picking up the idea: It would be nice to have a common interface to read different types of multi-dimensional images (and Subsets / ROIs of the data).

citing ulli from issue #5: "In the long run, it would be desirable to unify multi-dimensional import/export in a similar way as has been done for the 2D case.That is, 'importVolume()' would transparently call the appropriate import library (e.g. for one-image-per-slice, multi-page TIFF, HDF5) depending on the input file type. Are there any volunteers?"

hmeine commented 13 years ago

That is exactly the way I coded the original importVolume. ;-) Back then, only multi-image and info+raw were supported, but I already ensured that image sequences could be loaded by passing just one filename. In the meantime, hdf5 support was added without being "properly integrated", yet I wonder how such an integration should look like, since there could be an arbitrary number of volumes in a single file. The 3D TIFF support that I hacked together recently is seamlessly integrated again. (Tested with ilastik.)

In other words, this issue is mostly about hdf5, where the goal is not so clear IMHO (although just loading the first volume [potentially after a non-maximum filtering on the volume size] could be a useful heuristic).

hmeine commented 13 years ago

OK, and the ROI handling is missing & would be useful, too. (I think that one’s available for hdf5 only, ATM?)

jschleic commented 13 years ago

Yes, it's mostly about integrating HDF5: I think, the generic interface importVolume() could be extended by an Options object to pass an additional dataset name (that is ignored by other decoders than hdf5). For the additional functionality that hdf5 offers, one can still use the HDF5File class.

But for me the interface for adding new data-formats is unclear. Concrete example: Where would I have to start, if I wanted to add support for SIFImportInfo / readSIF() to the generic importVolume()? Adding another if() passage in multi_impex.hxx seems to be rather tight coupling? In my opinion the Decoder-Schema of 2D impex is more complicated than what would currently be needed for 3D while the current implementation of importVolume() is too unflexible. Am I missing something in your implementation?

hmeine commented 13 years ago

No, I absolutely agree with you. I would like to have something similar to the 2D impex for 3D, too, and my gut feeling is also that the former is more complicated than necessary. The question is who will tackle this problem.

An idea which I had recently was to try to extract some common base class(es) from the 2D impex, such that common stuff can be reused. I was thinking about data types, compression schemes, etc. Ideally, the 3D implementation could just pass on the information to the same backend routines used for 2D, e.g. in the case of multi-file sequences, or in my case of 3D TIFFs.

hmeine commented 13 years ago

Oh, BTW, the ROI selection would be very useful for the tiled TIFFs, too: after all, the main reason for using tiles is to be able to handle very large images. Even for other, 2D images it could make sense to offer "cropped loading". And it is a common feature of existing load dialogs in 3D software to select a sub-VOI.

IOW, this feature should at least be kept in mind not only for HDF5 files.