Skip to content
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

Dimensions of volume and segmentations are not matching #513

Open
stefano-trebeschi opened this issue Jan 13, 2025 · 3 comments
Open

Dimensions of volume and segmentations are not matching #513

stefano-trebeschi opened this issue Jan 13, 2025 · 3 comments

Comments

@stefano-trebeschi
Copy link

Following on the same public dataset of #512
I get non-matching dimensions between the CT volumes and the labels after running segimage2itkimage

@fedorov
Copy link
Member

fedorov commented Jan 13, 2025

This is expected, and it is a very common question.

DICOM segmentations are represented as a set of frames (slices) - not as a single 3D volume. Those individual frames include geometry information that can be used to order them and reconstruct the segmented volume. For the sake of reducing file size while encoding SEG, frames that do not contain any segmented pixels are often skipped and are not included. As a result, when you have empty image slices above and/or below (which is often the case) the segmented slices, they will not be included.

When DICOM SEG is converted by segimage2itkimage, only the slices present in SEG will appear in the output representation. If you want the segmentation geometry to match that of the segmented image, you will need to augment the segmentation image with the empty slices above/below, which is easiest done by resampling segmentation to the volume of the segmented image.

Does it make sense?

@stefano-trebeschi
Copy link
Author

stefano-trebeschi commented Jan 13, 2025 via email

@fedorov
Copy link
Member

fedorov commented Jan 13, 2025

If you do resampling to the raster of the segmented image with nearest neighbor interpolator (using ITK, as an example), the result should be identical to adding empty slices, but you will not need to worry about the code being error-prone while accounting for differences in image orientation (perhaps among other possible complexities).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants