Efferent-Health
Intermittent silent failure when transcoding DX images from Explicit VR Little Endian to JPEGLSLossless
Environment
fo-dicom.Codecs: 5.16.4
fo-dicom: 5.22
OS: Windows 10 21H2
Runtime: .NET 8.0
VC++ Redistributable: Latest installed (v14.x)
Description When I attempt to transcode a batch of DX (X-ray) DICOM images from Explicit VR Little Endian to DicomTransferSyntax.JPEGLSLossless, about 75 % of the images transcode correctly. The remaining images appear to “fail” silently:
No exception is thrown.
No error or debug output is emitted by the codec pipeline.
A DicomPixelData-derived object is still produced, but its header is corrupted by no leading JPEG bytes.
The resulting DICOM file is roughly 1 MB in size (regardless of original size), even after I increased the internal buffer limit to 32 MB.
Strangely, if I retry transcoding a failed image multiple times, it may eventually succeed.
Steps to Reproduce
Ensure C++ Redistributable v14 is installed.
Load a DX image in Explicit VR Little Endian:
csharp Kopieren Bearbeiten var file = DicomFile.Open("example_LE.dcm"); var df = file.Dataset; Attempt lossless JPEG-LS transcoding:
csharp Kopieren Bearbeiten var cloned = DicomCodecExtensions.Clone(df, DicomTransferSyntax.JPEGLSLossless); cloned.Save("output_JPEGLSLossless.dcm"); Inspect the output. Some files open correctly in a DICOM viewer; others contain no JPEG-header fragment in the PixelData and cannot be displayed.
Expected Behavior All DX images should transcode losslessly to JPEG-LS without inconsistencies or hidden errors.
Actual Behavior
Approximately one quarter of images produce invalid PixelData (JPEG bytes embedded in header).
No exceptions or log messages are available to indicate failure or partial write.
Manual retries sometimes “fix” the problem, suggesting a race or buffer reuse issue.
Attempts & Workarounds
Increased internal codec buffer to 32 MB → no effect.
Verified latest native codecs are present via fo-dicom.Codecs package.
Confirmed thread-safety by running transcoding serially (no parallel loops).
Questions / Requests
Is there a way to enable internal logging for the codecs pipeline (e.g. verbose/debug output) to diagnose where the write truncation or corruption occurs?
Could this be related to buffer reuse, unmanaged memory fragmentation, or missing codec finalization on certain image dimensions?
Any other ideas on troubleshooting intermittent failures in the JPEG-LS transcoder?
Feel free to let me know if you need sample DICOM files or a minimal repro solution. Thank you!
Hi @nutzlastfan can you provide the DICOM files you got the intermittent failures?
We are near to close this issue unless we receive concrete information. This library has hundreds of users and we haven't received a similar report of such a high error rate (25%?) Be sure you are not trying to encode in parallel within the same process. That may corrupt the data.
