-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BUG: fixes to improve handling of single frame SEG #89
Conversation
Note for the discussion: this should be improved further. Spacing should be calculated for consecutive frames of the individual segment. Right now, all frames are considered indiscriminately. Question is whether it should be computed at all, considering we do not have any information about whether the 2 frames are adjacent or not, so perhaps we should always rely on the declared spacing, and not even try to compute it? To be discussed with @QIICR/dcmqi |
I should have used have no choice but instead of should. At least I don't see any choice. Assumption of consecutive frames that is valid for scalar volumes does not apply to segmentations. |
I think the Slice Thickness should be a mandatory requirement for a valid It's really just not right to leave this to chance when we are talking On Fri, Sep 16, 2016 at 2:50 PM, Andrey Fedorov notifications@github.com
|
@pieper for the context, here is the code that handles parsing the "declared" spacing. Here is the code that makes the decision which spacing to use - declared or computed: https://github.com/QIICR/dcmqi/blob/master/libsrc/ImageSEGConverter.cpp#L442-L468 What I am saying is that we just cannot compute spacing from the slice positions, and thus we should remove any use of computed spacing. If SEG doesn't have SliceThickness or SpacingBetweenSlices, we should probably fail with the error that there is no sufficient information to reconstruct the volume. I don't see any way around this, but wanted to confirm with the group. |
I guess there are at least four scenarios, assuming parallel
For 1 and 2, spacing should be computed from the (always But since Spacing Between Slices is Type 3 (optional) why Spacing Between Slices is a convenience attribute, useful for Slice Thickness, if present, is irrelevant. It should never The comment in the code at: https://github.com/QIICR/dcmqi/blob/master/include/ConverterBase.h#L226 describes this ... and (appropriately) does not use thickness. For 3, a single frame, since Spacing Between Slices is Type 3 http://dclunie.blogspot.com.au/2013/10/how-thick-am-i-sad-story-of-lonely-slice.html For the single frame case, CP1426 is important to us for Pixel Note that there is no reason to treat Slice Thickness differently On 9/16/16 3:14 PM, Andrey Fedorov wrote:
I assume that you mean that you cannot compute spacing when there
I assume that you are saying this only for single frame slices, which In: https://github.com/QIICR/dcmqi/blob/master/libsrc/ImageSEGConverter.cpp#L442-L468 you call computeVolumeExtent, but I couldn't find where this was Case 4, multiple slices that are not regularly spaced, are an Obviously, there are other reasons a set of slices could have All this begs the question of what you are using the "spacing" "for" As for the standard ... The requirements for the SEG IOD were intended to allow for all http://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_A.51.5.html and the conditions within the macro when it has been included: In our case, since we are always sending Frame of Reference UID David On 9/16/16 3:14 PM, Andrey Fedorov wrote:
On 9/16/16 2:52 PM, Andrey Fedorov wrote:>
|
@dclunie the discussion is motivated my the scenarios 3 and 4 from your list. While receiving SEG, in absence of the direct correspondence between SEG frames and segmented modality frames (when they are available), we cannot decide which of the scenarios we deal with in the general case, and that is why I raised the concern that we cannot calculate slice thickness, in the general case. If you have SEG frames regularly sampled, how can you assure that, for example, it is not every other frame of the original modality that has been segmented? (in the general case, of course) To your question
In the Slicer world, everything is a volume, even if it is a single slice. We always deal with volume reconstructions. In the quantitative imaging use case, if we have a segmentation and we don't know slice spacing - how can we, for example, compute ROI volume? |
For me the overriding consideration is: a unambiguous definition of the If the parameter to dcmqi aren't enough to create an unambiguous SEG then On Sat, Sep 17, 2016 at 7:26 AM, Andrey Fedorov notifications@github.com
|
So I guess that for each scenario we need to define: (a) what the right thing to encode is (b) what Slicer will do with such a SEG object when received (c) how the user (caller) of dcmqi will assure that it is encoded This thread is mostly about (c), right (if I understand what Steve If we assume that Spacing Between Slices is always to be sent in
As for Slice Thickness, it is required, and cannot be computed Andrey raised the question of regular, but sparse sampling Note that in this variant (sparser sampling that the original), The "happy" path (>90% of use cases I suspect) is a single 3D David On 9/17/16 10:18 AM, Steve Pieper wrote:
|
Let's discuss at the next hangout when you are back David. |
Consensus was reached that in the cases where neither SliceThickness, nor SpacingBetweenSlices are available, the conversion of the SEG into a volume should fail. |
As discussed in QIICR#89, in the general case, we cannot rely on the slice thickness computed from the positions of the individual frames, since frames may not be contiguous. When source image references are available, and the source images are also available, additional checks could be possible, but not in dcmqi.
No description provided.