michaelonken
commented
8 months ago @fedorov : We had an interesting discussion this morning which has been triggered by the work done by @spalte last night. I checked the pull request and realized he was working on the overlap detection code I recently added, and the labelmap supplement clearly forbids overlaps -- so there is no need for checking probably we don't need the overlap checking for the labelmap case.
However, Joel correctly stated that it is still possible to create overlapping labelmaps by just putting different (DICOM) frames into the same position that project multiple segments onto the same pixel in space. I.e. what might be forbidden by the standard is not inherently enforced by the data model which was counterintuitive to (at least my) brain's model of labelmaps so even the possibility did not came to my mind at all . [1]
So we asked @dclunie about his view on this and @pieper and @CPBridge joined the discussion. We were agreeing that there should be extra guidance in the supplement that such kind of overlaps must be avoided.
An interesting point has been raised by Chris in this context: If one has cine runs, i.e. frames recorded at different points in time, a segmentation might well contain frames with the same frame position at different time point points (which is not forbidden right now), it even makes sense to encode things this way. The question is whether this is allowed (as I understood, it is right now), whether it should be allowed (and then must be encoded correctly using the Segmentation's dimension setup), and so on.
Then the discussion moved on what needs to be considered when you have the same and/or different label maps spread over multiple files and how to keep track of segments. But that is another topic.
We got interrupted by a Slicer session but I think David decided to sit down and think/write a proposal how to handle all this.
@ everybody interested: please don't hesitate to add/fix if I forgot or misunderstood something.
[1] Actually, this scenario also applies to the existing binary and fractional segmentation objects (multiple frames at the same position can "overwrite" or "extend" each other's segment pixel coverage). I think our current code in dcmqi does not crash or do something stupid in those cases, but maybe we could spit out some warnings or so if we can do it "en passant".
fedorov
CPBridge
dclunie
This pull request to meant to assist in sharing the current work in progress for adding LABELMAP support.
16 bit label map support still needs to be added. The behavior with 16 bit label maps is undefined as is.