[MAC-GUI] Using 3D Dicoms instead of niftis causes dimensionality mismatch in some algorithms

[rongguangw]

Describe the bug After click the "Geodesic Training Segmentation" and wait for a few seconds, an error prompt out "The physical dimensions of the previously loaded image and the mask are inconsistent".

To Reproduce Steps to reproduce the behavior:

1. Load in the different images, that are different modalities of the same subject.
2. Draw over the images using CaPTk's drawing tools.
3. Click Applications>'Geodesic Training Segmentation' from the menu and wait ~30 seconds.
4. See error

Expected behavior See the output segmentation where my labels were previously drawn.

Screenshots

CaPTk Version CaPTk_1.7.6

Desktop:

• OS: macOS
• Version: 10.15.3 (19D76)

[dboun]

I really can't recreate this. I tried it with 2D, 3D, 4D, and 2D images that are saved as 3D with the last dimension as one. I tried running segmentations with 2D images and then unload them and run with 3D and vice versa.

(this seems to be coming from the "ImageSanityCheck" stuff that happen in CaPTk) (maybe mac has to do with it too?) idk

@rongguangwang Can you please

• Try this again with a brand new instance of CaPTk. Launch captk, don't do anything else with it, load an image and try to draw briefly with 2+ labels and run geodesic training
• Maybe share some of the data, you used for this issue, on the cluster.

[rongguangw]

Currently, I'm using the Mac version of CaPTk_1.7.6. I thought CaPTk_1.7.6 is the latest version?

Of course, the dataset I used for testing is open-access on the cluster in the below directory:

/cbica/home/wangron/tumor/

[dboun]

Thanks for sharing the data!

I meant something different, but nevermind it. 1.7.6 is the correct version. I have replicated it now so no need for you to do anything :)

@sarthakpati @ashishsingh18 This is not an issue with geodesic training. It is with the dicom reader. I tried it:

• By loading the first image of the series into CaPTk.
• By converting dcm to 3D nifti image It worked when the image was first converted to nifti. But with loading directly the dicom in CaPTk it fails because of dimensionality mismatch between the 1st image of the data manager and the segmentation. I presume that's because captk thinks that it is a bunch of 2D images (-> slices) and not one 3D image.

[rongguangw]

No problem!

I forgot to mention that similar situation happens to "N4 Bias Correction". An error also prompt out "The physical dimensions of the previously loaded image and the mask are inconsistent" after the correction process finished. However, this function do output a corrected image in the specified directory.

[ashishsingh18]

Thanks for sharing the data!

I meant something different, but nevermind it. 1.7.6 is the correct version. I have replicated it now so no need for you to do anything :)

@sarthakpati @ashishsingh18 This is not an issue with geodesic training. It is with the dicom reader. I tried it:

* By loading the first image of the series into CaPTk.

* By converting dcm to 3D nifti image
  It worked when the image was first converted to nifti. But with loading directly the dicom in CaPTk it fails because of dimensionality mismatch between the 1st image of the data manager and the segmentation. I presume that's because captk thinks that it is a bunch of 2D images (-> slices) and not one 3D image.

Thanks for sharing the data!

I meant something different, but nevermind it. 1.7.6 is the correct version. I have replicated it now so no need for you to do anything :)

@sarthakpati @ashishsingh18 This is not an issue with geodesic training. It is with the dicom reader. I tried it:

* By loading the first image of the series into CaPTk.

* By converting dcm to 3D nifti image
  It worked when the image was first converted to nifti. But with loading directly the dicom in CaPTk it fails because of dimensionality mismatch between the 1st image of the data manager and the segmentation. I presume that's because captk thinks that it is a bunch of 2D images (-> slices) and not one 3D image.

@dboun I don't believe this is a problem with the dicom reader. We are not changing the dimensions of the data during dicom reading. This has to do with something that we are doing before/after the dicom reading. Can you point me to the exact dicom data you are loading that gives this issue?

I tried with the data from @rongguangwang and it turns out that that dicom data has different z dimensions. We don't allow loading such data in case of nifti. However with dicom this was getting loaded.

[dboun]

I tried with the data from @rongguangwang and it turns out that that dicom data has different z dimensions. We don't allow loading such data in case of nifti. However with dicom this was getting loaded.

@ashishsingh18 This problems occurs with loading a single series. That series corresponds to single itk::Image. There can be no dimensionality mismatch if it's just one image.

Try to load a series by dragging the first file and then run geodesic or the other algorithm

[ashishsingh18]

I tried with the data from @rongguangwang and it turns out that that dicom data has different z dimensions. We don't allow loading such data in case of nifti. However with dicom this was getting loaded.

@ashishsingh18 This problems occurs with loading a single series. That series corresponds to single itk::Image. There can be no dimensionality mismatch if it's just one image.

Try to load a series by dragging the first file and then run geodesic or the other algorithm

@dboun This has nothing to do with loading. Infact your algorithm runs and even writes out the segmented result in the temp directory. The problem occurs when that result is read via readmask function. Something is not right with the imagesanity checks there.

[dboun]

@dboun This has nothing to do with loading. Infact your algorithm runs and even writes out the segmented result in the temp directory. The problem occurs when that result is read via readmask function. Something is not right with the imagesanity checks there.

I know that the algorithm works and runs. But the sanity checks are relatively simple, they check if there is a mismatch between what you are trying to load and what is in captk. That's why I'm saying the problem is probably earlier. If you read above, you will see I tried to convert the dcm->nifti first and everything worked

[AlexanderGetka-cbica]

From what I am reading, this sounds similar to the problem I have with #757.

Check to see if the origin isn't messed up by the ReadImageWithOrientFix call when loading the mask for checking with ImageSanityCheck -- that is what was causing my "inconsistent dimensions" failure. EDIT: maybe not, if it works if you convert it first... but maybe worth a check.

[ashishsingh18]

@dboun This has nothing to do with loading. Infact your algorithm runs and even writes out the segmented result in the temp directory. The problem occurs when that result is read via readmask function. Something is not right with the imagesanity checks there.

I know that the algorithm works and runs. But the sanity checks are relatively simple, they check if there is a mismatch between what you are trying to load and what is in captk. That's why I'm saying the problem is probably earlier. If you read above, you will see I tried to convert the dcm->nifti first and everything worked

@dboun I have checked this thoroughly and can tell you that the problem is not earlier. I have even checked the properties of the loaded image. The problem is with readmask and image sanity checks for sure.

[ashishsingh18]

From what I am reading, this sounds similar to the problem I have with #757.

Check to see if the origin isn't messed up by the ReadImageWithOrientFix call when loading the mask for checking with ImageSanityCheck -- that is what was causing my "inconsistent dimensions" failure. EDIT: maybe not, if it works if you convert it first... but maybe worth a check.

@AlexanderGetka-cbica I checked the origin as well. It is not that either. ReadImageWithOrientFix is getting called though. I am guessing this could be a rounding issue..