Invalid loading of segmentation with cropped in-plane data

Bug Report

Describe the Bug

I am the author of pydicom-seg, a library for reading and writing DICOM-SEG in Python, and currently try to track down errors in using the generated DICOM-SEGs in OHIF/Viewer (https://github.com/razorx89/pydicom-seg/issues/20).

Currently, OHIF viewer does not correctly load DICOM-SEG data, which was cropped in-plane. The CT image has an in-plane resolution of 512x512, while the cropped segmentation has a resolution of 272x224. As you can see below, the 512x512 is shown correctly while the 272x224 is distorted. Cropping is intended to reduce the generated DICOM size, since for small segmented objects most of the frame data is only zeros.

It seems like an error in accessing the allocated segmentation buffer and thus assigning to the wrong voxels. In order to correctly assign the voxels, the PlanePositionSequence[0].ImagePositionPatient attribute in the PerFrameFunctionalGroupSequence as well as the Rows and Columns need to be used for computing the correct buffer indices.

Loading the DICOM-SEG using my package or via the conversion tool segimage2itkimage from QIICR/dcmqi, followed by resampling to the original CT image grid using SimpleITK, displays the correct segmentation in ITKSnap.

What steps can we follow to reproduce the bug?

Data credits go to: QIICR/dcmqi I prepared the ct-3slice scan, from dcmqi’s repository, with the corresponding liver.dcm segmentation as example.zip. The liver-nocrop.dcm is exported using my package without in-plane cropping, the liver-cropped.dcm is exported with cropped segmentation data.

[pieper]

Yes, 24x38x3 works

[fedorov]

There is also this odd-sized sample dataset in dcmqi that we tested against BrainLab and I believe confirmed the encoding is correct (that is the one that we used to debug encoding bug in DCMTK): https://github.com/QIICR/dcmqi/tree/master/data/segmentations/24x38x3.