MONAI: 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.

About this issue

Original URL
State: closed
Created 3 years ago
Reactions: 1
Comments: 24 (21 by maintainers)

Commits related to this issue

BUG: Wrap MetaDataObject for Array and std::vector value types These are other commonly used times, e.g. when "NRRD_measurement frame" is set. Addresses: https://github.com/Project-MONAI/MONAI/issue... — committed to thewtex/ITK by thewtex 3 years ago
BUG: Wrap MetaDataObject for Array and std::vector value types These are other commonly used types, e.g. when "NRRD_measurement frame" is set. Addresses: https://github.com/Project-MONAI/MONAI/issue... — committed to thewtex/ITK by thewtex 3 years ago
BUG: Wrap MetaDataObject for Array and std::vector value types These are other commonly used types, e.g. when "NRRD_measurement frame" is set. Addresses: https://github.com/Project-MONAI/MONAI/issue... — committed to InsightSoftwareConsortium/ITK by thewtex 3 years ago

Most upvoted comments

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.

thewtex on Jan 27, 2021

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 notifications@github.com 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.

aylward on Feb 17, 2021

My gut feeling is not to have pre-releases in our requirements.txt

I think I agree with this, I can handle making the suggested changes sometime today or tomorrow if folks agree here

adamaji on Feb 16, 2021

Yes, that build addresses my issue – thanks! Should a requirements.txt be updated here to close this issue now, or should this be closed once that change is in a stable release?

Edit: For anyone running the “reproduce” section from the original post, it will return an image with 'NRRD_measurement frame': ((666666.0, ...), ..., which should be fine as I believe it’s just the default value when the dims of the measurement frame and image are different https://github.com/InsightSoftwareConsortium/ITK/blob/c2b399eef1248465a848a26231de66a8c9715132/Modules/IO/NRRD/src/itkNrrdImageIO.cxx#L1057 Loading a real image seems to work fine for me.

adamaji on Feb 15, 2021

Thanks for looking into this @thewtex !

adamaji on Jan 27, 2021

@rijobro @wyli thanks for the pointers. After starting from a clean conda environment, I ran into the same issue with BUILD_MONAI=1 python setup.py develop. But, I did a git pull, and I think I must have landed on an unlucky commit. It is working now 🔓 🍀. Thanks again!

thewtex on Jan 22, 2021

Hi @thewtex ,

Could you please help take a look at this issue and give a solution?

Thanks in advance.

Nic-Ma on Jan 15, 2021