Retrieval of pixel data of Segmentation storage

[walibi33]

Hi,
Basically I'm working on a DICOM import feature for Segmenation storage, in a commercial application for scientific data visualization and analysis, and I'm ecountering an issue to have this feature work consistently.

My problem is:

when I retrieve the pixel data (7FE0,0010) from a DICOM segmentation storage file (binary segmented image to make my case as simple as possible), if the dimensions of this image is a multiple of 8 (4*4*2 for instance), then the bits of the pixel data I retrieved are exactly corresponding to each pixel of the segmented image.
Therefore I can easily rebuild the segmented image and transferred it into an image data structure of our own.
So this is the nominal case here, that works fine for me. Here are what the image and pixel data look like:

- First slice of the data set: https://www.noelshack.com/2018-30-1-153 ... tframe.jpg
- Its corresponding pixel data: https://www.noelshack.com/2018-30-1-153 ... eldata.jpg

Pixel data value is FF 0C so if we map this value onto a 4*4 bitfield with the little Endian encoding we then get:

1 1 1 1
1 1 1 1
0 0 1 1
0 0 0 0

Which corresponds to arrangement of the pixels of my segmented image just above (blue pixels are segment, black are void).

- Second slice of the data set: https://www.noelshack.com/2018-30-1-153 ... dframe.jpg
- Its corresponding pixel data: https://www.noelshack.com/2018-30-1-153 ... eldata.jpg

Pixel data value is FF 00 so if we map this value onto a 4*4 bitfield with the little Endian encoding we then get:

1 1 1 1
1 1 1 1
0 0 0 0
0 0 0 0

Which corresponds to arrangement of the pixels of my segmented image just above.

So far so good, but now, if I take a very similar data set except that its dimensions are 5*5*2 (not a multiple of 8 then), here is what I get then:

- First slice of the new data set: https://www.noelshack.com/2018-30-1-153 ... tframe.jpg
- Its corresponding pixel data: https://www.noelshack.com/2018-30-1-153 ... eldata.jpg

Pixel data value is FF 73 00 so if we map this value onto a 5*5 bitfield with the little Endian encoding we then get:

1 1 1 1 1
1 1 1 1 1
0 0 1 1 1
0 0 0 0 0
0 0 0 0 ?

First, you’ll notice that with only 3 words one bit is missing (25 pixels => only 24 bits to describe them).
Nevertheless, if we set 0 to the missing bit, then the bitfield corresponds to arrangement of the pixels of my segmented image just above.

- Second slice of the new data set: https://www.noelshack.com/2018-30-1-153 ... dframe.jpg
- Its corresponding pixel data: https://www.noelshack.com/2018-30-1-153 ... eldata.jpg

Pixel data value is 7F 81 80 so if we map this value onto a 5*5 bitfield with the little Endian encoding we then get:

1 1 1 1 1
1 1 0 1 0
0 0 0 0 0
1 0 0 0 0
0 0 0 1 ?

And here the bitfield does not correspond at all to arrangement of the pixels of the segmented image above…

A last fact is that in the previous case (segmented image of dimensions 4*4*2) all values of the pixel data were used to describe the segment over the 2 frames, whereas in this case here only 3 words are used to describe the segment over the 2 frames (1 bit is missing for each frame).
That is also why there is a “leftover” at the end of the pixel data (you can also compare with where the previous frame stops): https://www.noelshack.com/2018-30-1-153 ... ftover.jpg
The pixel data size is 8 words, both frames sizes are 3 words (previous screenshots) so that is why it remains (8–3*2) 2 words at the end of the pixel data structure…

I first noticed this issue (apparent different encoding for frames > frame 1) with bigger segmented image where the first frame was usually correct but all the following frames were incorrect.
My impression is that in this case, that I believe is when segmented image dimensions are not a multiple of 8, the first frame is encoded normally (1 bit -> 1 pixel) but all the other frames are encoded differently (RLE ?).
I’m really stuck right now because I can’t figure out how a way to interpret consistently the pixel data of a DICOM segmentation storage in order to retrieve / rebuild it correctly in the application I’m working on.

And I've already checked all the relevant information regarding the pixel encoding:
- Transfer Syntax: little endian.
- Samples per Pixel: 1.
- Photometric interpretation: MONOCHROME2.
- Bits allocated: 1.
- Bits stored: 1.
- High bit: 0.
- Pixel Representation: 0.

These values are the same for both data sets used here.

First data set can be found here (whose dimensions are a mulitple of 8 ): https://fei.netexplorer.pro/dl/si3Yami8R2
Second data set can be found here: https://fei.netexplorer.pro/dl/BXo1x3JLzB

I hope I managed to make myself clear enough.
Any guidance here will really be greatly appreciated !

Thanks,
Kevin.

[Michael Onken]

Hi Kevin,

I think this should have been fixed by this commit. See also my email to you. I'll update this thread once we figured out whether this solves your problem or we find something else.

Best,
Michael

[walibi33]

Hi Michael,

Thanks for your answer.
Altough your fix seems totaly related to my issue here, it nevertheless turns out the problem was coming from my side.

I used the method DcmDataset::findAndGetUint8Array() to access the frame pixels bits array, whereas the recommended way to access pixels array from a frame is rather to use the method DcmSegUtils::unpackBinaryFrame(), that does in addition the bits unpacking and therefore takes care of the issue I was stuck with.

I find it weird though, knowing the purpose of your fix, that I don't get to see any incorrect result with DICOM segmentation object whose single frame size is not a multiple of 8...
I'm working with a DCMTK 3.6.3 version.

[Michael Onken]

Hi,

good to hear that the issue is resolved for you

The reason is the packing of segmentation information inside the Pixel Data element. For binary segmentations (that we talk about), every bit reflects a "pixel" of the segmentation. If one frame of the segmentation is done (i.e. the last Segmentation "pixel" of a frame is stored to a Pixel Data bit), then the next frame follows and its first but is written to the next free bit in Pixel Data.

If the frames do match the byte boundary, that is a no brainer, you just start the next frame at the next free byte boundary.

However, if a frame ends up in the middle of Pixel Data byte, you have continue in the next free bit of the Pixel data byte. This means you have to perform intensive shifting of bits when packing the segmentation "pixel" into the Pixel Data element. The code before the bug partly shifted into the wrong direction, i.e. segmentation "pixels" ended up at the wrong bit position, which was based on a misunderstanding how the bits for images with 1 bit "color depths" are aligned in the Pixel Data element.

Best,
Michael