Ok, since this issue made it impossible to use v2023.04 in Kaapaana mitk-flow, I am still on the previous release, where it kind of works?
So I would stay on this previous release until there is a new MITK version addressing these DICOM issues.
For now we are highly dependent on dicoms, so we don't have the option to just store the files in another file format...

Pushed new branch to rMITK MITK: feature/T30176-FindTask.

I just did the Pic3D/brain test mentioned above and it works with v2023.04.

@gaoh Since we released MITK v2023.04.2 yesterday specifically addressing a DICOM-SEG issue I kind of got an overview of the overall situation in MITK regarding saving DICOM-SEGs.

We could set up a test case to check if it is still an issue in the context of segmentation task lists. A segmentation task list with two tasks, one task referencing Pic3D.nrrd, the other task referencing the tilted brain.nrrd image. If this is working with the latest release it should be a proof that is not an issue anymore.

Thanks for the report. We recently removed this functionality from MITK so I would like to close this task as Wontfix if you are fine with the workaround you mentioned?

Deleted branch from rMITK MITK: bugfix/T29649-ClassificationModuleCleanUp.

@holzwart Which version of MITK and which plugin do you use?

The tag v2023.04.2 was created on the branch hotfix/T30163-v2023.04.2, which should not be deleted.

Pushed new branch to rMITK MITK: bugfix/T29649-ClassificationModuleCleanUp.

It's agreed in the meeting that the status quo is inconsistent.

With the addition of the polygon tool, this is now possible.

@goetzm Thank you for the patch. We will look into it and merge it for parts that we keep (see T29649). If change your mind and want to maintain the rest of the classification code base in an extension, we can revisit it and see how we can help with merging the rest. Best Ralf

Yes, after commenting the 4 lines in the mitkExtractSliceFilter I am getting 3 component image.
Also, found out that the following works instead of commenting the snippet out:
Comment vectorComponentExtractor->SetComponents(m_Component); and pass on exact component needed to vectorComponentExtractor->SetComponents(0,1,2);.

Your "solution" is not a real fix. It just exploits a bug/undefined behavior. So do not do it

Checklists updated

Oh ok. Yes, I can the see the pixel type "rgb". Also, when I save the mitk::Image object using IOUtils::Save, I can see (in python) that the written image is 3 channel.
But the issue still occurs, channel is information is ultimately lost here in mitk::SegWithPreviewTool::UpdatePreview:

Be carefull. RGB channels of an RGB image are not stored in different mitk::Image channels currently. Every thing is stored in one channel. But the channel has the pixel type "rgba". So the channels are encoded in each pixel.

After a little debugging, I see that even DataNode::GetData() returns single channel Image.
eg. dynamic_cast<const Image *>(m_SegmentationInputNode->GetData())
SegPreviewTool class uses this image for further processing.

Anyway after discussing with Ralf, the problem at hand - implementing levelwindow effect of input images to SAM, is solved using itk::IntensityWindowingImageFilter.

Updated document: https://hub.dkfz.de/f/55254009

1. I am seeing the array in python after writing it out IOUtil::Save(mitkImage, imagePath);. That's 4 channel image. ie. 32x32x4.
2. I use vtkMitkLevelWindowFilter because you recommended(?) and also its used by MITK for its levelwindow processing and at few other occasions. So this data type change is widely affecting MITK. But whether its compensated somewhere else or not is not clear for me.

But for SAM tool- Thanks for the tip, I will try out vtkImageMapToColors and see.

You seem to mix a few things here.

Hi,
I finally could apply levelwindow Filter on image successfully for SAM tool.
But that seems to opened up another can of worms 😅 (?)
The vtkMitkLevelWindowFilter gives me 2D 4 channel image. But the channels are duplicate. I verified using numpy/python. Presumably. I can just take out one channel slice and that should be it.
But I observe somethings not correct:

1. I convert vtk image to mitk image using the following syntax:

Pushed new branch to rMITK MITK: hotfix/T30163-v2023.04.2.