Browser Crash with Compressed DICOM Data

[OzgeYurtsever]

Hi,

I would like to report an issue where the browser crashes when attempting to handle compressed DICOM data. It appears that there is no problem when working with uncompressed data. Based on my analysis, I suspect that the cause of this issue might be a nested loop in the "readEncapsulatedPixelDataFromFragments" function.

Steps to Reproduce:

• Load a web page or application that handles DICOM data.
• Attempt to load and display compressed DICOM da
• Observe that the browser crashes. (I attach a screenshot)
• The issue persists across different browsers in Microsoft machines.

Thank you for your attention to this matter.

[yagni]

Thanks for the report @OzgeYurtsever. Any chance you could attach some DICOM that's causing the problem? That would help troubleshoot it quicker. Please make sure it doesn't contain any identifiable information.

[OzgeYurtsever]

Thanks for your response @yagni. I am working on finding a deitentified multiframe image.

[emelalkim]

Hi @yagni, after conducting further troubleshooting, we have determined that the issue seems to be related to the size of the image. When attempting to load a larger uncompressed image, the OHIF viewer crashes almost immediately. However, in the case of compressed DICOMs, it takes longer for the crash to occur.

For testing purposes, you can download the same deidentified data from the following link: sample image

By using this larger multiframe DICOM image, you should be able to replicate the crashing issue more quickly. Please note that this sample data is specifically provided to investigate and address the challenges associated with loading large multiframe DICOM images and we were able to reproduce this issue only in Windows machines.

[yagni]

@OzgeYurtsever @emelalkim I think this might be a cornerstone3D issue, not a dicomParser issue.

1. When I drop the file from @emelalkim into the DICOM dump with data dictionary example, it increases memory usage by about the size of the file. I can drop that same file multiple times and not see a memory increase. (Note that I had to comment out the console.log() and replace an innerHtml assignment with a JQuery .empty() call, but those are both specific to the example, not the core dicomParser code)
2. When I drop the file into the local cornerstone3D example in a separate tab and scroll through a couple of slices, it easily gets up to 7GB and then goes out of memory. Further, it seems like the garbage collector isn't running in time, as I can trigger the garbage collector and it drops back down to ~600MB, which is around what I would expect.

I'll leave this open for now, but I would recommend filing this report in cornerstone3D issues. If it ends up being a parsing bug, we can come back here and dig in to it some more.