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).

In T30186#253599, @kislinsk wrote:

Is there some additional functionality involved or could we just add it as another MIME type for images instead of a dedicated plugin?

Yes there is. As only (potentially) the pixel values of image parts with an mask should be exported. And you can select multiple image (as long as they have the same geometry), there pixel values will be exported into the same table.

@full Is this still an issue (with the current release)?

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.

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.

After we have moved to Qt6, we then have QtCharts to our disposal and migrate to that.

After we have moved to Qt6, we then have QtCharts to our disposal and migrate to that.

After we have moved to Qt6, we then have QtCharts to our disposal and migrate to that.

Should be done after(!) we have moved to Qt6 as we then have QtCharts to our disposal and migrate to that.

After we have moved to Qt6, we then have QtCharts to our disposal and migrate to that.

Should be done after(!) we have moved to Qt6 as we then have QtCharts to our disposal and migrate to that.

Should be done after(!) we have moved to Qt6 as we then have QtCharts to our disposal and migrate to that.

Should be done after(!) we have moved to Qt6 as we then have QtCharts to our disposal and migrate to that.

@kislinsk Where does the crash originate from?

@gaoh Maybe you got it wrong. Saving DICOM seg is broken like always. The there is no version before v2023.04.02 that could store multi lable segmentations correctly and 4D will always crash. If you find a earlier version that does not crash on your data, then it is highliy likely to a change in DCMTK over time.

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

@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

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

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.

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

👍
I would propose to also standardizeand align some of the properties for the frames to be either in sync with MITK terminology or with DICOM.

@kislinsk thank you for the explanations. They do make sense.

Thank you for the first draft. I had the following first thoughts:

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

So far only CLGlobalImageFeatures is claimed to be needed.

Valid. Will be /is regarded in the refactoring.

There is now a dedicated mini app for matching.