MPR of 3000 slice images allocation error

[mrTonyH]

I am new to OHIF viewer. We create multiple series and one being a full body scan which can create up to 3000 slices. The full body series loads ok, but when i select 2D MPR if causes an error with DataArray Length. I was wondering whether there is a maximum series size or whether there was away to increase and allow for series containing up to 3000 slices to be loaded into 2D MPR function.

I am relatively new to JavaScript as well, so any help or advice would be much appreciated

[dannyrb]

@mrTonyH, are you able to provide more information about your series, or an anonymized version of similar data? What browser and browser version are you using? How much memory (RAM) does your computer have?

Are you able to include an exact copy of the error? Perhaps a screenshot as well?

We've been able to consistently load large series on our end, but you may be butting up against a limitation we haven't yet hit in our own testing.

[mrTonyH]

Thank you for getting back to me......
I am running the dev environment on my laptop with 8GB RAM. please see my screen shots attached, I can run through the series for the full body but the error happens as soon as i click 2D MPR function.

![2DMPR](https://user-images.githubusercontent.com/35929902/74343855-a2873780-4da3-11ea-8345-364a936d541

[mrTonyH]

[dannyrb]

Hmm... I wonder what size it's trying to allocate. You're using 64-bit chrome and have a good bit of memory, so I would be surprised if it's a system limitation. This may be difficult to troubleshoot without a reproduction I can touch/test.

FWIW, the 2D viewing of slices has a LRU cache that begins to purge after it grows past 1GB. MPR requires WebGL and loads the entire volume into memory.

You're not seeing an "out of memory" exception 🤔

There is some potentially related information here:

• https://stackoverflow.com/questions/17823225/do-arraybuffers-have-a-maximum-length
• Remove 1GB max size limit for Buffer nodejs/node#1719
• Common error: Array buffer allocation failed webtorrent/webtorrent-desktop#873

I know our MPR logic is not as efficient as it could be, there may be some optimizations we can make that would resolve this issue. The StackOverflow note about indexed arrays and max int size is also interesting.

[mrTonyH]

Thanks for replying, i've downloaded latest firefox browser and installed this on to a server with 32GB memeory, these are the errors generated in firefox.

[mrTonyH]

Hi dannyrb,

Can you tell me which library handles the 2D MPR function? i thinking its the vtk library? I have used the function with a smaller series size of 395 and that works without any issues. the series causing the issues is 2470 slices in size. I am just trying to understand whether its a browser limitation or whether it just requires a code change somewhere. If you could point me in the direction of the 2D MPR and confirm i am correct that its from vtk that would be a great help.

BW

Tony

[dannyrb]

@mrTonyH, the 2D MPR is handled by the "vtk" extension, which can be found here:

• https://github.com/OHIF/Viewers/tree/master/extensions/vtk

It's important to note that it consumes our react-vtkjs-viewport, which can be found here:

• https://github.com/OHIF/react-vtkjs-viewport

Which ultimately uses vtk.js:

• https://github.com/Kitware/vtk-js

What's interesting is that these errors don't appear to be WebGL errors. Which is the first thing I would expect to break due to memory limitations.

The limitation is likely a little of both. I'm sure there are things we can do to optimize our implementation to buy you more memory to play with, but I wouldn't be surprised if the browser or specific browser vendors, or WebGL in general limit what we have access to for the entire system (and make it difficult to find that limit).

It's hard for us, as a very small team, to focus on optimizations like this as they can take a good amount of time to hunt down and address. If this is make or break for your usage, we would either need you to conduct the bulk of the legwork and help identify a fix (for us to take and run with), or I would likely direct you to one of the consultancies that frequently contribute.

Some more interesting reading:

• https://stackoverflow.com/questions/32662357/how-much-webgl-memory-is-available-what-happens-when-i-run-out
• https://groups.google.com/forum/#!topic/webgl-dev-list/TrPjvxVk5rc

[mrTonyH]

Thank you dannyrb,

I appreciate your time getting back to me and also appreciate the size of resource you have for working on this project. thank you for providing the information above i will take a look.

If i happen to have some form of success I will get back to you.

BW
TonyH

[JamesAPetts]

What's interesting is that these errors don't appear to be WebGL errors. Which is the first thing I would expect to break due to memory limitations.

I believe these are browser level allocation errors. The standard just says "If the requested number of bytes could not be allocated an exception is raised."

[mrTonyH]

Hi James, I appreciate your input! Does this suggest it is a limitation of the web browsers themselves? The reason for the query is that in the field of work I operate within a Radiologist is required to review full body series stack of dicom. My intention is to utilize the web browser to allow flexible access to review the images. If i can get the OHIF viewer to accept this large series it will be an extremely useful tool.

Even with the provided documentation it is difficult for me to see how it all works and fits together. so any help or input is always appreciated.

[JamesAPetts]

Hey, yeah it seems like Firefox has a max ArrayBuffer length of Math.pow(2,32) - 1, which with Float64Array (required for webgl) means 4095 slices of 512x512 CT is the most you could allocate in one go. What are the dimensions of your images? This might also depend on other factors like total amount of memory already allocated, however.

You might be able to get more leverage by splitting it into smaller arrays and filling the GPU memory sequentially. But I'm not sure what the limits of the WebGlL memory is, it may be similar. As Danny says this would take a considersable amount of time to hunt down and investigate.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.