Incorrect decoding of RLE-compressed DICOM (TransferSyntaxUID 1.2.840.10008.1.2.5) - output image becomes noise

[Anastasia-Kiseleva12]

Magick.NET version

Magick.NET-Q16-AnyCPU 14.10.3

Environment (Operating system, version and so on)

Windows 10 x64 .NET Framework 4.8 Running inside a WPF desktop application

Description

I am migrating from an older ImageMagick CLI-based implementation to Magick.NET.

During testing i discovered that some DICOM files that were previously decoded correctly by the old ImageMagick CLI now produce corrupted output when read using Magick.NET.

The issue appears specifically with RLE-compressed DICOM files.

The resulting PNG image appears as random grayscale noise even though the image dimensions and metadata are correct.

The problem reproduces even with a minimal Read(stream) -> Write(Png) pipeline, so it does not appear to be caused by any post-processing in my code.

Steps to Reproduce

1. Open the attached RLE-compressed DICOM file.
2. Run the following code:

using System;
using System.IO;
using ImageMagick;
using MagickNetFormat = ImageMagick.MagickFormat;

public static class Repro
{
    public static Stream Convert(Stream inStream, bool onlyFirstPage = true)
    {
        if (inStream is null)
            throw new ArgumentNullException(nameof(inStream));

        if (inStream.CanSeek)
            inStream.Seek(0, SeekOrigin.Begin);

        var read = new MagickReadSettings
        {
            Format = MagickNetFormat.Dcm
        };

        if (onlyFirstPage)
        {
            read.FrameIndex = 0;
            read.FrameCount = 1;
        }

        using (var image = new MagickImage(inStream, read))
        {
            var outStream = new MemoryStream();
            image.Write(outStream, MagickNetFormat.Png);
            outStream.Seek(0, SeekOrigin.Begin);
            return outStream;
        }
    }
}

Save the returned stream as a PNG file and open it.

Result:
The PNG output contains random noise / corrupted pixel data.

Expected result:
The PNG should contain the correct grayscale radiographic image.

Additional notes:

The same source file is decoded correctly by the older ImageMagick CLI-based implementation that I used previously.

The issue appears only for DICOM files with TransferSyntaxUID = 1.2.840.10008.1.2.5 (RLE Lossless).

Uncompressed DICOM (1.2.840.10008.1.2.1) and JPEG-compressed DICOM (1.2.840.10008.1.2.4.70) work correctly.

Example metadata of problematic files:

TransferSyntaxUID = 1.2.840.10008.1.2.5
Compression = RLE
Depth = 16
ColorSpace = Gray
PhotometricInterpretation = MONOCHROME2
Manufacturer = LEAD Technologies

Images

images.zip

[Anastasia-Kiseleva12]

I also reproduced the same corrupted output with magick.exe from ImageMagick-7.1.2-16-Q16-x64-static, so this does not appear to be specific to the Magick.NET wrapper or our .NET code.

However, I could not find any similar reports about this behavior. Is this a known issue with RLE-compressed DICOM files?

[dlemstra]

In 2016 we made a change in ImageMagick to correct the byte order for RLE compressed DICOM images. You are now the first person in 10 years to report an issue with this. When I swap the byte order in your image it is read correctly. We could introduce an option for this but that would mean you would still need to figure out yourself which byte order to us.

[Anastasia-Kiseleva12]

Thank you for the explanation!

That makes sense and matches what I observed during testing. Since these files appear to be using a non-standard byte order, I will handle them separately for now. Thanks again for the clarification.

[Anastasia-Kiseleva12]

One quick follow-up question: do you expect that such an option for handling this byte order might be introduced in future Magick.NET releases?

This would help me decide whether I should implement a permanent workaround or wait for a possible option in the library.

[dlemstra]

The option would result in a class here that is similar to the PdfReadDefines and would allow you to specify that the bytes should be swapped when reading the image. There is no way to "detect" this so it will be up to you to determine if you need to make the swap with this setting.

If this still sounds like an option you would be interested in then please let me know.

[Anastasia-Kiseleva12]

Yes, this would be very useful for me. I do encounter such DICOM files in real scenarios, and having an option to explicitly enable byte swapping on read would help avoid implementing a custom workaround.

[dlemstra]

In the next version you can use FixByteOrder of the DcmReadDefines to swap the bytes.