Open Nifti in 3D Slicer

[issakomi]

@issakomi

Does your tool currently write Nrrd files with sheared matrix?

I can answer it already. I tried dcm2niix with DICOM series (equidistant, parallel, gantry tilt) and “-e y” option, produced 2 files, one has shear matrix and another seems to be orthogonal and corrected.

The shear one looks like:

Neither Nrrd nor Nifti files with shear matrices were recognized by ITK as such. I didn’t look at Nrrd IO, but Nifti IO tried to detect it and failed.

It can be done like this, BTW, very simple (the values are from Nrrd files produced by dcm2niix):

#include <iostream>
#include <cmath>

typedef struct
{
	double x;
	double y;
	double z;
} V3;

static V3 normalize(V3 v)
{
	const double j = 1.0/(sqrt((v.x*v.x) + (v.y*v.y) + (v.z*v.z)));
	V3 vn;
	vn.x = v.x*j;
	vn.y = v.y*j;
	vn.z = v.z*j;
	return vn;
}

static double dot(V3 a, V3 b)
{
	return ((a.x*b.x) + (a.y*b.y) + (a.z*b.z));
}

static bool is_orthogonal(V3 v0, V3 v1, V3 v2)
{
	const double tolerance = 1e-3;
	const V3 n0 = normalize(v0);
	const V3 n1 = normalize(v1);
	const V3 n2 = normalize(v2);
	const double d = dot(n0, n1) + dot(n0, n2) + dot(n1, n2);
	const bool b = fabs(d) <= tolerance;
	return b;
}

int main(int argc, char ** argv)
{
#if 1
	// shear
	V3 v0;
	v0.x = -0.482422;
	v0.y = 0.03;
	v0.z = 0.0;

	V3 v1;
	v1.x = 0.0;
	v1.y = 0.50871;
	v1.z = 0.153075;

	V3 v2;
	v2.x = 0.0;
	v2.y = 2.38419e-07;
	v2.z = 2.24829;
#else
	// orthogonal
	V3 v0;
	v0.x = -0.482422;
	v0.y = -0.0;
	v0.z = 0.0;

	V3 v1;
	v1.x = 0.0;
	v1.y = 0.457492;
	v1.z = 0.153075;

	V3 v2;
	v2.x = -0.0;
	v2.y = -0.752269;
	v2.z = 2.24829;
#endif
	const bool b = is_orthogonal(v0, v1, v2);
	std::cout << "orthogonal = " << (b ? "yes" : "no") << std::endl;
	return 0;
}

[issakomi]

@issakomi

Neither Nrrd nor Nifti files with shear matrices were recognized by ITK as such.

Correction for Nifti file: ITK IO preferred qform for the file with shear matrix.

[Chris_Rorden]

For reference, the CT with gantry tilt (that results in a sheared matrix) that @issakomi refers to is available in DICOM and NIfTI format here. You can use dcm2niix to convert it to either NIfTI or NRRD. Since many tools do not handle shear, dcm2niix will also create a copy of the image where the image is interpolated to a orthogonal grid (with the _tilt extension to the file name). This provides an example of what the image should look like.

You can view the image in voxel space (where it appears distorted) or world space (which adjusts for gantry tilt) using the NiiVue live view web page - just drag and drop the NIfTI or NRRD image you wish to inspect. Use the world space button to choose between world (top) and voxel (bottom) space:

@lassoan now that ITK supports the same spatial transforms as other tools, I suspect the odd behavior you have been experiencing will diminish dramatically. In cases where the spatial transform was improperly specified, the user will get similar feedback regarding the odd setting regardless of the tool that is used. I also wonder if we could insert a bit of logic into ITK to detect malformed spatial transforms. With NRRD, the spatial transform is optional, but with NIfTI is is required. Therefore, I assume that reading a NRRD without a spatial transform is loaded with an identity matrix, while the explicit usage of a spatial transform in NIfTI requires the user to supply sensible values. Another thing to check with ITK is whether it can discriminate between NIfTI format files and its ancestor the Analyze format which did not include a spatial transform. Analyze files must be treated in the old way, as described in the NIfTI specification.

My tools tend to do a couple checks to detect a bogus spatial transform (regardless of the format). This logic may be useful for detecting files where the spatial transformation matrix should be used. The basic check is:

1. All values of the 4x4 spatial transformation matrix must be finite: NaNs, Infinity, negative Infinity suggest a borked matrix.
2. Assuming a 3D image (at least 2 voxels in each direction): For the 3x3 rotation matrix (e.g. ignoring translations) each row and each column must have at least one non-zero value and the 9 values of the matrix must have some variability.

[issakomi]

@Chris_Rorden

where the image is interpolated to a orthogonal grid (with the _tilt extension to the file name)

They (blue) are really nice and match perfectly with the original DICOM slices (red), BTW.

[Chris_Rorden]

@issakomi thanks for noticing. dcm2niix does attempt to preserve spatial information. The method is discussed here. It uses in-plane linear interpolation which might not be ideal for all applications. This can mean some loss of high frequencies, but for most uses is less jagged than nearest-neighbor and avoids the ringing artifacts of higher-order interpolation.

[pieper (Steve Pieper (Isomics, Inc.))]

A note to Slicer users, if you have DICOM images with gantry tilt or variable spacing you can use the Acquisition geometry regularization option is enabled as described here. This creates a nonlinear transform that can later be hardened with whatever options are needed in terms of filters and target sample grid.

[issakomi]

S. issue: Nifti file can not be opened after Jul 2020 commit · Issue #3514 · InsightSoftwareConsortium/ITK · GitHub

[issakomi]

Update. ITK rejected to fix the issue, the Nifti file is incorrectly written. S. post

P.S. I tried to download that VINCI, filled a form several days ago with address, phone, etc. and there is still no reply. The only thing i shall do with VINCI is to file a request to delete my personal data and confirm it.

[pieper (Steve Pieper (Isomics, Inc.))]

Thanks for following up on that @issakomi. I see Hans’s point and I don’t like supporting ill-formed nifti files but in this case it’s an unfortunate backwards compatibility issue with no clear path for users. On the plus side it’s probably not a common issue. If a lot of people end up having this trouble perhaps a nifti patcher like the dicom patcher would be the easiest solution.

[lassoan (Andras Lasso)]

Nifti file ambiguities and non-conformances such as this one could be caught early or automatically fixed up by Nifti IO implementations. Therefore it seems that a major contributor to Nifti headaches is that commonly used Nifti implementations behave inconsistently.

Is there a forum where handling of Nifti inconsistencies could be discussed and binding decisions could be made for all implementations that want to claim they comply to the standard?

[pieper (Steve Pieper (Isomics, Inc.))]

@lassoan

Is there a forum where handling of Nifti inconsistencies

The NIH encouraged working groups to standardize and expand nifti in the early 2000s but it’s always been pretty ad hoc. The closest now would be the BIDS group. But I don’t think it’ll ever by an ISO standard like DICOM with a formal process.

[lassoan (Andras Lasso)]

I see. This is quite discouraging. I added a comment to ITK#3514 to see if @hjmjohnson sees any chance that inconsistency of Nifti readers could be reduced.

[lassoan (Andras Lasso)]

@Chris_Rorden @issakomi could you help with answering @hjmjohnson at Nifti file can not be opened after Jul 2020 commit · Issue #3514 · InsightSoftwareConsortium/ITK · GitHub?

[dzenanz (Dženan Zukić)]

PR 6454 should fix many NIFTI-related issues. The latest preview release should have it now.