Scifio: mysteries of plane to N-dim index conversion

scifio
Tags: #<Tag:0x00007fd54317c968>

#1

I am trying to use the SciFIO library to import image data in one of my projects, i.e. I try to use the library to get access to pixel data of planes. What leads to trouble is the assignment of planes in N-dimensional space. One can get the axes and axes lengths from the ImageMetadata (using the getAxesLengths() member function), and one can get the position on the various axes of a plane from the FormatTools.rasterPosition(int imageIndex, int planeIndex, Metadata md) utility function. This works for some file formats (notably tiff and jpeg), however, for others (so far I found avi in this category) there is no match between the long[] rasterPosition returned by FormatTools.rasterPosition and the Axes information returned by getAxesLengths(), i.e. the rasterPostion has only one index whereas there are 4 axes, so how does one discover which axis that single rasterPosition belongs to?

In general, I am surprised about the feebleness of this design. It seems imperative for anyone working with N-dimensional images to easily discover the indices into these dimensions. As it stands, I can only find easily breakable approaches. Am I missing something or is this really how it should work and am I dealing with a bug in the avi importer?


#2

Sorry for the delay in reply, @nicost.

Did you notice the getPlanarAxisCount() method? It tells you how many dimensions of the N are to be excluded from planar index rasterization. You may also find the method getAxesNonPlanar() to be useful in conjunction with positionToRaster et. al (see also ImgLib2’s IntervalIndexer, which has the same methods; we will probably deprecate then remove the FormatTools methods in SCIFIO with the next major iteration of the design).


#3

Indeed @ctrueden . Too long ago for me to remember the details. However, getAxesNonPlanar() did not do the trick, seeing that I ended up with ugly hacks like:

if (reader_.getFormatName().equals(“Audio Video Interleave”)) {
cb.t((int) rasterPosition[0]);
return cb.build();
} else {
axes = im.getAxesNonPlanar();
}

It would be strange to deprecate and(eventually) remove the positionToRaster functionality from SciFio. Seems to me that providing pixel data for N-dimensional data sets is the primary purpose of SciFio, and what good does that do if the pixels can not be associated with an index in that N-dimensional space? Why should that primary responsibility live in another library (that is doing a whole lot of other stuff)? It would make much more sense to improve the api to give full-fledged access to pixel data indexed by N-dimensional axis, rather than delegate that responsibility to a third party.

More general, I got away from this attempt (https://github.com/nicost/micro-manager/blob/ViewerPlusCV/mmstudio/src/main/java/org/micromanager/data/internal/SciFIODataProvider.java) with the notion that SciFio is not suitable for inclusion in 3rd party projects as it is basically undocumented and unmaintained. It would have helped me avoid putting too much time into a more or less wasted effort if this had been clear upfront. I’d be happy to update the website page to that effect.


#4

The idea would be to recommend use of IntervalIndexer instead, which accomplishes the same purpose. I am not suggesting we would remove that functionality, since as you say it is of primary importance.

I would say underdocumented and undermaintained. I am the maintainer. But I am currently responsible for maintaining too many projects. SCIFIO is the primary mechanism for image I/O in ImageJ2, so we certainly have no plans to abandon it. We are actively pursuing more funding so that SCIFIO can have its own dedicated developer + maintainer again. In the meantime, it is being developed by @gab1one at ~0.5 FTE rate. Our current efforts involve migrating the core data I/O logic into SciJava Common, so that SCIFIO can focus on only image-specific APIs. This will slim down the codebase very much. Progress is happening, but slowly.

I would suggest communicating more frequently on this forum, then.


#5

“would suggest communicating more frequently on this forum, then.”

@ctrueden That is a funny thing to suggest after a 19 day delay between posting and getting an answer. Am I supposed to post multiple times when I do not get an answer? B.t.w., I am not being notified by email when there is a response on a thread that I started. Am I supposed to pull for notifications?

Your reply underscores the point I made. The library in its current state is unusable for third parties, and the maintainers are too busy to respond to inquiries in a timely manner. Nothing to be ashamed off, but something that should be made very clear and upfront. My suggestion to update the SciFIO website to that effect still stands. By suggesting that a project is something that you can not back up, you will loose support very quickly.


#6

I am all for clear communication, to facilitate realistic expectations from the community. However:

  • The SCIFIO GitHub repository already says: “SCientific Image Format Input & Output: a flexible, extensible framework for image I/O. *EXPERIMENTAL* All API is subject to change, so depend at your own risk! See also @openmicroscopy/bioformats.”
  • The version number is still 0.x. By SemVer, this indicates that the library is not yet stable. Perhaps it is tempting to start using a project when it has been versioned at 0.x for years, but it is at 0.x for a good reason.

It really depends what you are trying to do. There are projects, including KNIME, that use it successfully. Third parties have successfully contributed formats that have merged to the mainline.

Feel free. The squeaky wheel gets the grease.

No, there is some technical problem going on right now. The forum staff are discussing the best way to address it. Edit: The problem has been resolved; emails should be working again. Please @ mention me if you notice otherwise.