Page MenuHomePhabricator | MITK

mitkBaseGeometry.cpp: Internal ITK matrix inversion error, cannot proceed.
Open, NormalPublic

Description

  1. load the image: . The image will be displayed correctly (but reinit is necessary)
  2. right click on image -> reinit
  3. enjoy!

Event Timeline

isensee created this task.Nov 26 2018, 11:21 AM

I accidentally uploaded the segmentation. This is the raw data. The problem occurs with both.

Log output with debug version:

!5.547! WARNING: EnsurePerpendicularNormal(): Plane geometry was _/askew/_, so here it gets rectified by substituting the 3rd column of the indexToWorldMatrix with an appropriate normal vector: [ 0.921861 -0.918454 -0.746066 ], original vector zed was: [ -0.943643 -3.64367e-09 -1.16599 ].
MitkWorkbench: ../../../../MITK/Modules/Core/src/DataManagement/mitkSlicedGeometry3D.cpp:273: virtual void mitk::SlicedGeometry3D::InitializePlanes(const mitk::BaseGeometry*, mitk::PlaneGeometry::PlaneOrientation, bool, bool, bool): Assertion `(standardPlaneNormal - (top ? 1.0 : -1.0) * worldPlaneNormal).GetSquaredNorm() < 0.000001' failed.

@isensee : what is the source of these images? any chance to get the original DICOM?

These images are from the Kora Dataset. Peter Full and @kislinsk have the original DICOM images.
The images were 4d DICOM originally and have been converted into 3d nifti by @kislinsk

@full @schererj @kislinsk : how did you convert these files exactly? If I load the DICOM with a current MITK Workbench -> no problem, re-init fine. Save as nifti, quit, restart, load nifti, re-init -> no problem as well.

So we should investigate two things: 1. what is different in your conversion process? 2. are "your" nifti files somehow invalid and should be rejected on load or should we able to handle them as well.

I converted them with a simple two-liner: mitk::IOUtil::Load<mitk::Image>(); mitk::IOUtil::Save();

Peter and I checked some output NIFTI images and they are valid 3d+t images. Reinit did also work. So for now I suspect that there is another processing step involved? The images above do not match my output files regarding name and file extension I think.

I'll catch some of the files on my way to the Hacking Week...

@full

As far as I can tell files were split along t with fslsplit.

Peter @full converted the files to .nii.gz

I added the _0000 manually. No tool involved here

Just checked the original DICOM and my output file of the derived image above. The original DICOM has the matrix inversion issue already. I bring the files along...

kislinsk triaged this task as Normal priority.Nov 28 2018, 9:41 AM

Even when deactivating the askew image handling, there's matrix inversion errors with the original image matrix.

Ideas for further investigation:

  • Visualize the axis vectors of the original image matrix (first three columns)
  • Check file in other applications (is there a reinit equivalent?)
hentsch added a subscriber: hentsch.Thu, Feb 7, 3:22 PM

I have the issue again with other data data from a cooperation partner. Also Slicer has issues with the original DICOM data set:

Geometric issues were found with 1 of the series.  Please use caution.
reg inside examine
Loading with imageIOName: GDCM
Window/level found in DICOM tags (center=212.0, width=487.0) has been applied to volume 25: CINE_segmented_SAX_InlineVF
Irregular volume geometry detected, but maximum error is within tolerance (maximum error of 4.00539e-05 mm, tolerance threshold is 0.001 mm).
Loading with imageIOName: GDCM
Window/level found in DICOM tags (center=212.0, width=487.0) has been applied to volume 25: CINE_segmented_SAX_InlineVF_1
Irregular volume geometry detected, but maximum error is within tolerance (maximum error of 4.00539e-05 mm, tolerance threshold is 0.001 mm).

I guess there's something wrong with the original image matrix.
MITK tries to fix the normal to be perpendicular, which leads to a matrix that can't be inverted anymore.

nolden added a comment.Fri, Feb 8, 8:39 AM

Looks like the Slicer warning is important, but still it succeeds in loading the data. The numerical error is rather low. Found this discussion which also links to the python code Slicer is using and which emits the warning. Could be of some use for further investigations. https://discourse.slicer.org/t/dicom-scalar-volume-load-irregular-geometry-warning-overly-stringent/3761/14