Legacy ImageMagick Discussions Archive

First up, thank you very much for an absolutely fantastic product.

We've been using ImageMagick successfully to convert dental X-Ray DICOM images into PNG for easier manipulation. So far so good.

However, we have some 16-bit grayscale RLE compressed DICOM images (written by LEADTOOLS software) (e.g. this one), that fail to convert correctly. What's more, certain 3rd party DICOM solutions also stumble over these images. The cause: endianness. LEADTOOLS writes LSB, while these other solutions assume MSB.

Our issue with the ImageMagick conversion is two fold:

the resulting image is very dark
the converted image contains 4 smaller versions of the source image

We found and fixed what appears to be a bug in dcm.c, left shifting by 8 instead of 4. This fixed our first problem:

Code: Select all

static unsigned short ReadDCMLSBShort(DCMStreamInfo *stream_info,Image *image)
{
  unsigned short
    value;

  if (image->compression != RLECompression)
    return(ReadBlobLSBShort(image));
  value=ReadDCMByte(stream_info,image) | (unsigned short)
     (ReadDCMByte(stream_info,image) << 8);
  return(value);
}

static unsigned short ReadDCMMSBShort(DCMStreamInfo *stream_info,Image *image)
{
  unsigned short
    value;

  if (image->compression != RLECompression)
    return(ReadBlobMSBShort(image));
  value=(ReadDCMByte(stream_info,image) << 8) | (unsigned short)
    ReadDCMByte(stream_info,image);
  return(value);
}

However, the second problem still remains. Can you please tell me if it is a bug, and/or could we be using a setting to get around this?

Here follows snapshots of the sample image in its various forms.

The DICOM image actually looks like this:

Certain 3rd party solutions (e.g. Sante, and MicroDicom viewers) render this image thus:

Here is how ImageMagick converts it (pre-bug fix):

After the bug fix, the DICOM image is converted to this:

I have never used DICOM images, but have you tried using -endian in your command line. see http://www.imagemagick.org/script/comma ... php#endian

I gave it a shot with -endian lsb and msb, but both produced a black result.

However,

convert 39896666772PBWR.DIC -auto-level 39896666772PBWR_al.jpg

produces an image similar to your last example.

You can also use -contrast-stretch to clip some percent on either side of the histogram to increase contrast.

Thanks for the patch. We'll get it into the next release of ImageMagick.

In regards to ImageMagick misinterpreting the image layout, we'll need to see proof of that. Post a URL to 2-3 Dicom converters or viewers that interpret the DICOM image differently than ImageMagick and we'll investigate further.

I'm pretty sure your DICOM file is bad. It has the least-significant bytes in the first RLE segment, and the most-significant bytes in the second. That's backward. The most-significant bytes always go in the first segment, regardless of the endianness of the file. In other words, the "Sante, and MicroDicom" display is correct.

Thanks for the quick response. Glad to help out with patches (if and when we find them).

Our "problem" is that, in spite of the fact that LEADTOOLS writes "bad" files, we need to be able to read them as though they were correct. The patch we submitted goes part of the way towards correcting the problem.

However, the bigger problem (apart from endianness) that we see with the converted image, is that there are 4 smaller copies.

Most free DICOM viewers, like these:
Sante DICOM Viewer
MicroDicom Viewer
(and too many others to list here)
render the image like this:

These two viewers (and LEADTOOLS) display the image correctly:
(X)MedCon
Paxeramed viewer
i.e. they show the image thus:

I can guess what IM is doing wrong. Say there are N pixels in the image. It's interpreting the uncompressed data as N 16-bit integers. The correct interpretation is N 8-bit integers (the MSBs) and then N more 8-bit integers (the LSBs). I don't know what it would take to change it.

As for the endian problem, I'd be surprised if IM doesn't have some sort of image processing operation that will, in effect, swap the bytes.

ImageMagick appears to be behaving correctly. The verbose output identifies the image as 808x632. Perhaps the other DICOM applications performs post-processing on the image. Here is the detailed image attributes:

0x0084 1 UL-UL (0x0002,0x0000) Meta Element Group Length: 176
0x0090 2 OB-OB (0x0002,0x0001) File Meta Information Version: 256
0x009E 26 UI-UI (0x0002,0x0002) Media Storage SOP Class UID: 1.2.840.10008.5.1.4.1.1.7.
0x00C0 38 UI-UI (0x0002,0x0003) Media Storage SOP Instance UID: 1.2.840.114257.1.24032009.160009.1.1.1
0x00EE 20 UI-UI (0x0002,0x0010) Transfer Syntax UID: transfer_syntax=1.2.840.10008.1.2.5
1.2.840.10008.1.2.5.
0x010A 16 UI-UI (0x0002,0x0012) Implementation Class UID: 1.2.840.114257.1
0x0122 4 SH-SH (0x0002,0x0013) Implementation Version Name: v13
0x012E 10 AE-AE (0x0002,0x0016) Source Application Entity Title: LEADTOOLS
0x0140 1 UL-UL (0x0008,0x0000) Identifying Group Length: 198
0x014C 26 UI-UI (0x0008,0x0016) SOP Class UID: 1.2.840.10008.5.1.4.1.1.7.
0x016E 38 UI-UI (0x0008,0x0018) SOP Instance UID: 1.2.840.114257.1.24032009.160009.1.1.1
0x019C 8 DA-DA (0x0008,0x0020) Study Date: 20090324
0x01AC 10 TM-TM (0x0008,0x0030) Study Time: 160009.78
0x01BE 2 SH-SH (0x0008,0x0050) Accession Number: 1
0x01C8 2 CS-CS (0x0008,0x0060) Modality: OT
0x01D2 2 CS-CS (0x0008,0x0064) Conversion Type: DV
0x01DC 24 LO-LO (0x0008,0x0070) Manufacturer: LEAD Technologies, Inc.
0x01FC 14 PN-PN (0x0008,0x0090) Referring Physician's Name: Reffering^Doe
0x0212 1 UL-UL (0x0010,0x0000) Patient Group Length: 62
0x021E 8 PN-PN (0x0010,0x0010) Patient's Name: John^Doe
0x022E 12 LO-LO (0x0010,0x0020) Patient's ID: 123-45-6789
0x0242 8 DA-DA (0x0010,0x0030) Patient's Birth Date: 19970112
0x0252 2 CS-CS (0x0010,0x0040) Patient's Sex: M
0x025C 1 UL-UL (0x0020,0x0000) Relationship Group Length: 116
0x0268 34 UI-UI (0x0020,0x000d) Study Instance UID: 1.2.840.114257.1.24032009.160009.1
0x0292 36 UI-UI (0x0020,0x000e) Series Instance UID: 1.2.840.114257.1.24032009.160009.1.1
0x02BE 2 SH-SH (0x0020,0x0010) Study ID: 1
0x02C8 2 IS-IS (0x0020,0x0011) Series Number: 1
0x02D2 2 IS-IS (0x0020,0x0013) Instance (formerly Image) Number: 1
0x02DC 1 UL-UL (0x0028,0x0000) Image Presentation Group Length: 196
0x02E8 1 US-US (0x0028,0x0002) Samples per Pixel: 1
0x02F2 12 CS-CS (0x0028,0x0004) Photometric Interpretation: MONOCHROME2
0x0306 2 IS-IS (0x0028,0x0008) Number of Frames: 1
0x0310 1 US-US (0x0028,0x0010) Rows: 808
0x031A 1 US-US (0x0028,0x0011) Columns: 632
0x0324 1 US-US (0x0028,0x0100) Bits Allocated: 16
0x032E 1 US-US (0x0028,0x0101) Bits Stored: 16
0x0338 1 US-US (0x0028,0x0102) High Bit: 15
0x0342 1 US-US (0x0028,0x0103) Pixel Representation: 0
0x034C 1 US-US (0x0028,0x0106) Smallest Image Pixel Value: 0
0x0356 1 US-US (0x0028,0x0107) Largest Image Pixel Value: 65535
0x0360 6 DS-DS (0x0028,0x1050) Window Center: 32767.
0x036E 6 DS-DS (0x0028,0x1051) Window Width: 65535.
0x037C 2 DS-DS (0x0028,0x1052) Rescale Intercept: 0.
0x0386 2 DS-DS (0x0028,0x1053) Rescale Slope: 1.
0x0390 12 LO-LO (0x0028,0x1054) Rescale Type: UNSPECIFIED
0x03A4 1 LO-LO (0x0028,0x1055) Window Center & Width Explanation: 0
0x03AC 1 UL-UL (0x7fe0,0x0000) Pixel Data Group Length: 1053622
0x03B8 0 OB-OB (0x7fe0,0x0010) Pixel Data:

I have no opinion about how far the ImageMagick team should go toward support for uncommon DICOM formats like this. But I respectfully disagree that IM is behaving correctly.

Transfer Syntax UID "1.2.840.10008.1.2.5" means the image uses RLE compression. Referring to the documentation at http://medical.nema.org/dicom/2006/06_05pu.pdf

G.1:
RLE Compression consists of the following steps:
...
3. Each Byte Segment is RLE compressed to produce a RLE Segment
4. The RLE Header is appended in front of the concatenated RLE Segments

So: one or more "segments" are created, RLE-compressed, concatenated, and stored in the file. Let's see where the segments come from.

G.2:
The first Segment is generated by stripping off the most significant byte of each Padded Composite Pixel Code and ordering these bytes sequentially. The second Segment is generated by repeating this process on the stripped Padded Composite Pixel Code continuing until the last Pixel Segment is generated by ordering the least significant byte of each Padded Component Pixel Code sequentially.

(Note that when is says "stripping off", it confusingly means to use the stripped-off bytes for something. It doesn't mean to discard them.)

The evidence is clear that IM does not understand that all the MSBs are stored before the first LSB.

The meta data claims the image is 808x632 and that is what ImageMagick returns. ImageMagick recognizes the pixels are RLE compressed. If not, the final image would be entirely gibberish. Its possible there is a bug in ImageMagick but we don't see it. We encourage you to review coders/dcm.c and identify the source of the bug and even better, post a patch here.

While I do not dispute the image being 808x632, I don't see how IM is processing it correctly. Clearly IM is duplicating the image, twice with bytes swapped (top row) and twice with bytes in correct order (bottom row), into parts that are 1/4 size of the original. That is, each new part is 404x316. Then these 4 small parts are tiled together into the larger 808x632 sized image. Please help me understand what I am seeing, and how this can be correct when almost two dozen independent applications only display a single 808x632 image?

It seems there may have been some ambiguity in the DICOM and/or RLE specifications when it comes to multi-byte color depths, with some software writing/reading LSB and some opting for MSB. I am happy to work around this "problem" in my own code.

However, my biggest concern, and the main reason for this topic, is the 4-way duplication of the image. Which section in dcm.c is causing this to happen when converting 16-bit grayscale RLE files? Especially considering that converting other 16-bit grayscale DICOM files (non-RLE) works correctly.

We understand the problem now. For maximum compression, multibyte RLE is separated by high and lower order bytes. We'll add a patch to fix the problem hopefully within a week or two.

Thank you very much :D

Try ImageMagick 6.6.8-10, the latest release. It supports multi-segment RLE-compressed images.

6.6.8-10 did indeed fix the problem. Great work, guys.

Legacy ImageMagick Discussions Archive

DICOM RLE bug causes 4 images in one

DICOM RLE bug causes 4 images in one

Re: DICOM RLE bug causes 4 images in one

Re: DICOM RLE bug causes 4 images in one

Re: DICOM RLE bug causes 4 images in one

Re: DICOM RLE bug causes 4 images in one

Re: DICOM RLE bug causes 4 images in one

Re: DICOM RLE bug causes 4 images in one

Re: DICOM RLE bug causes 4 images in one

Re: DICOM RLE bug causes 4 images in one

Re: DICOM RLE bug causes 4 images in one

Re: DICOM RLE bug causes 4 images in one

Re: DICOM RLE bug causes 4 images in one

Re: DICOM RLE bug causes 4 images in one

Re: DICOM RLE bug causes 4 images in one