StudyPrefetcher

[vicOnGit75]

Will StudyPrefetcher be available in v2.0?
Or there is another place to monitor downloading progress, performs some actions based on it and
define downloading strategy?
Thanks

[dannyrb]

I believe it's something we eventually intend to add, but it's not near the top of our lists. Feel free to suggest an implementation an spearhead the development with a PR 🙌

[swederik]

I don't really recall why we disabled it actually. I know we had issues with the study loading monitor thrashing redux too often (it probably shouldn't be using redux), but that is an independent component.

I know that we planned to revisit this as some point because it's a bit confusing how the prefetcher should work since extensions can register their own viewports components now.

Viewers/platform/viewer/src/connectedComponents/Viewer.js

Line 285 in 7c4ee73

{/*<StudyPrefetcher studies={this.props.studies} />*/}

https://github.com/OHIF/Viewers/blob/0064a4b1cd6b1b30e339e39bf92292ad1917fb35/platform/viewer/src/components/StudyPrefetcher.js
https://github.com/OHIF/Viewers/blob/0064a4b1cd6b1b30e339e39bf92292ad1917fb35/platform/core/src/classes/StudyPrefetcher.js

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

[dannyrb]

👞 💨 🤖
We're nearing a good place to begin scoping this.

[vicOnGit75]

Can you "point to how it was implemented in OHIF v1, and provide some guidance on how it should probably be implemented in v2.", please?

[Stormert]

Any updates on this or more guidance available on this?

I will be working with a couple other developers to make some customisation of this viewer in the near future to better suit our needs. And this is also a highly wanted feature for us so if we are able to make some time this could be a good issue to have a closer look at.

[dannyrb]

The logic for StudyPrefetcher lives at:

<repo-root>/platform/core/src/classes/StudyPrefetcher.js

We expose that functionality in a React Component at:

<repo-root>/platform/viewer/src/component/StudyPrefetcher.js

It needs to:

• Start when a viewing route is loaded
• Stop when the viewing route is destroyed

The class handles:

• Listening for when the cornerstone image cache is full
  • This allows it to stop prefetching when the LRU (least recently used) cache starts to purge
• It's constructor takes an array of studies to prefetch
• It's prefetchDisplaySets works with cornerstone-tools's requestPoolManager to orchestrate prefetching

The hang-up appears to be in getDisplaySetsToPrefetch. We need to find the study's display sets so we can prefetch them, but the code to do this is commented out.

Our app's data needs to be cleaned up, but for the time being, that info is retrieved in the <ViewerRetrieveStudyData> component. We prop drill quite a bit and pass those studies down. We also update an instance of the the studyMetadataManager that can be accessed by doing something like this:

import { utils } from '@ohif/core';

const { studyMetadataManager } = utils;
const studies = studyMetadataManager.all();

Long term, I'd like to make the study info we make reactive very thin, and keep the bulk of it's immutable information somewhere that won't trigger re-renders or unnecessary comparisons.

[salimkanoun]

Just to know @Stormert did you succeded make something on the study prefetcher ?

[Stormert]

@salimkanoun unfortunatly not, we ran in to some other issues with our image sets being too large 600-700MB when just letting them load regularly and trying to generate the MPR view causing browser lock ups and crashes so we had to put this project on ice for the time beeing. I have not been able to keep up with the updates here though some things might have changed since then.

[biskyt]

This is a feature that I am in real need of for a project that I'm currently working on for eye care. we have OCT outputs with 127 and 256 frames (ultrasound b-scans). Currently it is painfully slow to browse these stacks, as it only starts loading each frame when you scroll to it.

I'm prepared to offer a bounty if somebody is willing to do the development. Please either reply here if you're interested or email me directly toby.bisco @ toukanlabs.com and let me know how much you would charge and how long it would take.

Thanks

[salimkanoun]

@biskyt Actually RadicalImaging do some sponsored features to be integrated in OHIF.
Maybe @swederik will give you some details if they are available to do so.

[biskyt]

@salimkanoun - Thanks for the quick response. We have been speaking with RadicalImaging, but so far they have not been able to find anybody. So I thought it worth posting here too to widen the search.

We're definitely happy to pay for the time.

I should note that the product we're trying to use the viewer in is a fully open source medical record, primarily for the NHS in the UK. We just don't have any developers in-house that are skilled in React, otherwise we'd be happy to contribute directly.

To give a better idea of the issue, I've created the below video.

ohif-osimis-load-compare.mp4

This shows the OHIF viewer vs the Osimis viewer. In the OHIF viewer, the user gets locked out of making any interactions while frames are loaded. There is also no indication of which frames are/not loaded. And as the frames are not being pre-fetched, this makes for a very painful user interaction when trying to load the full stack!

In the Osimis viewer, it is clear to see the loading progress, and no interactions are blocked if you scroll to a frame that is not loaded.

Other than this, the OHIF viewer is streets ahead of any other viewer I've come across.

We also have a few other small feature requests (which again we're happy to pay for), if we can find somebody willing to do the work.

[salimkanoun]

I see,
Actually i would be probably able to do it, or supervise a student to do it but i'm also missing bandwith....

Maybe next year we hope to be able to do some contribution to OHIF, but not this year

[igoroctaviano]

#3363 created for v3