Viewers: 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.

ohif-cropped-seg-bug

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.

About this issue

Original URL
State: closed
Created 4 years ago
Comments: 24 (17 by maintainers)

Most upvoted comments

Yes, 24x38x3 works

pieper on May 31, 2020

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.

fedorov on May 31, 2020

Interesting - a bit off-topic for this issue, but I tried to replicate this using OHIF against google’s dicomweb and I get the message below about it being an invalid instance. I guess google doesn’t support a value of 1 for BitsAllocated. But this is not correct according to the standard. FYI @fedorov I guess I’ll report this as a bug to the google folks.

https://healthcare.googleapis.com/v1beta1/projects/idc-sandbox-000/locations/us-central1/datasets/sdp-dev/dicomStores/cropped-seg/dicomWeb/studies/1.2.392.200103.20080913.113635.0.2009.6.22.21.43.10.22941.1/series/1.2.826.0.1.3680043.8.498.71167181430473953726005125072372749258/instances/1.2.826.0.1.3680043.8.498.88983434253411987964922722856183426978

generic::invalid_argument: error while transcoding from 1.2.840.10008.1.2.2 to application/dicom; transfer-syntax=1.2.840.10008.1.2.1: invalid Pixeldata macro attributes: Rows/Columns/SamplesPerPixel must be set and BitsAllocated must be a multiple of 8, cause (internal only): generic::invalid_argument: invalid Pixeldata macro attributes: Rows/Columns/SamplesPerPixel must be set and BitsAllocated must be a multiple of 8
com.google.apps.framework.request.StatusException: <eye3 title='INVALID_ARGUMENT'/> generic::INVALID_ARGUMENT: invalid Pixeldata macro attributes: Rows/Columns/SamplesPerPixel must be set and BitsAllocated must be a multiple of 8

pieper on May 31, 2020