View in #ohif on Slack
@Johnmark_Enriquez: Hi everyone,
I’m currently experimenting with the StudyPrefetcher feature in OHIF and I have a few questions about how prefetching works.
When I preload/prefetch the second study/series, the images in the first study/series become glitchy when I use stack scroll. Specifically, there’s a noticeable lag of around 1 to 2 seconds when scrolling up and down. Correct me if I’m wrong, but I think this happens because the second study/series is still being requested over the network.
Has anyone else experienced this issue or have any insights on how to resolve it? Any inputs would be greatly appreciated.
Note: These are medium to large scans, by the way.
Thanks!
@Bill_Wallace: Would you have the opportunity to encode them using HTJ2K progressive encoding? Even just using the recent OHIF builds from this week may improve your prefetching interaction.
There are three fetch categories, thumbnail, prefetch and interactive.
The study prefetcher naturally uses the prefetch category, and that one has to be kept small enough to not consume too much bandwidth.
It previously was quite big, which results in using lots of bandwidth, but making it hard to get other requests in.
Laggy scrolling happens when a request takes longer than about 250 ms to get the next image for the scroll.
To improve that, reducing the prefetch size to allow an immediate interactive fetch to be started helps. Then, using HTJ2K for large images helps because the image can be rendered as a partial. Try looking at:
https://www.cornerstonejs.org/live-examples/htj2kstackbasic
Or the same studies that example loads within OHIF on viewer-dev.ohif.org?datasources=ohif3
@Johnmark_Enriquez: Thank you so much @Bill_Wallace…
Can I ask a few last questions?
- How can I identify if the images use HTJ2K?
- How can I implement and use HTJ2K on images?
- How to reduce the prefetch size?
Note: Our studies/scans are primarily in MPR layout and CBCT scans.
@Bill_Wallace: HTJ2K is quite new, so unless you have a very new server, you won’t be using HTJ2K. The transfer syntax that they are fetched in (which is in the frames/1 URL header) is 1.2.840.10008.1.2.4.202
The HTJ2K on images would have to be added by your PACS provider - Static DICOMweb will generate the appropriate encoding, and dcm4che includes the HTJ2K encoder in recent versions.
@Johnmark_Enriquez: Correct me if i’m wrong… this one right?
@Bill_Wallace: Yes, thats the transfer syntax used, so that is the old (internal) transfer syntax
@Johnmark_Enriquez: And also our set-up is Orthanc + OHIF
@Bill_Wallace: I have no idea if Orthanc has added the HTJ2K transfer syntax or not.
The settings for cache control are in cornerstone extension init.tsx:
// These are set reasonably low to allow for interleaved retrieves and slower
// connections.
imageLoadPoolManager.maxNumRequests = {
interaction: appConfig?.maxNumRequests?.interaction || 10,
thumbnail: appConfig?.maxNumRequests?.thumbnail || 5,
prefetch: appConfig?.maxNumRequests?.prefetch || 5,
};
@Johnmark_Enriquez: Thank you so much @Bill_Wallace
@Bill_Wallace: Orthanc needs these turned a long way down
@Johnmark_Enriquez: I have verified that we are currently using Content-Type: image/jp2 with transfer-syntax=1.2.840.10008.1.2.4.90 for both single-frame and multi-frame images. I will try to encode these in HTJ2K progressive mode. Sounds like a plan.
By the way @Bill_Wallace, Our studies/scans are primarily in volume, MPR layout and CBCT scans…
Hi @Bill_Wallace, Does the stable version(3.8.3) supports HT2JK?
@Bill_Wallace: Yes, but doesn’t have the progressive rendering. That is, it displays images in HTJ2K, but it works the same as JLS or any of hte other compression types