ITKReader does not read NRRD05 images with 'measurement frame' field

Describe the bug ITKReader throws an error when reading NRRD05 images with the “measurement frame” field. Here’s part of the traceback:

~/workspace/envs/sono-env/lib/python3.6/site-packages/monai/data/image_reader.py in _get_meta_dict(self, img)
    220             if key.startswith("ITK_original_"):
    221                 continue
--> 222             meta_dict[key] = img_meta_dict[key]
    223         meta_dict["origin"] = np.asarray(img.GetOrigin())
    224         meta_dict["spacing"] = np.asarray(img.GetSpacing())

~/workspace/envs/sono-env/lib/python3.6/site-packages/itk/ITKCommonBasePython.py in __getitem__(self, key)
    887         import itk
    888         obj = self.Get(key)
--> 889         return itk.down_cast(obj).GetMetaDataObjectValue()
    890     def __len__(self):
    891         return self.GetKeys().size()

~/workspace/envs/sono-env/lib/python3.6/site-packages/itkExtras.py in down_cast(obj)
   1198         raise RuntimeError(
   1199             "Can't downcast to a specialization of %s" %
-> 1200             className)
   1201     else:
   1202         return t.cast(obj)

RuntimeError: Can't downcast to a specialization of MetaDataObject

To Reproduce Run

import numpy as np
import SimpleITK as sitk
from monai.data import ITKReader
from monai.transforms import LoadImage

fn = "tmp.seg.nrrd"
data = np.zeros((3,3,3))
im = sitk.GetImageFromArray(data)
im.SetMetaData("NRRD_measurement frame", "(1,0,0) (0,1,0) (0,0,1)")
sitk.WriteImage(im, fn)

LoadImage(reader=ITKReader())(fn)

Commenting out the SetMetaData line runs fine.

Expected behavior ITKReader reads NRRD005 files.

Environment

================================
Printing MONAI config...
================================
MONAI version: 0.4.0
Numpy version: 1.17.4
Pytorch version: 1.6.0.dev20200528+cu101
MONAI flags: HAS_EXT = False, USE_COMPILED = False
MONAI rev id: 0563a4467fa602feca92d91c7f47261868d171a1

Optional dependencies:
Pytorch Ignite version: 0.4.2
Nibabel version: 3.2.1
scikit-image version: 0.17.2
Pillow version: 6.2.1
Tensorboard version: 2.4.0
gdown version: 3.12.2
TorchVision version: 0.7.0.dev20200528+cu101
ITK version: 5.1.2
tqdm version: 4.54.1
lmdb version: NOT INSTALLED or UNKNOWN VERSION.
psutil version: NOT INSTALLED or UNKNOWN VERSION.

Additional context Is ignoring the measurement frame field like this here an acceptable fix? https://github.com/adamaji/MONAI/commit/13cbe07e5af795f67560189b36a1486d4ce69f0e If so, I can issue the PR.

[thewtex]

This is addressed in https://github.com/InsightSoftwareConsortium/ITK/pull/2270, and will be available in a few weeks with the release of itk 5.2rc2.

[aylward]

A branch would just be a temporary solution until the official ITK release

• I agree that it is far from ideal, but I’m searching for a compromise.

The motivation is that MONAI is getting a large number of questions regarding I/O, and in particular, this version of ITK (RC2 and beyond) is intended to address those DICOM, NIFTI, and image coordinate ordering issues specifically for MONAI IO. We should perhaps try to involve as many people as possible in the nightly testing of ITK+MONAI, and that is arguably best accomplished by lowering the barriers to its use.

Perhaps telling folks to pip install is the better solution, but if they then suggest a bug/update, it can perhaps become problematic regarding where to commit a fix to MONAI that will allow the community to keep moving forward with evaluating RC2 (e.g., if that fix isn’t compatible with the prior version of ITK that MONAI uses).

In general, I fully agree that using an RC from a 3rd party app is bad practice, but since this ITK RC is so focused on fixing issues with MONAI, perhaps an exception / compromise of some sort needs to be made so that progress can be made in both toolkits simultaneously.

Again - just my opinion. We could also simply hold off on testing MONAI+ITK, but then bugs found in that release of ITK IO would not be fixed until its next release in a few months, and so MONAI would continue to have IO issues…definitely not a rapid development cycle…

Thanks, Stephen

On Wed, Feb 17, 2021 at 10:09 AM adam aji [e-mail] wrote:

@aylward https://github.com/aylward I’m not sure of a clean way to go about that – what’s the difference between pointing somebody to run pip install --upgrade --pre itk versus checking out a branch of Monai which uses release candidate libraries? Some questions I would have: is the branch ITK specific? Would we then want branches for the other libraries? Should we point people to using the release candidates of certain IO libraries if we’re not sure that the release candidate fixes the issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Project-MONAI/MONAI/issues/1451#issuecomment-780620796, or unsubscribe https://github.com/notifications/unsubscribe-auth/AACEJLYWZN5JUD34IBWQSK3S7PL2FANCNFSM4WC3GZ5A .

– Stephen R. Aylward, Ph.D. Senior Director of Strategic Initiatives

Kitware: Delivering innovative, open source, scientific software.