Approach for image caching using IndexedDB or other web API's

[focusaway]

First of all, we would like to express our sincere thanks for the incredible work you have done with Cornerstone.

Now, we have encountered a problem with the way the image cache is stored in RAM, we see that, as in the Legacy version, this information is stored in Map type variables. This approach can cause significant memory consumption and we think a better solution would be to use an API like IndexDB (for example) to store the image information on disk, which makes it possible to share the cache between windows, like a native viewer.

We understand that this issue may have come up before, but we were wondering if you had any plans to implement something like this or even make it possible to choose the storage type from the implementation in the future. We think it would be a valuable addition to Cornerstone and could greatly benefit its users.

[sedghi]

Hey @focusaway Thanks for reaching out. The short answer is yes, we believe we will add some sort of disk cache. The tricky part is storing the PHI on the disk, since there is no guarantee that it gets removed after. So image pixelData (maybe not for all, not for US), can be stored. Or maybe we need some sort of encryption involved.

CC @Ouwen since he might have some comments on this.

[focusaway]

Thanks for answer so soon @sedghi! We are seeing with our team if perhaps it would be worthwhile for this cache to also be something external as is currently done with the loader (wado). So each implementation can define if it prefers a cache in RAM, or on disk. Something very similar to how it works for example https://www.npmjs.com/package/redux-persist. We are doing some testing to include this cache in a loader, but if required we can help implement something directly into this version of cornerstone.

[Ouwen]

@focusaway, here is an implementation on CSWIL which uses cacheAPI to store the imaging data. https://github.com/gradienthealth/cornerstoneWADOImageLoader/tree/gradienthealth/add_cacheAPI

Using IndexedDB to store is also possible, but there is performance consideration as loading the images can be slow.

If there is a way to proxy all calls through browser cacheAPI that would be fantastic, but as @sedghi mentioned there is a challenge of lingering PHI.

Feel free to give the branch a try in case it meets your needs.

[articu]

@sedghi Hello, I am a beginner of cornerstone3D library. I am confused by what cache exactly mean in the context of cornerstone3D library.

https://www.cornerstonejs.org/docs/concepts/cornerstone-core/cache/#utilities-for-the-cache

The doc said The cache has two main components: a volatile portion for images and a non-volatile portion for volumes.

Does "volatile" mean RAM and "non-volatile" mean disk ? Does cornerstone3D use any kind of disk cache ? Or cornerstone3D only use RAM cache ? I hope the doc can clarify that. Thank you very much.

[sedghi]

Absolutely not. Our cache consists entirely of RAM. Let's consider rephrasing that statement. Essentially, this means that volatile images will be replaced by newer ones if necessary, whereas non-volatile volumes will remain in the cache unless manually removed to prevent any unexpected behaviors.