Better handling of < 3D images

[Lestropie]

There are a number of places in the core libraries that make assumptions about any image with less than three dimensions being somehow invalid. This leads to e.g. fixel data files that have sizes Nx1x1 as opposed to just a 1D image with size(0) = N, and can lead to erroneous warnings about invalid transforms / voxel sizes. I'm encountering similar when going over #1541, where (greyscale) PNGs are by design 2D.

It would be nice if at some point we could find the areas in the library that either break or explicitly intervene when provided with < 3D data, and update them to either handle such appropriately or abort due to their incompatibility. E.g. One could envisage mrview issuing an immediate error message if attempting to open a fixel data file as the main image, rather than displaying a 500,000x1x1 texture; or the image transform being ignored entirely at both read & write in any < 3D image header rather than being set to identity.

[Lestropie]

I think missing from this issue that I can't find posted anywhere else:

If <3D, I'd prefer for the resulting images to not contain voxel spacings or affine transform. These make no sense, and being absent entirely rather than set to "default" / "invalid" would to me make more sense. But it'd require a fair bit of combing through the code and example usages to find situations where new branches need to be introduced.

[jdtournier]

Just my 2 cents: voxel and transform both make sense in general for 2D slices - that's how they're provided in DICOM. I'd be very uncomfortable with removing that information.

[Lestropie]

voxel and transform both make sense in general for 2D slices - that's how they're provided in DICOM. I'd be very uncomfortable with removing that information.

That would still be preserved in the case of e.g. XxYx1; I'm thinking specifically data where the dimensionality has been explicitly reduced below 3.

---

Bumping due to forum post: attempting to load a fixel data file in the Overlay tool should, IMO, produce an error.

[Lestropie]

P.S. There's potentially an alternative solution here.

Define a different file format, with a different file extension, but that shares almost all of the code with the MRtrix format. The only points at which the handling would diverge would be:

• One demands >= 3 axes, whereas the other is entirely OK with being a 1D file;
• One can be opened directly for visualisation in mrview, the other cannot;
• One must write & read transform & voxel spacing from the header, the other must not;
• One can be opened for the purpose of e.g. per-fixel information, the other cannot.

So this alternative "format" would be used for fixel data files, the fixel-fixel connectivity matrix, and also the upcoming fixel correspondence information (#2200). It would provide a much more explicit split between "image data" and "fixel data" at the point of file names. It would also fully exploit the existing code base, and support arbitrary key-value string pairs in file headers.

[Lestropie]

Another note in this regard in light of #2437 is that .npy would in many ways be a preferable format for 1D / 2D non-spatial data compared to using an "image" format. I believe that the Python dict literal that is used to provide the compulsory metadata should be possible to use to store other metadata, such that anything coming from a KeyValues should be possible to store in there (though it would ideally be typed rather than a strict string-string mapping, much like is done with JSON support).

It may be too far down the road to preclude the use of image files to store fixel data with .npy as a replacement. But with #2435, defining a standardised API for 1D / 2D data access, use of .npy could be done through the memory-map, both for read and write. An Eigen::Map is unfortunately not always applicable in this scenario: that requires matching of type + endianness + row/column-major-ness (?) at compile time.