dcmqi (DICOM for Quantitative Imaging) is a free, open source C++ library for conversion between imaging research formats and the standard DICOM representation for image analysis results
How to communicate the situation when segmentation algorithm did not produce anything for a given image?
@rfloca is interested in this topic. We should meet to discuss the issue of encoding semantics of background and the use cases Ralf has @dclunie - this will also be relevant to the labelmap work.
We had similar request from @vanossj, and below are the notes from the exchange with @dclunie.
Andrey: @dclunie what would be the recommended way to communicate this? I do not think it should be a blank SEG!
David C: Why not, if that's what the application produces? Also, itkimage2segimage should not crash under such circumstances.
Andrey: I didn't think we would want to do this, since it will be a very large object. If this is what we recommend should be done, then you will need to replace all zeros in the image with some other label, and then communicate the semantics of that label in the JSON file. There is a code for "background" (see https://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_7165.html), but I do not know if that matches the semantics you would like to communicate. Regarding “should not crash” - indeed, that is a bug, and I now created an issue for that: https://github.com/QIICR/dcmqi/issues/471. But I am not sure when I will get to it, given the time and other issues in dcmqi that are higher priority. I do not want to force users to always define semantics of 0. We need to have a way to communicate that some slices do not contain anything of value (otherwise, how would we decide which slices to skip during conversion?). Right now, 0 in the input image effectively communicates that those slices do not have anything. If background needs to be encoded, it will have to be non-zero label.
David C: As I understand it, common usage is that input label maps have 0 for background, and that “background” == “nothing there” (in DICOM, “That which is not part of an object”; as I see it, the input label map is what it is and you should encode it as such - this is different from there being no output at all (a label map was not produced at all, for one reason or another, which could be signaled implicitly not present in the set of objects) or explicitly (e.g., an SR describing presence or absence of a segmentation) - users should absolutely define the semantics of 0, otherwise it is undefined and nobody knows WTF they meant; this should not be confused with not including an empty bitplane when the corresponding value in the labemap does not occur (i.e., zero for a bitplane that is either zero or one (only), and corresponds to a discrete input labelmap value (which could include zero), should not be confused with 0 in the labelmap; IMHO, it is fine to omit bitplanes that are all zero, it is not fine to omit slices that are all 1 for a bitplane that corresponds to a label map of 0, unless the user specifically requests that behavior (“omit bitplanes for background”), which makes sense under some circumstances; also, 0 in a label map need not always background).
Andrey: “ IMHO, it is fine to omit bitplanes that are all zero” - I do not understand what this means. In research formats, you don’t send the list of frames, you have a 3d volume. How do you suggest in that 3d volume user communicates the difference between 0 = “I do not care about this, skip it, ignore it” and 0 = “I intentionally labeled this as 0 background and I want to encode it as such”? How would one decide which slices to skip? But independently, as any implementation, dcmqi is also opinionated, and in most use cases I have seen, users do not care about explicitly encoding background. If they do want to encode the background, it should not be a big lift to assign it a unique non-0 label. I refuse to complicate life for the majority of users by forcing them to describe and encode background in order to satisfy the narrow use case, which can already be supported by a workaround. Also, remember that we set a precedent on this issue: none of the SEGs we ever produced or shared explicitly encoded the background. AND dcmqi already has a flag —skip, semantics of which is to skip empty frames, empty frames defined as those containing 0 only in the input labelmap. That’s how it’s always been implemented. Encoding of DICOM results is defined by the standard. Interpretation of the input is up to the library.
Related but different from #471
How to communicate the situation when segmentation algorithm did not produce anything for a given image?
@rfloca is interested in this topic. We should meet to discuss the issue of encoding semantics of background and the use cases Ralf has @dclunie - this will also be relevant to the labelmap work.
We had similar request from @vanossj, and below are the notes from the exchange with @dclunie.