BUG: Fix case where DICOM series order has negative spacing #5357

blowekamp · 2025-05-20T20:38:32Z

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 · 2025-05-20T20:43:55Z

relates to SimpleITK/SimpleITK#2292

dzenanz

Looks good after a quick look.

blowekamp · 2025-05-21T16:13:44Z

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 · 2025-05-21T16:18:53Z

Maybe we could have both of those tests?

blowekamp · 2025-05-21T17:30:01Z

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 · 2025-05-23T12:44:10Z

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 · 2025-05-23T13:14:12Z

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 · 2025-06-03T13:38:01Z

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 · 2025-09-16T02:02:26Z

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

Modules/IO/ImageBase/include/itkImageSeriesReader.hxx

blowekamp · 2025-09-22T16:09:46Z

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];

}

}

}

I just tries this patch with this dataset referenced. I used the file names in the order presented by GDCMSeriesFileNames:

-00-slice009.dcm
-00-slice008.dcm
-00-slice007.dcm
-00-slice006.dcm
-00-slice005.dcm
-00-slice004.dcm
-00-slice003.dcm
-00-slice002.dcm
-00-slice001.dcm
-00-slice000.dcm

When read in this order with the patch the direction(2,2) == -1.0, same as reported in the issue. When ReverseOrder is enable then direction(2,2,) == 1.0 and the physical geometry is the same. For both cases the space is [0.976562, 0.976562, 2].

This behavior is consistent and follow the expectations of the patch.

If the spacing between slices is negative, then direction cosine matrix was not correct with reguards to the sign. This can be easily created with the "ReverseOrder" flag with the series reader and DICOM data. With the correction, a DICOM series mantains its correct physical location when this flag is enabled.

thewtex

Please see the inline comments.

Please also add a test where the image is not orthogonal to the z-plane, i.e. the third direction component is neither [0,0,1] or [0,0,-1].

thewtex · 2025-09-23T18:36:31Z

Modules/IO/ImageBase/include/itkImageSeriesReader.hxx

+        {
+          for (unsigned int j = 0; j < TOutputImage::ImageDimension; ++j)
+          {
+            direction[j][this->m_NumberOfDimensionsInImage] *= -1.0;


This assumes that the image orientation is orthogonal to the z-plane. This is not always the case, e.g. some DICOMs. The solution should look more like:

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

Lines 194 to 197 in 31744be

for (unsigned int j = 0; j < TOutputImage::ImageDimension; ++j)

{

direction[j][this->m_NumberOfDimensionsInImage] = dirN[j] / dirNnorm;

}

The "direction" matrix helps transform index-space to xyz space. The third column by construction in GDCM is one of the orthogonal directions to the imaging planes:
https://github.com/InsightSoftwareConsortium/ITK/blob/main/Modules/IO/GDCM/src/itkGDCMImageIO.cxx#L734-L743

This is the case where the wrong direction was computed due to the spacing sign, or the order of the images, and its is being corrected. The non-orthogonal imaging is a separate case.

I understand that the third direction is orthogonal to the first two. That was not my point. And I was not referring to non-orthogonal imaging.

The axis that needs flipping might not be the third, but rather second or first. Is that your point Matt?

It is not necessarily a simple flip of one value.

blowekamp · 2025-09-23T19:26:15Z

Please also add a test where the image is not orthogonal to the z-plane, i.e. the third direction component is neither [0,0,1] or [0,0,-1].

The "ReadSlicesReverseOrder" has a no-trivial third direction component. The output of the test include the direction matrix without and with the reverse order flag:

baseline direction: 1 0 0
0 0.466651 0.884442
0 -0.884442 0.466651

reversed direction: 1 0 0
0 0.466651 -0.884442
0 -0.884442 -0.466651

thewtex · 2025-09-23T20:01:17Z

The output

When loaded in ITK-SNAP and Slicer, does this look correct? Is it LPS?

blowekamp · 2025-09-24T12:28:29Z

The output

When loaded in ITK-SNAP and Slicer, does this look correct? Is it LPS?

I am not certain what your request is here.

When ReverseOrder is off ( the default ) this image is the same as before. The test checks that the physical location of the pixels values remains. If there are additions to the gtest requested please be specific. It is not reasonable to compile of ITK-SNAP and/or 3D slicer with this patch. I do understand that effecting the location of DICOM images could have serious impact and this change needs careful review and testing.

thewtex · 2025-09-26T13:58:41Z

To help ensure we are getting correct behavior with DICOM's ,please add a test where the input does not have any 0's and 1's in the direction matrix. And add a check in the test that the resulting direction matrix's third vector equals the cross product of the first two.

dzenanz approved these changes May 20, 2025

View reviewed changes

blowekamp force-pushed the dicom_series_reverse branch from 0ba9197 to cb4f83f Compare May 21, 2025 16:12

blowekamp force-pushed the dicom_series_reverse branch from cb4f83f to d46d322 Compare May 29, 2025 15:19

blowekamp requested review from thewtex and hjmjohnson June 3, 2025 13:38

thewtex reviewed Sep 16, 2025

View reviewed changes

Modules/IO/ImageBase/include/itkImageSeriesReader.hxx Outdated Show resolved Hide resolved

blowekamp force-pushed the dicom_series_reverse branch from d46d322 to 6aba916 Compare September 22, 2025 15:33

blowekamp marked this pull request as ready for review September 22, 2025 16:11

blowekamp force-pushed the dicom_series_reverse branch 2 times, most recently from 84e2a15 to eec7c09 Compare September 23, 2025 13:16

blowekamp force-pushed the dicom_series_reverse branch from eec7c09 to 25ee357 Compare September 23, 2025 17:53

thewtex requested changes Sep 23, 2025

View reviewed changes

	for (unsigned int j = 0; j < TOutputImage::ImageDimension; ++j)
	{
	direction[j][this->m_NumberOfDimensionsInImage] = dirN[j] / dirNnorm;
	}

Uh oh!

BUG: Fix case where DICOM series order has negative spacing #5357

Are you sure you want to change the base?

BUG: Fix case where DICOM series order has negative spacing #5357

Uh oh!

Conversation

blowekamp commented May 20, 2025

PR Checklist

Uh oh!

blowekamp commented May 20, 2025

Uh oh!

dzenanz left a comment

Choose a reason for hiding this comment

Uh oh!

blowekamp commented May 21, 2025

Uh oh!

dzenanz commented May 21, 2025

Uh oh!

blowekamp commented May 21, 2025

Uh oh!

N-Dekker commented May 23, 2025

Uh oh!

blowekamp commented May 23, 2025

Uh oh!

blowekamp commented Jun 3, 2025

Uh oh!

ashwinkumargb commented Sep 16, 2025

Uh oh!

Uh oh!

blowekamp commented Sep 22, 2025

Uh oh!

thewtex left a comment

Choose a reason for hiding this comment

Uh oh!

thewtex Sep 23, 2025

Choose a reason for hiding this comment

Uh oh!

blowekamp Sep 23, 2025

Choose a reason for hiding this comment

Uh oh!

thewtex Sep 23, 2025

Choose a reason for hiding this comment

Uh oh!

dzenanz Sep 23, 2025

Choose a reason for hiding this comment

Uh oh!

thewtex Sep 23, 2025

Choose a reason for hiding this comment

Uh oh!

blowekamp commented Sep 23, 2025

Uh oh!

thewtex commented Sep 23, 2025

Uh oh!

blowekamp commented Sep 24, 2025

Uh oh!

thewtex commented Sep 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

thewtex commented Sep 26, 2025 •

edited

Loading