Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug] Large series will not render as volumes and will crash (Array Buffer Allocation Failed) #4150

Closed
IbrahimCSAE opened this issue May 17, 2024 · 7 comments
Labels
Awaiting Reproduction Can we reproduce the reported bug?

Comments

@IbrahimCSAE
Copy link
Collaborator

Describe the Bug

If a series is a large enough the array buffer allocation fails and we can't do MPR on it.

Chrome:

image

Safari can do better but still the render seems odd, I also have to override the cs3d cache first to increase it:

image

Steps to Reproduce

  1. https://viewer-dev.ohif.org/local
  2. Load study attached
  3. Go into basic viewer
  4. Try to MPR
  5. Check console

The current behavior

The viewer crashes

The expected behavior

Render MPR correctly

OS

MacOS

Node version

18

Browser

Chrome

@IbrahimCSAE IbrahimCSAE added the Awaiting Reproduction Can we reproduce the reported bug? label May 17, 2024
@IbrahimCSAE
Copy link
Collaborator Author

@wayfarer3130 @sedghi

I can share the data on slack if needed

@wayfarer3130
Copy link
Contributor

@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.

@salimkanoun
Copy link
Contributor

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

@sedghi
Copy link
Member

sedghi commented May 21, 2024

Bill added a nice PR to fix the issue until 4GB for now cornerstonejs/cornerstone3D#1260

@salimkanoun
Copy link
Contributor

That's cool ! (but i think it will have a day when we will have > 4gb images ^^⁾

@sedghi
Copy link
Member

sedghi commented May 21, 2024

see you then :D

@wayfarer3130
Copy link
Contributor

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting Reproduction Can we reproduce the reported bug?
Projects
None yet
Development

No branches or pull requests

4 participants