Host process crashes when decoding corrupt JPEG Lossless, Non-Hierarchical-1stOrderPrediction DICOM file

[bdebaer]

Describe the bug This bug is related to #78. As far as I know, from reading the comments, the issue should be fixed for J2K files, but I'm not sure if something was also done in the other codecs? When trying to decode a corrupt JPEG Lossless, Non-Hierarchical-1stOrderPrediction DICOM file, the host process still crashes without a stack trace.

To reproduce

new DicomSetupBuilder()
        .RegisterServices(s => s.AddFellowOakDicom().AddTranscoderManager<FellowOakDicom.Imaging.NativeCodec.NativeTranscoderManager>())
        .SkipValidation()
        .Build();

var dicomFile= DicomFile.Open(corruptJpegLosslessFile);  
var dicomImage= new DicomImage(dicomFile.Dataset);  
dicomImage.RenderImage(0);

Environment:

• OS: Windows 11
• fo-dicom nuget package version: 5.1.4
• fo-dicom.Codecs nuget package version: 5.15.4

[amoerie]

More context:

The old codecs avoided this problem by checking if the first two bytes of a JPEG lossless begin with the SOI marker. This is taken from the Native\libijg12\jdmarker.c (old fo-dicom codecs)

/* Like next_marker, but used to obtain the initial SOI marker. */
/* For this marker, we do not allow preceding garbage or fill; otherwise,
 * we might well scan an entire input file before realizing it ain't JPEG.
 * If an application wants to process non-JFIF files, it must seek to the
 * SOI before calling the JPEG library.
 */
{
  int c, c2;
  INPUT_VARS(cinfo);

  INPUT_BYTE(cinfo, c, return FALSE);
  INPUT_BYTE(cinfo, c2, return FALSE);
  if (c != 0xFF || c2 != (int) M_SOI)
    ERREXIT2(cinfo, JERR_NO_SOI, c, c2);

  ...
}

I've attached an anonymized DICOM file that exhibits this problem to easily reproduce the issue.

problem.zip

@jaime-olivares @cbeltran1306 if you require more input, please shout!

P.S. @bdebaer is a colleague

[jaime-olivares]

We are looking into this

[pvrobays]

I had the same issue and created corrupted files for all the different kind of encoders that are supported. This way I know which encoders have the issue and I can check beforehand if the passed data is valid so I can avoid the hard crash of the application.

Below a summary of what my findings:

• ✅ the decoding can handle a corrupted header, it returns null result
• ❌ the decoding cannot handle a corrupted header. Often the program crashes hard (tested on windows)

Can handle corrupted header	Transfer Syntax UID	Description
✅	1.2.840.10008.1.2.5	RLE Lossless
❌	1.2.840.10008.1.2.4.50	JPEG Baseline (Process 1): Default Transfer Syntax for Lossy JPEG 8 Bit Image Compression
❌	1.2.840.10008.1.2.4.51	JPEG Extended (Process 2 & 4): Default Transfer Syntax for Lossy JPEG 12 Bit Image Compression (Process 4 only)
❌	1.2.840.10008.1.2.4.57	JPEG Lossless, Non-Hierarchical (Process 14)
❌	1.2.840.10008.1.2.4.70	JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]): Default Transfer Syntax for Lossless JPEG Image Compression
❌	1.2.840.10008.1.2.4.80	JPEG-LS Lossless Image Compression
❌	1.2.840.10008.1.2.4.81	JPEG-LS Lossy (Near-Lossless) Image Compression
✅	1.2.840.10008.1.2.4.90	JPEG 2000 Image Compression (Lossless Only)
✅	1.2.840.10008.1.2.4.91	JPEG 2000 Image Compression
✅	1.2.840.10008.1.2.4.201	High-Throughput JPEG 2000 Image Compression (Lossless Only)
✅	1.2.840.10008.1.2.4.202	High-Throughput JPEG 2000 with RPCL Options Image Compression (Lossless Only)
✅	1.2.840.10008.1.2.4.203	High-Throughput JPEG 2000 Image Compression

@jaime-olivares I hope it helps. I also have a dataset here with files with a corrupted header. If it helps, I can share them privately.

[cbeltran1306]

Hi @pvrobays, can you share me those files? -- this is my mail => [email protected]

[pvrobays]

@cbeltran1306 You've got mail!

[cbeltran1306]

Hi @pvrobays, please use the fo-dicom.Codecs latest version (https://www.nuget.org/packages/fo-dicom.Codecs/5.16.0#versions-body-tab), it includes decoding files with a corrupted header for JPEG dicom files.

[jaime-olivares]

Waiting for more feedback. Otherwise we will close this item soon.

[amoerie]

Sorry we forgot to communicate back, I can confirm that the latest version of the codecs fixes the issues! Thanks so much for the fast response!