Hello,
I have Orthanc running locally with the Osimis Viewer plugin which is only being accessed locally as well. It works nicely. I am wondering if there are any methods to speed the loading of the images in the viewer, especially since the images are stored locally anyway.
- Is there anything I can do in the API to trigger a load before the users selects a study?
- Are there any other options for pre-loading or somehow speeding up the image loading?
Also, are there any other api endpoints - the only one I know of is /osimis-viewer/app/plugin-entrypoint.html?study=[study-id]
Thanks,
Andrew
Hi,
Concerning loading optimisation, there is a deprecated parameter “CacheEnabled” in the “WebViewer” section of the orthanc config file.
It probably no longer work though, as it’s no longer supported/maintained nor tested. There is no way to trigger the study loading before opening the page.
Current entrypoints are:
-
/osimis-viewer/app/plugin-entrypoint.html?study=[study-id]
-
/osimis-viewer/app/plugin-entrypoint.html?series=[series-id] (warning: will be removed shortly!)
-
/osimis-viewer/app/plugin-entrypoint.html (mainly for debug/testing)
Another entrypoint is available in the in-dev version of the pro edition of the web viewer. It allows realtime communication with the iframe, and for instance
switching between studies without reloading the iframe.
Kind Regards,
Thibault.
Hi Thibault,
I am reading your “will be removed shortly” comment below.
Can you please confirm that this is really the case and why.
Although its a good idea to give the user the chance to see other series of a study as well, it still makes sense to call the viewer with a default series here. The default series can then immediately be shown while other series of this study are visible left side and user can open them if he likes.
btw, this approach does even make sense one level higher, i.e. starting to view one series but be able to see all series of a study left AND other studies with their series of a patient if they exist. The left side could be structured in that way.
best
Torsten
Hi Torsten,
Concerning the entrypoint, I forgot to tell you the plugin-entrypoint.html has been renamed index.html in newer versions.
We are removing the series entrypoint since it’s nearly never used and is hard to maintain:the viewer do not only display
series in its viewport, but sometime series’ instance (if it’s a PDF for instance), so we have to adapt the entrypoint for each
use cases, while it doesn’t bring concrete benefits to the actual users.
What you’re suggesting is however highly pertinent, this is unfortunately not how it works at the moment as the current
entrypoint interface are differents. The model mismatch still occurs though. What should we do if the series is a mix of
instance and pdf report for instance (the model mismatch can occurs at this level, as we cannot display both pdf & instances in the same viewport) ?
Kind Regards,
Thibault.
Hi Thibault,
it was just an idea.
For me as a user it would be helpful to start at a certain level (e.g. series or instance, if report or photo, XC modality) but still be able to see what else is available for that patient. The alternative is to go back to OrthancUI and reenter Osimis Viewer - works too but more clicks and less intuitive. Osirix does do it in a similar way btw (left side shows studies, series and instances and click opens in viewport. I attach a screenshot to give you an idea. Pattern is more or less Accordion with a thumbnail and some meta infos (modality, seriesname, date, no of instances etc.)
best
Torsten
Thanks for the quick response.
I noticed that when I use the viewer to look at certain studies, the viewer is making a request to …/low-quality and …/high-quality. And with other studies it is making a request to /pixeldata-quality. The studies that are loading with pixeldata-quality are loading practically instantly, where as the ones loading with /low-quality and /high-quality take a few or several seconds to load.
Can you explain what is happening?
My guess is that it has to do with the format of the DICOM file. I know this question is outside the domain of the webviewer, but how can I ensure my DICOM files are in the format that loads quickly? Do you know of any plugin or tools that could be used to make sure it is in this format?
Thanks,
Andrew
Hi Torsten, Andrew!
Feedback is very welcome. We in fact are looking to support different hanging protocols in a few monthes. If you´re fine with it, it’ll be great if we could come back to you later on this matter.
Concerning the image loading time: the web viewer do compress images to either jpeg or png. Some dicom files already wrap compressed images instead of pure raw images. When it’s the case and when we have adapted decompression libraries in the frontend, we can bypass the server-side decompression/recompression process. Thus, those images (actually jpeg-ls ones) are processed way faster on the back-end side. So if you precompress all your images in jpeg-ls, you will achieve the same effect without losing any quality.
I’ll stay close to this thread 
Kind regards,
Thibault.
I understand what you are saying, but I am a bit new to DICOM.
So I’d like to “precompress all your images in jpeg-ls” so that I get those super fast load times.
I see there is a dcmtk tool for this - http://support.dcmtk.org/docs/dcmcjpls.html
Can you provide any guidance or link me to some resources where I might be able to figure out how to have incoming dicom files compressed?
also, I see “StorageCompression” is a setting on Orthanc. Does this have anything to do with the jpeg-ls?
Thanks again,
Andrew
Hello Andrew,
I am sorry, I mismatched the required compression. It’s in fact jpeg-lossless (not jpeg-ls).
You can use the following tool:
http://support.dcmtk.org/docs/dcmcjpeg.html
with --encode-lossless-sv1 and --true-lossless options (those are set by default apparently).
Let me know if you have any specific question concerning the implementation. At which level do you have difficulties ? If you need some advice concerning the overall implementation let me know.