DICOM file detected incorrectly on versions above 6.9.7

[quasarj]

I have a simple DICOM CT image which incorrectly rendered on later versions of ImageMagick.

Using "Version: ImageMagick 6.9.7-4 Q16 x86_64 20170114" (from Ubuntu 18.04) returns:

Code: Select all

/home/quasar/test.dcm DCM 512x512 512x512+0+0 16-bit sRGB 527KB 0.000u 0:00.000

But using 6.9.10-50 and up (acquired from the official source and compiled) returns:

Code: Select all

/home/quasar/test.dcm DCM 512x512 512x512+0+0 16-bit Bilevel Gray 65536c 526926B 0.010u 0:00.007

Note that, when it is detected as "Bilevel Gray" it does not render correctly; it renders as mostly gray. I see the same behavior in the 7.x version.

Here is the correct rendering:

And here is the incorrect:


And here is the actual file: https://pathology.cancerimagingarchive. ... r/test.dcm

[fmw42]

What was your exact command line?

[quasarj]

For all versions the exact command was just

Code: Select all

convert test.dcm test.png

[fmw42]

try

Code: Select all

convert DCM:test.dcm test.png

[quasarj]

Same result.

Also, identify still shows it as Bilevel Gray:

Code: Select all

└⮚ ./ImageMagick-6.9.10-50/utilities/identify DCM:$HOME/test.dcm                                  1:50PM 
DCM:/home/quasar/test.dcm=>/home/quasar/test.dcm DCM 512x512 512x512+0+0 16-bit Bilevel Gray 65536c 526926B 0.010u 0:00.007

Code: Select all

└⮚ ./ImageMagick-7.0.8-50/utilities/magick identify DCM:$HOME/test.dcm                            1:50PM 
DCM:/home/quasar/test.dcm=>/home/quasar/test.dcm DCM 512x512 512x512+0+0 16-bit Bilevel Gray 65536c 526926B 0.010u 0:00.014

As compared to:

Code: Select all

└⮚ ./ImageMagick-6.9.7-10/utilities/identify DCM:$HOME/test.dcm                                   1:51PM 
DCM:/home/quasar/test.dcm=>/home/quasar/test.dcm DCM 512x512 512x512+0+0 16-bit sRGB 527KB 0.000u 0:00.000

[fmw42]

I can reproduce the issue - works with IM 6.9.7.4 but not 6.9.10.49

[magick]

Try this command:

Code: Select all

convert test.dcm -normalize test.png

The pixels appear to be 12-bit signed pixels but the file meta data says its 16-bits (add -verbose to your command-line to confirm). Normalization expands the 12-bits to the full 16-bit range

[fmw42]

That stretches the dynamic range, but the output does not match that of 6.9.7-4 and the top image in the OP's original post.

[magick]

Modern releases of ImageMagick exports unadulterated pixels. If it is proven that the pixels values are not the expected results, we will investigate further.

[fmw42]

I think the OP wants to be able to reproduce his first image at the top. I cannot seem to reproduce that. Is there some way?

[quasarj]

I spent a few hours today reading through the source and experimenting. I found a few things..

The 7.0 version completely ignores the Window Width and Window Center values in the file by default. You can get it to apply that transform by adding

Code: Select all

-define dcm:window

I think this is a bad idea for the default behavior; it would make more sense to have a no-window flag.

However, this still does not produce the right output. I found that there is a block of code which attempts to covert the pixel to a signed integer (or maybe fake it, I'm not really sure):

Code: Select all

         if (info->signed_data == 1)
            pixel_value-=32767;

In 6.9.7, this block is only executed if the window_width is 0. This may actually be a bug in this version, but in the case of my file(s) it causes them to render correctly in 6.9.7.

It appears that the DCM decoder assumes the Bits Stored and High Bit DICOM tags are accurate; however in our experience these tags are almost always incorrect and using them to determine the type of stored pixels will result in an incorrect rendering.

I have no idea how you should detect whether the pixels are actually signed or not..

[magick]

We compared the ImageMagick rendering of your image against what is returned by XMedCon and got similar results suggesting the current ImageMagick rendering is correct and therefore bug free.