Viewers
Viewers copied to clipboard
OHIF
[Bug] Large series will not render as volumes and will crash (Array Buffer Allocation Failed)
Describe the Bug
If a series is a large enough the array buffer allocation fails and we can't do MPR on it.
Chrome:
Safari can do better but still the render seems odd, I also have to override the cs3d cache first to increase it:
Steps to Reproduce
- https://viewer-dev.ohif.org/local
- Load study attached
- Go into basic viewer
- Try to MPR
- Check console
The current behavior
The viewer crashes
The expected behavior
Render MPR correctly
OS
MacOS
Node version
18
Browser
Chrome
@IbrahimCSAE - yes, if you shared the data I would look into this issue. Do I have time against flexview for it? I'm also doing some other work that is related.
Hi all, is there a defined strategy on this ? I think the real way to solve this is to do partial loading of image, like pathology. Probably estimate a max number of slices that can be loaded and then load / unload the slices depending on the camera location.
In my opinion it will be always a series that will not load in memory, either because browser limitation, hardware limitation, or series anyway too large with thousands of instances
Bill added a nice PR to fix the issue until 4GB for now https://github.com/cornerstonejs/cornerstone3D/pull/1260
That's cool ! (but i think it will have a day when we will have > 4gb images ^^⁾
@salimkanoun - I agree, we will have > 4GB images - we can double the new size on most machines now, by switching to 16 bit textures (instead of float 32). That seems to have largely been fixed on the GPU. Getting to larger than 4 gb will require either WebAssembly64, or webgpu implementation, which is in the works inside VTK, but has a LOT of testing and fixes to get things stable. I'm also looking at splitting volumes out per image, which splits the webgl versus browser memory, and that might resolve things too, but I'm not sure when we will have time for that one.