We should also have a look on eMITK plugins. Maybe not for that release, but for the next.
E.g. would the MRI tools make sense?
SUV would also be a candidate... may RT (but there we have to double check the state...

So now we have to clarify the name for the bigger edition. And if we want to have just one extended edition or if we will in the end have it focused on topics. As we only have currently fitting stuf added.

I think in doubt I would just move but not merge it for now. If we see that it is needed or wanted we can make the effort and merge it. It would be better than not offering this feature at all.

The dicom inspector has one additional dependency to module MITKDICOM. Therefore if we merge the inspector plugins also our normal inspector could only be build if DICOM module is activated. (Which it currently is per default).

Integrate into F1 help. Make MITK ModelFit Webpage deprecated for manual section with link to doxygen documentation.

It is a useful feature and should be part of the next release.
Open to dos:

• Checklist
• check dependencies of the view. If the view does not have more dependencies then our property inspector should be merged.

In T30157#253717, @fedorov wrote:

offer the feature to take an instance UID that is an int as the pixel value.

Not sure if I understand it correctly, but ... DICOM UID cannot have int as the value - this would violate VR constraints.

offer the feature to take an instance UID that is an int as the pixel value.

T29204 should be done before as we need to store the information in an appropriate way. The most important thing is that we have then a property to store the instance UID. The default UID is the pixelvalue if not overwritten by the user or another configuration. Regarding the persistance of the pixel value I see two option:
a) Leave with the fact (and document it) that DICOM Seg is not "loss less" regarding the pixel value. So after saving to and loading from DICOM Seg your label will have the same (class) name and instance UID but might have a different pixel value.
b) offer the feature to take an instance UID that is an int as the pixel value. But this is only possible if we assure in our UI that you cannot use/change into an instance UID in a Segmentation that is alrready used there by another label.
Currently I would lean to a) and generate a new ticket for b) and see if we need it in the future.

• Boolean Operations
  • chosen: high effort
  • Can be used so that the other functions can do everything
  • Work only on one image, select two labels
• Contour to Image & Surface to Image
  • chosen: low effort seems more senseful. The functionality can be achieved via other tools (e.g. boolean)
• Image Masking
  • chosen: low effort
• Morphological Operations
  • as proposed
  • Pick an image & pick a label
  • Include options like in picking tool, i.e. generate a new layer when doing an operation, lock labels (to make sure other labels are not overwritten e.g. for a dilution)
• Add a new tool: Transfer Label could be used to transfer a label from one image to another (if the same image is selected twice, it's just a rename)

I had a look as well: two voxels is really an edge case, given the current method it would only give a correct result for number of bins == 1 . But setting the number of bins to at most (number of voxels - 1 ) doesn't really help, it fails e.g. for three voxels. In general thinking a bit about it I came to the conclusion that limiting the number of bins (currently it's _minimum_ 10) would still not yield a correct median.

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

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.

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

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

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

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

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.

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:

I think the handling of multiple labels depends on each action and needs to be handled separately.

• Boolean Operations: I see a few options here
  • low effort: only allow for segmentations with one label. If there is more than one label, show a message that this is not possible
  • higher effort: completely rework the selection. Let the user select two specific labels (from the same or different segmentations) and work on these, either replacing the first label or adding a new label (or instance) to that segmentation
• Contour to Image & Surface to Image:
  • low effort: leave it as is, still works at the moment
  • higher effort: introduce the option to add the newly created segmentation as a new label / instance to an existing segmentation
• Image Masking:
  • low effort: leave it as is, still works at the moment (using all labels of a segmentation)
  • higher effort: introduce the option to select which labels/instances should be considered for masking
• Morphological Operations: Currently don't crash, but always use label 1
  • I think the most senseful solution would be to let the user select a specific label for the operation to work on. Multiple at the same time probably only get in each other's way and make it unnecessarily complicated.

nnUNet(v1) won't be removed until nnUnet v2 is introduced.

Sounds good Ralf - happy to help!

@fedorov Thank you for your quick reply and verification for my assumption (I hoped, that I might have overlooked some broader interpretablility...)

" increase monotonically by 1" could be interpreted as "no holes allowed". We should clarify if this is the case.

from @neher : clscreenshot sounds like something that might be useful, but i never used it

So far only CLGlobalImageFeatures is claimed to be needed.

Fabian has reported than nnUNet(v2) python codebase can run to Windows.

Valid. Will be /is regarded in the refactoring.

Code test and patched for 2D image support.

I am not sure what happens when 2D 3 channel is loaded for segmentation. Never tested the behaviour of the SegWithPreviewTool API. From my side, I need to update the wrapper to accommodate for 3 channel images. Of course, it's a straightforward change but at the moment, 3-channel won't work.

In T29650#248947, @gaoh wrote:

@k656s has an example dataset. I am still at the release version before (I think 2022.10?) but I will update to the current release. Could this already help?

Yes, it could. I thought something like this was already introduced. @kislinsk, or?

what is the problem here/where do you lose the other channels? shouldn't it work out of the box already?

@k656s has an example dataset. I am still at the release version before (I think 2022.10?) but I will update to the current release. Could this already help?
If not, I would vote for the task list view reinit after loading opiton.

@gaoh do you have example data to reproduce this situation. That would help to replicate it and search for the best solution.
Which version of MITK was it?