Page MenuHomePhabricator

Issue with DICOM SEG -> NIFTI conversion: missing empty slices
Closed, ResolvedPublic

Description

When I open some DICOM SEG with the corresponding CT in the MITK Workbench, everything is working and presented correctly in the viewer.
When I then save this DICOM SEG as NIFTI (nii.gz), the resulting dimensions of the NIFTI are not identical to the CT image.

I guess this is because of skipping of empty slices during the export to NIFTI.
This is probably fine for some applications, but we have issues with this behavior within Kaapana and our pipelines (it expects similar dimensions).

-> Is there a way to include the empty slices in the exported file? (This is still a guess, though..)

MITK version: MITK-snapshots_2021-01-25-linux-x86_64

Example files can be found in T28214 (ct_images.zip)

Dimensions of this example data:
CT: [512, 512, 140]
NIFTI: [512, 512, 7]

Related Objects

StatusAssignedTask
Resolvedneher

Event Timeline

schererj created this task.

As far as I know, this is crucial for the RACOON project. So for the Kaapana side, this has a high priority.

As discussed I would solve it by using a tool to resample/pad the segmentation to the same size like the image.
I will have a look on the most pragmatic way to provide the CLI.

floca added a parent task: Restricted Maniphest Task.Jan 28 2021, 10:44 AM

OK. Following options/state:

  1. CLResampleImageToReference: MiniApp in the Classification Module which offers simple resampling.
    • Pro:
      • It is limited, but does nearly what you need.
    • Con:
      • Is not part of the release installer and will not be soon (Classification dependency). So has to be build on its own.
      • currently uses linear interpolation hard coded. Should work for this use case. But nearest neighbour would make more sense here because you want no interpolation.
  2. MapImageMiniApp: Planned MiniApp that offers all options of the mapper view. Part of the MatchPoint Module
    • Pro:
      • Does everything what you need
      • Will be in the release installer
    • Con:
      • Is not there yet.
      • Ralf would need a day time. and is not sure when it can be squeezed in.

So I think it pretty boils down who fast you need it and if who long you could wait for option 2. Any idea?

For RACOON we need it in the next weeks. Sooner is better of course :)
We could simply adapt CLResampleImageToReference to optionally use NN. Should be easy enough. I will take a look today.

Thank you very much for the super fast response!
For me this is only coupled to the training support within Kaapana.

So as far as I know the only current project, which needs this is RACOON.
In this context I would like to have a training working around the begin of March (@neher would that be fine?)

Do you think this would be enough for option 2?

These parameter descriptions don't really make sense, no?

parser.addArgument("fix", "f", mitkCommandLineParser::Image, "Input Image", "Path to the input VTK polydata", us::Any(), false, false, false, mitkCommandLineParser::Input);
parser.addArgument("moving", "m", mitkCommandLineParser::File, "Output text file", "Target file. The output statistic is appended to this file.", us::Any(), false, false, false, mitkCommandLineParser::Output);
parser.addArgument("output", "o", mitkCommandLineParser::File, "Extension", "File extension. Default is .nii.gz", us::Any(), false, false, false, mitkCommandLineParser::Output);

I added the functionality to choose the interpolator. I forgot how to merge it :) Arcanist? And land on develop?

Yes the easiest way would be arc diff and arc land.
Just a side note: As MITK also uses gitflow now, a compliant branch name would be feature/* or bugfix/*.

As you have fixed it in the classification mini app, it gives me some time. *poohhh*
But the MapImageMiniApp will come sooner then later, because we will need it also in other occasions. Then the provisioning will become easier also for your usecase.

These parameter descriptions don't really make sense, no?

parser.addArgument("fix", "f", mitkCommandLineParser::Image, "Input Image", "Path to the input VTK polydata", us::Any(), false, false, false, mitkCommandLineParser::Input);
parser.addArgument("moving", "m", mitkCommandLineParser::File, "Output text file", "Target file. The output statistic is appended to this file.", us::Any(), false, false, false, mitkCommandLineParser::Output);
parser.addArgument("output", "o", mitkCommandLineParser::File, "Extension", "File extension. Default is .nii.gz", us::Any(), false, false, false, mitkCommandLineParser::Output);

Nope. I guess a copy and paste error from Micheal (or who ever wrote the code).

Who should I assign as reviewer for this?

Who should I assign as reviewer for this?

For arc you don't have to assign one explicitly, if you want to I would assume from the bug history @floca could be a candidate ;)

Who should I assign as reviewer for this?

For arc you don't have to assign one explicitly, if you want to I would assume from the bug history @floca could be a candidate ;)

If you want speed up the review process. We currently have the policy that you add a reviewer, after you have clarified that she/he can do the review.

neher claimed this task.