Delivering frames of multi-frame instances faster

Google Groups archive
1

Hi,

First of all, thanks for the useful project.

I want to decrease the loading time to display a multi-frame dicom.

I use Orthanc via the docker image odogne/orthanc-plugins:1.9.6 . (Config attached)
In our case one DICOM file has 256 frames with a resolution of 512 x 885 .
The image data is uncompressed where one pixel has 8 bits. The PhotometricInterpretation is MONOCHROME2.

The front-end fetches all frames separately via the cornerstone library cornerstoneWADOImageLoader.
Currently this is done with the DICOMweb REST path:
/dicom-web/studies/${studyInstanceUID}/series/${seriesInstanceUID}/instances/${sopInstanceUID}/frames/${frameNumber}
With this method it requires about 3 minutes to transfer all frames.
During the fetching Orthanc needs a decent amount of CPU power.
The used CPU is an AMD FX-8350 with 8 threads from late 2012.

I assume that the bottleneck comes from the following scenario:
I think that the plugin ‘dicom-web’ loads for each frame request the DICOM and generates the frame. If this is the case is there a way to load the DICOM once and generate all frames and cache them?
Or are there other ways to speed this up?

best,
Georg

orthanc.json (2.4 KB)

2

Hi Georg,

I think that the dicomweb plugin is supposed to keep the DICOM file in a cache and therefore, it should be able to deliver the frame fast (at least, it should not read the whole file for each frame). Note however that, if you are accessing frames from multiple files at once, the cache will be invalidated.

Could you check in your browser which routes are being called for each frame with which HTTP headers ? There might be some transcoding/recompression involved that can slow down the retrieving. In Chrome dev tools, you can use this command to know and share the request that is being issued:
image.png

On another hand, I just checked how the StoneViewer was handling the multi-frame instances and it reads the whole file at once and extracts the frames browser side (this might not be possible with CornerStone).

Best regards,

Alain

3

Hi Alain,

Thanks for your response.

Here is the issued HTTP request via curl:

curl ‘http://localhost:3000/fellowEye/dicom-web/studies/1.2.276.0.7230010.3.1.4.1029158210.14816.1583188075.114653/series/1.2.276.0.7230010.3.1.4.1029158210.14816.1583188075.114654/instances/1.2.276.0.7230010.3.1.4.1029158210.14816.1583188075.114652/frames/127’
-H ‘Connection: keep-alive’
-H ‘sec-ch-ua: " Not A;Brand";v=“99”, “Chromium”;v=“92”’
-H ‘accept: multipart/related; type=“application/octet-stream”’
-H ‘sec-ch-ua-mobile: ?0’
-H ‘User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36’
-H ‘Sec-Fetch-Site: same-origin’
-H ‘Sec-Fetch-Mode: cors’
-H ‘Sec-Fetch-Dest: empty’
-H ‘Referer: http://localhost:3000/detailedScanData/instances/f1b2bdce-b89751aa-9eaf53e6-80d3513d-1f97e2ee’
-H ‘Accept-Language: en-US,en;q=0.9’
-H ‘Cookie: token=xxxxx’
–compressed

I use nodejs as proxy. Orthanc receives the HTTP request http://localhost:8042/dicom-web/studies/1.2.276.0.7230010.3.1.4.1029158210.14816.1583188075.114653/series/1.2.276.0.7230010.3.1.4.1029158210.14816.1583188075.114654/instances/1.2.276.0.7230010.3.1.4.1029158210.14816.1583188075.114652/frames/127 .

The HTTP response header is:

HTTP/1.1 200 OK

x-powered-by: Express

access-control-allow-origin: *

connection: keep-alive

keep-alive: timeout=1

content-type: multipart/related; type=“application/octet-stream; transfer-syntax=1.2.840.10008.1.2.1”; boundary=535deb37-7c41-49c1-9e6c-6fc277d2ad7d-69eb328b-1458-482c-9993-a9706118b

content-length: 508437

date: Mon, 30 Aug 2021 07:28:08 GMT

I had a look at StoneViewer. It is quite fast. It uses WebAssenbly to parse the DICOM and in order to ‘see something’ quickly it requests one frame as a rendered image.

The advantage of cornerstone is that it is easier to maintain via npm packages and it has a richer ecosystem like cornerstone-tools .
Therefore we currently try to use this front-end library.
We were able to parse to whole DICOM image via cornerstone (without Orthanc) but for unknown reasons, the image quality was noticeably more pixelated than fetching it frame-wise via Orthanc.

all the best,
Georg

4

Hi Georg,

Sorry, my first message was wrong. I confirm there’s actually no cache at the DICOM file level and therefore, indeed, Orthanc reads the whole file for each frame you request.

Note that you can request multiple frames at once in a single request with the syntax:
…/studies/…/series/…/instances/…/frames/1,2,3

HTH

Alain

5

Hi Alain,

thank you for checking that.

I found the example where WADO-URI (DICOM P10 via HTTP GET) multiframe is used to fetch a multi-frame DICOM with one call.

This example uses the module dataSetCacheManager ( https://github.com/cornerstonejs/cornerstoneWADOImageLoader/blob/master/src/imageLoader/wadouri/dataSetCacheManager.js )
Unfortunately, this does not exist for the REST part https://github.com/cornerstonejs/cornerstoneWADOImageLoader/tree/master/src/imageLoader/wadors .

By chance: Do you know an example or guide on how cornerstone can be used to cache the HTTP response that contains all frames and split the data into single frames?

best,
Georg

6

Hi Alain,

thanks again for your help.
I wrote a function that requests multiple frames with your proposed method and puts the single frames into the cornerstone cache.
I posted this solution in the github issue https://github.com/cornerstonejs/cornerstoneWADOImageLoader/issues/382#issuecomment-913507546 .

best,
Georg