Stack viewport memory problem

[zhoualibaba]

https://user-images.githubusercontent.com/17982206/225917534-935e69d3-0fa4-47e2-a01a-8e458a926998.mp4

@sedghi I have tried two ways to solve this bug. 1, Change the Google Chrome to the Chromium; 2, Seperate the multiple frames in one dcm file into a set of dcm files for each frame. The first way can solve the bug for most series, but if the frames count is too large (ie. 600+) the website will still crash. The second way can solve all the problems but I have to waste a lot of time to seperate the file.

[zhoualibaba]

Sorry about the last issue. I used to think it was the same problem

[sedghi]

so does the problem happen when you use something else? like Scroll through wheel? or our stackScroll tool?

[zhoualibaba]

This problem also happens when I use the stackScroll tool.

[sedghi]

Is your data annonymized and whether you can share it?

[zhoualibaba]

We created a dicom for testing. You can try it in“https://www.cornerstonejs.org/live-examples/local.html" 185_test.zip

[sedghi]

Is this expected? What is the desired rendering? and what is the problem?

[zhoualibaba]

https://user-images.githubusercontent.com/17982206/226778949-869cfdbc-c107-4069-ba50-983c81a13c35.mp4

Thanks for your quick response, and what you displayed is correct. This is an artificial 3D dicom file with multiple frames (One dicom file with dimension of 512 512 185). when you use the CINE or stackScroll tool using google chrome browser in windows, the memory leak issue would occur, as the above video shows. Have you used CINE or stackScroll tool to vusualize the file and checked your computer memory at the same time?

For your information, the memory leak issue disappeared when we use multiple 2D dicom files (185 2D dicom files, each dicom with dimension of 512 512) instead of one 3D dicom (512 512 * 185). As we mentioned before, there are temporary 2 ways that we tried to solve the issue, (1) Use the Chromium instead of the common google chrome; (2) Seperate one dicom files into a set of 2D dcm files.

[sedghi]

Before further investigation, what do you mean by if you use Chromium, Do you mean Google Chrome Canary (the yellow logo?)

[zhoualibaba]

The Chromium is the open source browser with the same core with Google Chrome, the color of Chromium logo is blue.

[sedghi]

So if that is fixed there, I expect chrome to fix the problem in the next release

[zhoualibaba]

The Chromium can solve the bug for most series, but if the frames count is too large (ie. 600+) the website will still crash. I do not think that the Chromium solved this problem totally.

[zhoualibaba]

I tried to seperate the multiple frames in one dcm file into a set of dcm files for each frame. This action do solve this problem, so I think the data loading of the volume dicom with multiple frames should be modified to be as the same as that of the the seperated dicoms in your architecture.

[tblock79]

We experience the identical problem. Different browsers crash at different times (Firefox tends to crash a bit later), but they all do eventually. So, I don't think that a fix has been added to Chromium. I assume that there is some kind of memory leak related to the multi-frame loader (we use DICOM multi-frame images to reduce the transfer overhead).

[tblock79]

This PR actually solves the problem, at least for us (so it seems to originate from the WADO loader): https://github.com/cornerstonejs/cornerstoneWADOImageLoader/pull/454 Would be great if this could be merged into the main branch.