This is a discussion on Pixel padding hackery. - DICOM ; Hi, I have a lot of DICOM data here, and some of the images are from some rather troublesome scanners, some GE, some not, that are causing some problems. The pixel padding value stored in the file is not the ...
I have a lot of DICOM data here, and some of the images are from some
rather troublesome scanners, some GE, some not, that are causing some
problems. The pixel padding value stored in the file is not the value
that is actually used as padding.
One workaround is to detect the equipment used and take some equipment-
specific action to get around bad padding values. This is not
acceptable; we're always getting data from some random place with some
random piece of equipment that we've never encountered before with an
incorrect padding value in it.
The current workaround that is implemented is to pretend all pixel
values are unsigned (while processing padding) then treat all pixel
values >= the specified padding value as padding, unless the padding
value is 0, in which case only pixel values == 0 are treated as
padding. And this works for 99.99% of all DICOM sets that I've ever
encountered, and that number is up in the thousands, from dozens of
different sources. But I don't like this at all for obvious reasons.
Firstly, in the 6 years I've been dealing with this stuff I've never
actually seen signed pixel data where values are actually negative.
Ever. Not once. (This is CT, MR, and xray image data). Secondly, up
until recently, I've never once seen an image where the padding value
was non-zero but was less than the maximum pixel value that occured in
the data (for example, I've never seen an image where the data ranged
from 0 to 2048 but the padding value was, say, 3).
And man it pains me to no end to rely on these things being true.
Sadly, for reasons beyond my control, I have to use some old, in-house
DICOM reading code rather than certain free, publicly available, open-
source, commercially licensed, standard-compliant, time-tested, fully-
functional, well-maintained, well-documented, easy-to-use DICOM
So then the question is... what's the best way to handle pixel padding
values that are just straight up wrong? Knowing which pixels are
padding pixels is important, the latest application I'm working on
involves editing DICOM images and modifications must not be applied to
padding data, and also modified DICOM images are written back out by
this software and padding information must be preserved.
I did read another great post here:
But it wasn't -quite- relevant to the problem I'm having.
I hope this question wasn't too vague. Thanks!