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 NumberSegment 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
- rework the internal structure and the need to offer conversion for old not dicom complient data
or
- 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.