search

OHIF / Viewers

OHIF zero-footprint DICOM viewer and oncology specific Lesion Tracker, plus shared extension packages
https://docs.ohif.org/
MIT License
3.35k stars 3.37k forks source link

Change approach for loading study metadata from WADO to QIDO+WADO #836

Closed swederik closed 5 years ago

swederik commented 5 years ago

This ticket addresses a metadata-loading performance issue that has come up a few times lately. @salimkanoun reported it over email with a set of PET/CT studies and @fredericcervenansky have also run into it (https://github.com/OHIF/Viewers/issues/824) when deploying against their hospital PACS.

The problem is that when we load a study right now we first make a WADO-RS call to retrieve all of the metadata for every instance related to that StudyInstanceUID. When a study has a large number of instances, this initial call can become very slow. Large studies e.g. PET/CT and DICOM Whole-slide Image studies suffer from performance issues because of this issue.

The proposed change is to switch from a single initial WADO-RS RetrieveMetadata call at the Study level to a set of calls: First, a QIDO-RS SearchForSeries call at the Study Level, and then a set of WADO-RS RetrieveMetadata calls at the Series level.

Steps:

  1. User loads a study into the Viewer
  2. Viewer makes QIDO-RS SearchForSeries request given the StudyInstanceUID to retrieve the list of series. If this fails, the viewer displays an error that the study was not found.
  3. Viewer starts making WADO-RS RetrieveMetaData requests at the Series level for each of the series listed in the study.
  4. As each series is retrieved, createDisplaySets should be run on the series (https://github.com/OHIF/Viewers/blob/8f758186c1a096a80b92596c4c796f927d1d9a8b/platform/core/src/classes/metadata/StudyMetadata.js#L115-L190). The display sets should be concatenated to the current set of display sets in the study.
  5. Whenever a new display set is added to the list of display sets for the study, the list should be sorted by series number to ensure the proper ordering in the study.

These calls can be tested on our public DICOMWeb server: https://server.dcmjs.org/dcm4chee-arc/aets/DCM4CHEE/rs/

QIDO-RS SearchForSeries: Docs: https://dicomcloud.azurewebsites.net/swagger/#!/QidoRS/QidoRS_SearchForSeries GET ${qidoRoot}/studies/{StudyInstanceUID}/series

WADO-RS RetrieveMetadata at the Series Level: Docs: https://dicomcloud.azurewebsites.net/swagger/#!/WadoRS/WadoRS_GetSeries GET ${wadoRsRoot}/studies/{StudyInstanceUID}/series/{SeriesInstanceUID}

Notes:

TZubiri commented 5 years ago

Big support for this feature.

Our CT files (512width, 512height, 16bits per pixel) consist of approximately 2.7% metadata. Most of which are repeated tags. If in fact OHIF is currently blocking the download of the first image untill all metadata can be downloaded, this fix would reduce the time to first image of a 1000 slice CT scan on a 3mb/s connection from 64 seconds down to a floor of one sixth of a second, effectively shifting the bottleneck to latency rather than broadband.

I have one question swederik. Since most of the metadata in a CT scan is duplicated anyways, have you considered a fix that would remove the need to download duplicate data? It wouldn't be very impactful, but it would feel like justice.

pieper commented 5 years ago

Thanks for the statistics @TZubiri. Yes, I think this change will directly impact your use case.

In terms of reducing redundant metadata, one way forward is to look at storing legacy converted multiframe datasets, which have the potential for much more efficient access.

swederik commented 5 years ago

This has now been added by @emfol in #922!

@fredericcervenansky, @MathisGuilhin, @salimkanoun could you test out the latest version with some of your larger studies (i.e. with a lot of instances spread across series)?

If you are still having issues, leave a comment and I'll reopen the issue.