Data z-spacing is suspicious in certain cases

[neheller]

This is referencing an issue first raised on Discourse here. case_00002 and case_00003 were mentioned in particular but the report is that there may be others.

[ghumpire]

@neheller, Were you able to reproduce this issue?

[neheller]

Sorry for the delay. I was able to verify that the released spacing does match the values from the DICOM imaging, but of course that doesn't necessarily mean it matches the real world.

Sometime between now and April 15, we will be releasing a copy of the data with fixed spacing all around. We will take care to ensure that the spacing truly is consistent from case to case.

[neheller]

On further exploration, the issue was the way I was extracting spacing from the DICOM imaging. Thanks again for discovering this, and it will be fixed in the release next week.

[neheller]

This has been addressed in the amended training data release. Please feel free to reopen if you still see any that look suspicious.

[ghumpire]

Thanks for the update. After pulling your changes, I visualized the new CT scans and found issues in other orthogonal directions. Before going into details, just to be in the same page, I attached an image below where: sagital, coronal, and axial orthogonal views are displayed in the first, second, and third columns respectively. Now, just to summarize what I found in the first and second versions:

• In your first version (March ~15th), the CT scans looked natural in the axial view but the coronal and sagittal. See first row of the image below.
• In your second version (April 15th), the CT scans look better in coronal view but axial and sagittal look distorted. See second row of the image below.

I tried to fix this issue and I think I did it, or at least the images I generated look more natural. Firstly, I think this issue is related to #9 (any Software that visualizes the CT scans shows the scans in sagittal view, which usually should be axial view). My workaround is simple (a similar workaround reported in #15 by @huyu398 using SimpleITK):

• Read a case from the repo.
• Swap axis 0 and 2 of the CT scan.
• Open the json file, retrieve the captured_pixel_width and captured_pixel_width values for the case you are reading.
• Replace the old voxel spacing with [captured_slice_thickness, captured_pixel_width, captured_pixel_width].

Sorry if I did not use nibabel to show my workaround, I am not familiar to it and I preferred to show the steps instead of making a mistake.

My workaround generates more natural CT scans. Below you can find screenshots of the first version, second version, and my suggestion. Note that red boxes represent slices that does not look natural, the green boxes show slices that (I think) look natural. Also note that the second version and my suggestion have green boxes but I think that my workaround looks slightly more natural.

[neheller]

Thanks for the thorough report!

To clarify the intended spacing:

• captured_slice_thickness is the distance in the z-direction between axial slices.
• captured_pixel_width is the distance in the x and y-directions between adjacent pixels within axial slices.

The data array stored within nibabel is indexed by (z, y, x). In commit 236685c7fd70c74b29cc8732bd5b9e3903737627 I changed the spacing to

array([[0.                   , 0.                   , captured_slice_thickness , 0. ],
       [0.                   , captured_pixel_width , 0.                       , 0. ],
       [captured_pixel_width , 0.                   , 0.                       , 0. ],
       [0.                   , 0.                   , 0.                       , 1. ]])

But I see now that this still has a few issues. (1) it disobeys the sign convention, and (2) it's actually the transpose of what I want. I have now changed it to

array([[0.                          , 0.                      , -1*captured_pixel_width , 0. ],
       [0.                          , -1*captured_pixel_width , 0.                      , 0. ],
       [-1*captured_slice_thickness , 0.                      , 0.                      , 0. ],
       [0.                          , 0.                      , 0.                      , 1. ]])

And ITK-SNAP finally shows natural looking images.

Thanks so much for your patience and help through this process. The commit with the fix has been pushed to master: 8b73b0472a86d71bbfa518fa7f96b72a0bba5fae.

[neheller]

I'm going to leave this open until I hear confirmation that it looks good on your end as well.

[dericdesta]

Thanks for the final fix. Looks good to me :slightly_smiling_face:.

[ghumpire]

Looks good now! thank you very much!