DICOM SEG PixelData issue when frame size doesn't align with byte boundaries

[jelinski]

Good morning.

First of all I'd like to thank you for your work on this 3d Slicer extension! It's great! 👏

I'd like to report a bug I encountered when importing a DICOM SEG file. The problem occurs whenever a SEG file has columns and rows whose product isn't divisible by 8 without a remainder. For me, it happens when the remainder equals 6 (it works for other remainder values), but that might be just a coincidence.

It looks like PixelData isn't created correctly. It must be a bug related to bits-packing into a byte, because everything works fine as long as a single byte doesn't contain bits from multiple frames.

I created a sample PET study with 10 slices 21x22 each, that can be used to reproduce the issue LINK. I did it to force the 3D Slicer to use these specific rows and colums values when doing a DICOM SEG file export.

Steps to reproduce:

• Import the study
• Create a segmentation that spans through all the slices and contains the 1st pixel (position 0,0) of each slice (so it's easier to identify the boundaries of the frames in hex editor)
• Export this segmentation to a DICOM SEG file
• Clear the scene, remove the DICOM study and patient, shutdown 3d slicer app (to make sure we start fresh and nothing is cached)
• Import the same study but this time include the SEG file that was just created

What's wrong:

During the DICOM SEG export, PixelData isn't created correctly. Investigating the binary content of the file reveals that the distance between 1s (the first pixel of each frame) is not equal to 462 for every frame/slice.

RED: 57 full bytes + 6 bits = 462 - OK
BLUE: 56 full bytes + 2 bits from previous + 4 bits = 454 - NOT OK

With the red color, I marked all the bits that belong to 1st frame, and with the blue color I marked the bits that represent the binary segmentation of 2nd frame. You can see that 2nd frame is missing 1 byte. This results in 3D Slicer claiming there is an extra pixel in the segmentation for the slice at position -1322mm. This happens because we're expecting 462 bits to represent a frame (but this particular frame contains 454 bits only), so we end up reading "1" bit that actually comes from the next frame. The total PixelData size is correct because all the "swallowed" bytes are appended at the end of it.

Unfortunately, looks like the same "1" is then interpreted for the second time. So it's not like the segmentation pixels are displaced, they are appearing as "phantom" pixels. I.e. there are 10 pixels total in PixelData, however, when displayed there are 14 pixels for that Segmentation in 3D slicer.

Versions:

3D slicer - 5.6.2 r32448 / f10cd8c
QuantitativeReporting - 2024-08-31 (Revision: [6259837]
Operating System - macOS Sonoma 14.6.1 (23G93)

[michaelonken]

Hi Krzysztof,

thank you for the report and the detailed analysis. I received a similar report via email from a company, so I assume the bug is real (there has been a similar issue in the past and it looks there are still some cases not covered by the related fix).

I have very limited time right now but hope i can fix this within the next two weeks. If someone comes up with a patch before I do, I welcome it of course.

Best regards,
Michael