BUG: Fix case where DICOM series order has negative spacing

[blowekamp]

If the spacing between slices is negative, then direction cosine matrix was not correct with reguards to the sign.

PR Checklist

• No API changes were made (or the changes have been approved)
• No major design changes were made (or the changes have been approved)
• Added test (or behavior not changed)
• Updated API documentation (or API not changed)
• Added license to new files (if any)
• Added Python wrapping to new files (if any) as described in ITK Software Guide Section 9.5
• Added ITK examples for all new major features (if any)

Refer to the ITK Software Guide for
further development details if necessary.

[blowekamp]

relates to SimpleITK/SimpleITK#2292

[dzenanz]

Looks good after a quick look.

[blowekamp]

I update the test case to use the sample MRI series in ITK test data, and use the ReverseOrder flag. The test is compare the pixel values at the physical locations match.

[dzenanz]

Maybe we could have both of those tests?

[blowekamp]

Maybe we could have both of those tests?

The DICOM tags were not correct in the prior example test case where the DICOM files were manually created. And oddly the X,Y spacing was being swapped for some reason likely related to the TAGs. Also this test case for the file has a non identify cosine matrix, which helps verifies the correct column was multiplied and not a row by -1.

[N-Dekker]

Thanks @blowekamp I'm just trying to understand the issue. It reminds me of an ITKElastix issue reported by @thewtex:

• GroupwiseRegistration notebook: ERROR: the direction cosines matrix of the fixed image is invalid! ITKElastix#291

Which appeared related to ImageFileReader::GenerateOutputInformation():

ITK/Modules/IO/ImageBase/include/itkImageFileReader.hxx

Lines 222 to 235 in b375cef

	// Spacing is expected to be greater than 0
	// If negative, flip image direction along this axis.
	// and store this information in the metadata
	for (unsigned int i = 0; i < TOutputImage::ImageDimension; ++i)
	{
	if (spacing[i] < 0)
	{
	spacing[i] = -spacing[i];
	for (unsigned int j = 0; j < TOutputImage::ImageDimension; ++j)
	{
	direction[j][i] = -direction[j][i];
	}
	}
	}

[blowekamp]

The original issue was reported in SimpleITK here:
SimpleITK/SimpleITK#2292

The cause appeared to be that the z-slice direction was negative. This was more easily reproduce by enabling the "ReverseOrder" flag.

It may very well be likely related to this change too:

ITK/Modules/IO/ImageBase/include/itkImageFileReader.hxx

Lines 222 to 235 in b375cef

	// Spacing is expected to be greater than 0
	// If negative, flip image direction along this axis.
	// and store this information in the metadata
	for (unsigned int i = 0; i < TOutputImage::ImageDimension; ++i)
	{
	if (spacing[i] < 0)
	{
	spacing[i] = -spacing[i];
	for (unsigned int j = 0; j < TOutputImage::ImageDimension; ++j)
	{
	direction[j][i] = -direction[j][i];
	}
	}
	}

It's not clear to me if the original DICOM reported in SimpleITK had negative spacing. The "ReverseOrder" reproduction of the issue, has negative inter-slice distance. There is certainly areas that need further investigation.

The principle used in the test, that for DICOM if the "reverse order" flag is set then the physical location of the voxel should be maintained, should be correct. But DICOM is complicated.

[blowekamp]

This patch does not directly deal with the DICOM tags, and specific DICOM information. It only correct a sign change in the DirectionCosine matrix when detected to maintain consistent physical spacing when the order is reversed. The specifics of multi-frame DICOM are not handled here.

If there is a specific DICOM series that should be tested, we can manually do that to ensure consistency.

Otherwise, I think this patch should be good?

[ashwinkumargb]

@thewtex @hjmjohnson is there any update on this PR? Would be great to get this issue resolved as it's affect pre-processing pipelines!

[thewtex]

In general, I do not think this is necessarily 1.0, -1.0.