Stay organized with collections
Save and categorize content based on your preferences.
This page shows best practices for improving performance when working with
DICOM data in the Cloud Healthcare API.
Maximizing frames per second (FPS) in an imaging viewer
The healthcare-imaging-performance-test
tool provides benchmarks that let you preview what FPS you can expect
for a DICOM medical imaging viewer that pulls data from the Cloud Healthcare API.
Sending requests concurrently
For the best FPS performance, send requests concurrently.
For example, under the following conditions you can improve FPS from 30 FPS to
60 FPS when going from six concurrent requests to 20:
Using no compression
When the DICOM data is all in the same region
When the DICOM images are 0.5 MB in size
Retrieving frames in a single request
The retrieveStudy
and retrieveSeries
methods efficiently return multiple DICOM files in a single request.
Using these methods, you can retrieve images at the same rate as using an
optimal number of concurrent requests. You can call these methods in a single
request instead of using concurrent requests if the following are true:
The client can store the entire study in memory, or the client
can parse the response as a stream to handle one DICOM instance at a time
You don't need to customize the order of the retrieved images
Improving performance for web viewers
The following sections apply to retrieving DICOM images when using a web viewer.
Increasing maximum concurrent requests
When using a web-based viewer, most browsers enforce a maximum number of
connections per host. This number is typically six. However, in practice
there is no restriction on the maximum number of concurrent requests
because:
Most browsers use HTTP/2 by default if the server supports HTTP/2
HTTP/2 uses a single connection for all requests
For example, if you use Cornerstone.js
to build a viewer, you can modify the maximum number of concurrent requests
to a number that is optimal for your viewer by changing maxSimultaneousRequests
when configuring Cornerstone.js.
Using web workers
JavaScript is a single-threaded language, so extra care must be taken when
applying concurrency patterns. You can use web workers
to process both DICOM images and HTTP requests.
For example, if you modify your HTTP request processing to web workers, you
can effectively double your viewer's FPS from 30 FPS to 60 FPS assuming a
30 millisecond request processing overhead.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[[["\u003cp\u003eThis page details best practices for optimizing performance when working with DICOM data in the Cloud Healthcare API, focusing on improving frames per second (FPS) in medical imaging viewers.\u003c/p\u003e\n"],["\u003cp\u003eSending requests concurrently can significantly improve FPS, with an example showing an increase from 30 FPS to 60 FPS when increasing concurrent requests from six to 20 under specific conditions.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003eretrieveStudy\u003c/code\u003e and \u003ccode\u003eretrieveSeries\u003c/code\u003e methods allow for the efficient retrieval of multiple DICOM files in a single request, matching the performance of optimal concurrent requests under certain conditions.\u003c/p\u003e\n"],["\u003cp\u003eFor web viewers, the default limit on concurrent connections in browsers can be bypassed with HTTP/2, and tools like Cornerstone.js allow customization of maximum concurrent requests for optimized performance.\u003c/p\u003e\n"],["\u003cp\u003eUtilizing web workers can enhance concurrency in JavaScript environments, potentially doubling a viewer's FPS by processing DICOM images and HTTP requests in separate threads.\u003c/p\u003e\n"]]],[],null,["# DICOM best practices\n\nThis page shows best practices for improving performance when working with\nDICOM data in the Cloud Healthcare API.\n\nMaximizing frames per second (FPS) in an imaging viewer\n-------------------------------------------------------\n\nThe [healthcare-imaging-performance-test](https://github.com/GoogleCloudPlatform/healthcare-imaging-performance-test)\ntool provides benchmarks that let you preview what FPS you can expect\nfor a DICOM medical imaging viewer that pulls data from the Cloud Healthcare API.\n\n### Sending requests concurrently\n\nFor the best FPS performance, [send requests concurrently](#sending_requests_concurrently).\nFor example, under the following conditions you can improve FPS from 30 FPS to\n60 FPS when going from six concurrent requests to 20:\n\n- Using no compression\n- When the DICOM data is all in the same region\n- When the DICOM images are 0.5 MB in size\n\n### Retrieving frames in a single request\n\nThe [`retrieveStudy`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.dicomStores.studies/retrieveStudy)\nand [`retrieveSeries`](/healthcare-api/docs/reference/rest/v1/projects.locations.datasets.dicomStores.studies.series/retrieveSeries)\nmethods efficiently return multiple DICOM files in a single request.\nUsing these methods, you can retrieve images at the same rate as using an\noptimal number of concurrent requests. You can call these methods in a single\nrequest instead of using concurrent requests if the following are true:\n\n- The client can store the entire study in memory, or the client can parse the response as a stream to handle one DICOM instance at a time\n- You don't need to customize the order of the retrieved images\n\nImproving performance for web viewers\n-------------------------------------\n\nThe following sections apply to retrieving DICOM images when using a web viewer.\n\n### Increasing maximum concurrent requests\n\nWhen using a web-based viewer, most browsers enforce a maximum number of\nconnections per host. This number is typically six. However, in practice\nthere is no restriction on the maximum number of concurrent requests\nbecause:\n\n- Most browsers use HTTP/2 by default if the server supports HTTP/2\n- HTTP/2 uses a single connection for all requests\n\nFor example, if you use [Cornerstone.js](https://github.com/cornerstonejs/cornerstone)\nto build a viewer, you can modify the maximum number of concurrent requests\nto a number that is optimal for your viewer by changing [`maxSimultaneousRequests`](https://github.com/cornerstonejs/cornerstoneTools/blob/cefbb34e4a651ae49c0b066e36f6ccf0cb6ea89f/src/util/getMaxSimultaneousRequests.js#L5)\nwhen configuring Cornerstone.js.\n\n### Using web workers\n\nJavaScript is a single-threaded language, so extra care must be taken when\napplying concurrency patterns. You can use [web workers](https://en.wikipedia.org/wiki/Web_worker)\nto process both DICOM images and HTTP requests.\n\nFor example, if you modify your HTTP request processing to web workers, you\ncan effectively double your viewer's FPS from 30 FPS to 60 FPS assuming a\n30 millisecond request processing overhead."]]
