File written with libminc not readable in ITK?

Hi, this is my first question here.

I’m trying to write some MNC2 files for them to be later viewed in Slicer 3D, and I run into a very odd problem: The file I’m writing with code that uses libminc directly, which seems perfectly readable for the MINC command-line tools, will not open with ITK. Neither in Slicer, nor using the Python library.

The failure appears to be very basic – under ITK, the failure comes from miopen_volume().
For example, with a file I wrote:

$ mincinfo ~/tmp/test_uc.mnc 
file: /home/shai/tmp/test_uc.mnc
image: unsigned byte 0 to 255
image dimensions: zspace yspace xspace vector_dimension
    dimension name         length         step        start
    --------------         ------         ----        -----
    zspace                    144            1            0
    yspace                    144            1            0
    xspace                    144            1            0
    vector_dimension            3      unknown      unknown

But in Python:

Python 3.8.10 (default, Jun 22 2022, 20:18:18) 
Type 'copyright', 'credits' or 'license' for more information
IPython 8.4.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import itk

In [2]: PixelType = itk.RGBPixel[itk.UC]

In [3]: ImageType = itk.Image[PixelType, 3]

In [4]: reader = itk.ImageFileReader[ImageType].New()

In [5]: reader.SetFileName('/home/shai/tmp/test_uc.mnc')

In [6]: reader.Update()
RuntimeError                              Traceback (most recent call last)
Input In [6], in <cell line: 1>()
----> 1 reader.Update()

RuntimeError: /work/ITK-source/ITK/Modules/IO/MINC/src/itkMINCImageIO.cxx:285:
ITK ERROR: MINCImageIO(0x21f0820): Could not open file "/home/shai/tmp/test_uc.mnc".

This line 285 is (in current development sources, still) reporting a failure in miopen_volume().

By setting MINC_LOGLEVEL=4 I was able to get this further message:

/work/ITK-source/ITK/Modules/ThirdParty/MINC/src/libminc/libsrc2/volume.c:1403 (from MINC): Unable to open file '/home/shai/tmp/test_uc.mnc'

Which makes things look like, maybe, the file is in Minc Version 1 format (in the ITK sources, that line is only compiled when MINC 1 support is unavailable) but when looking, again, with command-line tools…

$ mincdump ~/tmp/test_uc.mnc | head -n 14
hdf5 test_uc {
        vector_dimension = 3 ;
        xspace = 144 ;
        yspace = 144 ;
        zspace = 144 ;
        byte image(zspace, yspace, xspace, vector_dimension) ;
                image:varid = "MINC standard variable" ;
                image:vartype = "group________" ;
                image:version = "MINC Version    2.0" ;
                image:dimorder = "zspace,yspace,xspace,vector_dimension" ;
                image:valid_range = 0., 255. ;
                image:signtype = "unsigned" ;

… one can clearly see that the file is an HDF5 file (that’s MINC 2 only) and has explicit mentions of version 2.0 inside.

Can anyone point towards what I’m doing wrong?

Thanks, and of course, thanks for all your work on ITK,


@gdevenyi @Vladimir_Fonov do you have some suggestions?

Found the issue: My local copy of libminc is creating files supporting hdf5 API at least “v110” (version 1.10.2 of hdf5). The libminc that’s compiled into ITK appears to support, at most, “V18”.

The libminc sources still seem to include that limitation (in ITK as well as out of ITK), so I wonder what happened here. But, anyway, I have my explanation.

In [1]: import h5py                                                                                                                                                                                                               

In [2]: f = h5py.File('/home/shai/tmp/test_uc.mnc', 'r')                                                                                                                                                                          

In [3]: f.file.libver                                                                                                                                                                                                             
Out[3]: ('v110', 'v112')

Good job running this down.

I remember we solved this in libminc and ITK maybe 3 years ago?

Not cool of the HDF5 guys to change the default like that though.

1 Like

Yes, you have, but that fix was never included in a released version of libminc; building libminc without the fix against libhdf5>=1.10 causes the problem. Not sure the HDF5 guys are to blame.

@gdevenyi Would it be appropriate, in your opinion, to open an issue on the libminc repo, asking for a new release?

1 Like

Oops. That’s a bit of an oversight :slight_smile: Yes definitely request a new release.