I was given two volumes in gipl format (image and labelmap), that I can open with ITKsnap without any problem. When I drag and drop them into Slicer, first it suggests to load them as ‘Scalar Overlay’ as oppose to ‘Volume’. Regardless of what’s chosen, Slicer stalls. This happens with both stable 4.10 and r27623 on windows 10.
Same volumes exported as NRRD from ITK-Snap loads fine.
Gipl image loading works fine for me on Windows10 with Slicer-4.10. Can you share one of the images that you had problem with?
I haven’t encountered images in gipl formats in recent years. Where did the data sets come from?
It is a recycled data from an older publication. Here is the link:
https://app.box.com/s/bdtx5ys12un4e1bp5ccee6yl2c2d5589
Since DICOM files can have any file extensions, when Slicer loads a file, it checks if it can be interpreted as a DICOM file, by calling GDCMImageIO::CanReadFile(const char *filename). For the attached file, this check takes several minutes, as hundreds of errors are logged. After the check is completed and GDCM library finally realizes that it is not a DICOM file and the file is loaded correctly.
I’ll report this error to ITK: https://github.com/InsightSoftwareConsortium/ITK/issues/388
Until it gets fixed, I would recommend not to use gipl file format. In general, it is probably better to use more common file formats (nrrd, mha, maybe nifti).
OK. Thanks. It worked fine with 4.8.1.