Service stopped When Changing DICOM File Compression

[enasbond]

Description: When attempting to change the compression of the attached DICOM file, the application crashes, causing the service to terminate unexpectedly. This issue has occurred every time I used the attached file and generates an error in the attached Windows Event Viewer.

To Reproduce public static DicomTransferSyntax[] GetSupported() { var nativetranscoder = new NativeTranscoderManager(); return DicomTransferSyntax.KnownEntries .Where(t => nativetranscoder.CanTranscode(t, DicomTransferSyntax.ImplicitVRLittleEndian)) .ToArray(); }

var dicomFile = DicomFile.Open(inputFile);

string fileTs = dicomFile.Dataset.InternalTransferSyntax.UID.UID;

if (fileTs == transferSyntax) { return true; }

var newFile = dicomFile.Clone(DicomTransferSyntax.Parse(transferSyntax));

newFile.Save(outputFile);

Unhandled exception. FellowOakDicom.Imaging.Codec.DicomCodecException: Unable to determine bit depth: JPEG syntax error!

Screenshots

image.zip

Environment:

• OS:
• fo-dicom nuget package version: 5.1.1.0
• fo-dicom.Codecs nuget package version: 5.10.8

[jaime-olivares]

This doesn't look like a fo-dicom.Codecs issue. The message mentioned belongs to fo-dicom (read https://github.com/fo-dicom/fo-dicom/blob/f29b59d75c0499dd94e723e48100a6b627e71c40/FO-DICOM.Core/Imaging/Codec/DicomJpegCodec.cs#L172).

Reading that portion of the source code, it seems your file may be empty or corrupted.

[cbeltran1306]

Hello @enasbond, that dicom file has a transfer syntax JPEG Lossless [1.2.840.10008.1.2.4.70] but in its PixelData is missing the first 4 bytes (0xFFD8 0xFFE0) in order to be a JPEG file. Indeed JPEG library is stopping the process to decode.

We are adding validation to avoid this problem.

[enasbond]

Hello @cbeltran1306

Thank you for the update and the detailed explanation. It's clear now.

I appreciate you adding validation to avoid this issue, and I expect you will reopen this issue again

Thanks again for addressing this!

[jaime-olivares]

Hi @enasbond, This seems to be an unexpected case (lack of leading magic bytes). We will add a check for generating an exception rather than letting it crash.