Page MenuHomePhabricator
Create Task
Maniphest T30157

[DCM][SEG] potential in compliance to DICOM segmentation: clarify correct use of pixel value/segment number
Open, Unbreak Now!Public
Actions

Description

status: currently, MITK allows us to choose an arbitrary pixel value for new labels. The only thing that is checked is that there is no collision. But you can end up with the situation where you have a "hole" in the sequence of pixel values; e.g. 1, 2, 4, 5 ( here pixel value three is not used.)

MITK encodes the pixel value in the DICOM tag "segment number".

the DICOM standards defines the following forsegment number:

Section C.8.20.2.4
C.8.20.2.4 Segment Number

Segment Number (0062,0004) shall be unique within each Instance, start at a value of 1, and increase monotonically by 1.

" increase monotonically by 1" could be interpreted as "no holes allowed". We should clarify if this is the case. (@fedorov do you have more insights?)
if this is the case, MITK what currently be able to produce invalid DICOMS. :(

That would lead e.g. to either

  1. rework the internal structure and the need to offer conversion for old not dicom complient data

or

  1. implement it in a way that the segmentation are checked after loading or before writing if they are DICOM conformal and to offer user to convert it.

Related Objects
Search...

Event Timeline

floca triaged this task as High priority.Jul 11 2023, 9:06 AM
floca created this task.
floca added a comment.Jul 11 2023, 10:53 AM
This comment was removed by floca.
fedorov added a comment.Jul 11 2023, 5:37 PM

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

I can't think of any other way to interpret it as that first segment must have SegmentID = 1, and any subsequent segment should have SegmentID increased by 1.

Did a quick test. at least dcmqui does not complaine when loading or saving data where an sgement number is not used. So MITK can store and load data in DICOM without a loss. If it is standard conform is another question...

Does MITK use dcmqi for reading/writing SEG? That was the case in the past, at least. If this is still the case, it should be compliant. Yes, you can pass input segmentations that have labels numbered in any way, but the resulting SEG should always have consecutively numbered, starting from 1, increasing by 1 SegmentIDs. Note that when you convert SEG to a research format, pixel value labels will be assigned the values of SegmentID. I.e., if the labels while creating SEG are not following SegmentID conventions, round-trip conversion is not expected to match the source label IDs used when writing SEG.

floca raised the priority of this task from High to Unbreak Now!.Jul 11 2023, 7:51 PM

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

Also removed my last comment. I rechecked because I made an error in my first test. It now shows our DICOM Seg writing/loading is currently broken. 😬
The worest, it even seems broken with "normal"/conformal situation. So basically you cannot store DICOM currently correctly in most cases. We have to react asap

fedorov added a comment.Jul 11 2023, 8:18 PM

Sounds good Ralf - happy to help!

floca closed subtask T30161: [DCM][SEG] First label data gets lost if multilables are stored as DCM Seg as Resolved.Sep 7 2023, 12:18 PM
floca added a subtask: T29204: [SEG] Rework properties of Label class + add instance information.Sep 7 2023, 12:29 PM
floca added a comment.Sep 7 2023, 12:37 PM

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.

fedorov added a comment.Sep 7 2023, 5:19 PM

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.

floca added a comment.Sep 7 2023, 5:40 PM
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.

You are right and I know. My comment might be a bit brief. I meant, if the string content can be converted (e.g. by std::stoi), then one could assume to use it as pixel value (if it is unique within the DCM Seg instance).

kislinsk edited projects, added MITK (v2024.06); removed MITK (v2023.12).Dec 5 2023, 10:38 AM
MITK · MIC · IMSY · DKFZ