Bias correction gives an error

[sarthakpati]

Describe the bug Bias correction fails to complete.

To Reproduce Steps to reproduce the behavior:

1. Load image
2. Click 'Preprocessing > Bias Correct'
3. Default options for either N3 or N4
4. See error:

   The error of the previously loaded image and the current image are inconsistent; proceed to open registration dialog.

   This error message was repeatable at about 90% completion on multiple images that was tested.

CLI works fine.

Expected behavior There should not be any error.

CaPTk Version 1.8.0.Beta

Desktop (please complete the following information):

• OS: Windows
• Version: 10

Additional context Reported by @ChitaliaR

[AlexanderGetka-cbica]

Is it possible for me to get some of the input data used? I am having trouble replicating this.

I also cannot find "error of the previously loaded image" anywhere in the code, though I can find similar messages for physical dimensions, origin, spacing, sizes... is this error message accurate?

[AlexanderGetka-cbica]

Comparing a random file and its bias-corrected output:

.\Utilities.exe -i F:\work\SampleData\PseudoProgressionEstimator\ABFC\CONVENTIONAL\ABFC_t1ce_pp.nii.gz -inf ITK Image information:. Property,Value Dimensions,3 Size,192x256x192 Total,9437184 Origin,-91.130997x-156.126999x-79.760002 Spacing,0.977000x0.977000x1.000000 Component,short Pixel Type,scalar Directions,[1.000000x-0.000000x0.000000;-0.000000x1.000000x0.000000;-0.000000x-0.000000x1.000000] .\Utilities.exe -i F:\work\SampleData\PseudoProgressionEstimator\ABFC\CONVENTIONAL\biasCorrect.nii.gz -inf ITK Image information:. Property,Value Dimensions,3 Size,192x256x192 Total,9437184 Origin,-91.130997x-156.126999x-79.760002 Spacing,0.977000x0.977000x1.000000 Component,float Pixel Type,scalar Directions,[1.000000x-0.000000x0.000000;-0.000000x1.000000x0.000000;-0.000000x-0.000000x1.000000]

Only difference I see is the pixel value type (short in input vs. float in output). But I can load both images together on my machine.

[sarthakpati]

Tagging @ChitaliaR for clarification, as this was her error report.

[ChitaliaR]

Hi Alex, I've linked some example images that I used. After loading in the image and selecting N3 bias correction under pre-processing, I would get the error message around 90% of the way through the calculation. https://drive.google.com/file/d/107_0XW9OLe530D5HzsCNFGAz-N6Cjzs-/view?usp=sharing,%20https://drive.google.com/file/d/1LkUcL35QNbEmHdC-4gnzalRk_uSWhWA2/view?usp=sharing,%20https://drive.google.com/file/d/1dyxhSEGuGnarrR3jcuyAIwDYxI8cxbXz/view?usp=sharing

[ChitaliaR]

Here's some screen shots going through the screens I see! https://drive.google.com/file/d/1KjOB5u5TeHFM1NZRMiKTcLQUtzL7ctMG/view?usp=sharing

[AlexanderGetka-cbica]

Hi @ChitaliaR , thank you for the report and for the example input + screenshots! I am now able to replicate this issue using your input. It seems that the bias correction algorithm is producing output with different origins and spacing than the input in some cases. CaPTk then refuses to load these images together. I will be looking further into this.

[AlexanderGetka-cbica]

As a note, bias correction does produce output in the specified location -- it just fails to load into CaPTk's GUI afterwards. However, if you call BiasCorrection from the CLI, the resulting output images can be loaded into the GUI alongside the original image. In fact, comparing the two outputs (CLI and GUI) it seems like there is a change in directionality between the two:

Original:

ITK Image information:. Property,Value Dimensions,3 Size,256x256x60 Total,3932160 Origin,-26.100000x-108.800003x-101.296875 Spacing,0.703125x0.703125x2.000000 Component,short Pixel Type,scalar Directions,[-0.000000x1.000000x0.000000;-0.000000x-0.000000x1.000000;-1.000000x0.000000x-0.000000]

CLI bias-corrected (n4):

ITK Image information:. Property,Value Dimensions,3 Size,256x256x60 Total,3932160 Origin,-26.100000x-108.800003x-101.296875 Spacing,0.703125x0.703125x2.000000 Component,float Pixel Type,scalar Directions,[-0.000000x1.000000x0.000000;-0.000000x-0.000000x1.000000;-1.000000x0.000000x-0.000000]

GUI bias-corrected (N4):

ITK Image information:. Property,Value Dimensions,3 Size,60x256x256 Total,3932160 Origin,-144.100006x-108.800003x-101.296875 Spacing,2.000000x0.703125x0.703125 Component,float Pixel Type,scalar Directions,[1.000000x-0.000000x0.000000;-0.000000x1.000000x0.000000;-0.000000x-0.000000x1.000000]

I think this is an interaction involving how the CaPTk GUI sometimes reorients images during the loading process.

[sarthakpati]

I think this is an interaction involving how the CaPTk GUI sometimes reorients images during the loading process.

This should be uniform for both the input and loaded image as both call LoadSlicerImages, which handles the orientations. I know that DeepMedic calls on fMainWindow::SaveImage_withFile to save image with original image information whereas SBRT does not. Maybe this helps?

[AlexanderGetka-cbica]

The image produced with by callingfMainWindow::SaveImage_withFile rather than cbica::WriteImagedirectly has the following characteristics:

.\Utilities.exe -i F:\work\SampleData\test-bias-correction-chitalia\biasCorrect-saveImage_withFile-fix.nii.gz -inf ITK Image information:. Property,Value Dimensions,3 Size,60x256x256 Total,3932160 Origin,-26.100000x-108.800003x-101.296875 Spacing,2.000000x0.703125x0.703125 Component,float Pixel Type,scalar Directions,[-0.000000x1.000000x0.000000;-0.000000x-0.000000x1.000000;-1.000000x0.000000x-0.000000]

Seems like the SaveImage_withFile copies the direction and origin but not the spacing. It does this by copying the original information from the mSlicerManager. But the size/spacing information isn't consistent with this (axes swapped around).

[sarthakpati]

Oh damn. This is probably because the image is getting re-oriented to RAI using cbica::ReadImageWithOrientFix. Perhaps one way would be to return the original orientation from this function and save it to mSlicerManager as "original orientation" (there is already a function cbica::GetImageOrientation that does this). And then, from fMainWindow::SaveImage_withFile, use this to re-orient the image before using the original direction and origin.

[sarthakpati]

Oh damn. This is probably because the image is getting re-oriented to RAI using cbica::ReadImageWithOrientFix. Perhaps one way would be to return the original orientation from this function and save it to mSlicerManager as "original orientation" (there is already a function cbica::GetImageOrientation that does this). And then, from fMainWindow::SaveImage_withFile, use this to re-orient the image before using the original direction and origin.

Okay, so I have just added this in the aforementioned commits. Could you please test to ensure it works, @AlexanderGetka-cbica?

[AlexanderGetka-cbica]

This is the image info of the output of SaveImage_withFile called after loading the original file.

.\Utilities.exe -i F:\work\SampleData\test-bias-correction-chitalia\saveImage_wSarthakModification.nii.gz -inf ITK Image information:. Property,Value Dimensions,3 Size,256x256x60 Total,3932160 Origin,-26.100000x-108.800003x-101.296875 Spacing,0.703125x0.703125x2.000000 Component,float Pixel Type,scalar Directions,[-0.000000x1.000000x0.000000;-0.000000x-0.000000x1.000000;-1.000000x0.000000x-0.000000]

This makes more sense, now -- SaveImage_withFile is actually reorienting the image back to its original state instead of just slapping on info that doesn't match the image data itself. But SaveImage_withFile only saves images that are already loaded, so this issue isn't fixed yet. Still, it is good to have that fix... @sarthakpati Shall I create a similar function that follows this process for an image in memory (reorienting to the selected image's original direction) and just call that on the BiasCorrection output? Seems like the simplest way to do this without deferring to the CLI and writing temp files.

[sarthakpati]

I'd guess the quickest mechanism would be to just call the CLI after calling SaveImage_withFile, or am I missing something?

SaveImage_withFile saves the selected image, not all of the loaded images, which is the behavior we want.

[AlexanderGetka-cbica]

This was fixed with PR #1247. Closing.