Padding byte in multi-frame images

[andreasb]

Hi,

I've got some data from a certain PACS where in an uncompressed multi-frame each frame has a padding byte added (the frames have an odd number of rows and columns and 8 bit allocated). DcmPixelData::getUncompressedFrame() does not handle this case. I have added small patch, but I'm not sure if this is the correct way to fix it:

--- dcpixel.cc (revision 2688)
+++ dcpixel.cc (working copy)
@@ -1091,7 +1091,15 @@
// we already have an uncompressed version of the pixel data
// either in memory or in file. We can directly access this using
// DcmElement::getPartialValue.
- result = getPartialValue(buffer, frameNo * frameSize, frameSize, cache);
+
+ // consider a padding byte for each frame
+ // we use DcmPolymorphOBOW::getLength() because we know that we are uncompressed here
+ Uint32 frameLength = DcmPolymorphOBOW::getLength() / numberOfFrames;
+ if (frameLength != frameSize && ((frameLength != frameSize + 1) || !(frameSize & 1)))
+ {
+ return EC_InvalidTag;
+ }
+ result = getPartialValue(buffer, frameNo * frameLength, frameSize, cache);
if (result.good()) result = dataset->findAndGetOFString(DCM_PhotometricInterpretation, decompressedColorModel);
}
else

[J. Riesmeier]

I guess this issue is already fixed in the current DCMTK release 3.6.0. See this commit.

[andreasb]

Thanks - I will check this. From the diff, I can't see that the issue is fixed, as only the buffer size is changed here, not the offset into the pixel tag, but according to the comment, it should work...

[J. Riesmeier]

Read PS 3.5-2011 Section 8.1.1:

In a multi-frame object that is transmitted in Native Format, the individual frames are not padded. The
individual frames shall be concatenated and padding bits (if necessary) apply to the complete Value
Field.

[andreasb]

Thanks - this is indeed the correct behavior, but in older versions of the standard this was not so clear (I have been told, I did not lookup this).
Anyway, we will patch this locally to satisfy the customizers who use a PACS with the incorrect behavior. Eventually the PACS software will be updated to conform to the standard...

[andreasb]

Ok, the reference I mentioned was indeed from the DICOM standard, as an additional note to the section you mentioned (this is from the 2009 standard):

In a multi-frame object that is transmitted in Native Format, the individual frames are not padded. The individual frames shall be concatenated and padding bits (if necessary) apply to the complete Value Field.
Note: Receiving applications should be aware that some older applications may send Pixel Data with excess padding, which was not explicitly prohibited in earlier versions of the Standard. Applications should be prepared to accept such Pixel Data elements, but may delete the excess padding. In no case should a sending application place private data in the padding data.

So it seems that reading software shall support this kind of padding.

[J. Riesmeier]

As far as I understand it, the term "excess padding" refers to the end of the pixel data stream. How should the "receiving application" know that there is an "intra-frame padding"?

Here's another paragraph from the referenced section:

Also, the Value Field containing Pixel Data, like all other Value Fields in DICOM, shall be an even number
of bytes in length. This means that the Value Field may need to be padded with data that is not part of the
image and shall not be considered significant. If needed, the padding bits shall be appended to the end of
the Value Field, and shall be used only to extend the data to the next even byte increment of length.

So, in previous editions of the DICOM standard there could be more than a single padding byte at the end of the pixel data stream. This is now explicitly forbidden (but should be handled by the receiving application for reasons of robustness - or whatever you would call that.

[andreasb]

Ok, thanks. You are right - detecting an intra-frame padding is possible only by calculating the frame length from the value length and the number of frames, and it is generally not possible to differentiate it from "excess padding" at the end of the value. Ah, the joy of interpreting the DICOM standard...