Inconsistent downloaded file size

We are having problems with the weight of the images that are transferred on the platform.

As an example, when I download an image from the web platform (http://$URL/app/explorer.html) and download a frame from a mammogram, it weighs ~ 13MB. When using our viewer, an instance of OHIF, it accesses through another end-point (http://$URL/dicom-web/studies/$ID-STUDY/series/$ID-SERIE/instances/$ID-INSTANCE/frames/1) and downloads a file (“1”) of ~ 53MB.

This is causing that, for users with a bad internet connection (public hospitals in Chile), the images take several minutes to download.

What could be causing this problem?

Hello,

By default, the “/studies/…/series/…/instances/…/frames/…” URI of DICOMweb transcodes the frame content to transfer syntax “1.2.840.10008.1.2.1” (explicit VR Little Endian). This explains why your frame is larger that the source DICOM file.

If you want to control the transfer syntax for the resulting frame, you can set the “Accept” HTTP header. For instance, here is how to transcode to JPEG:

$ curl -u orthanc:orthanc http://localhost:8042/dicom-web/studies/1.3.6.1.4.1.5962.1.2.4.20040826185059.5457/series/1.3.6.1.4.1.5962.1.3.4.1.20040826185059.5457/instances/1.3.6.1.4.1.5962.1.1.4.1.5.20040826185059.5457/frames/1 -v -H ‘Accept: multipart/related; type=image/jpeg; transfer-syntax=1.2.840.10008.1.2.4.51’

You could also consider using the “/studies/…/series/…/instances/…” URI, as this one won’t transcode the DICOM file.

It would be very nice and extremely useful if you could consider contributing to the Orthanc project by writing an article on your deployment for public hospitals in Chile. We need this kind of information to sustain the development of Orthanc in the long-term!

Regards,
Sébastien-

Thanks for your answer. We will surely write about our experience using Orthanc and Ohif.

Chile is a very long country. Especially in the south, there are regions in extreme areas with 100,000 inhabitants (or less). This implies that it is not possible to have all the specialists in each of our cities. In this context, telemedicine plays an important role, allowing professionals from other cities to diagnose patients in one hour. This is a huge leap for patients who, a few years ago, had to travel 2,000 km for an exam.

About the solution that you comment, adding the header gives me the following error and then the application crashes: “DCT coefficient out of range orthanc”.

Regards,
Rafik

Thanks for your feedback, we’re looking forward to your testimonial!

You have visibly hit the same problem as here in GDCM:
https://groups.google.com/g/orthanc-users/c/xt9hwpj6mlQ/m/_BNkoDk8AAAJ

As written in my previous answer, you could also consider using the “/studies/…/series/…/instances/…” URI, as this one won’t transcode the DICOM file.

Regards,

Sébastien-

Modifying the transcode gives me the same error/crash as before (“DCT coefficient out of range”) with:

curl -u user:pass http://$URL/studies/21e6ef7a-92be94c8-a402bf25-af55586e-9bb5ad9b/modify -d ‘{“Transcode”:“1.2.840.10008.1.2.4.51”}’

About using the “/studies/…/series/…/instances/…” URI, work fine but OHIF use the other endpoint. There is any case of OHIF configured without the “frames/1” path?

I can’t answer regarding the OHIF configuration, as I’m not one of their developers.

Regarding your transcoding issue, please provide a sample DICOM file, without whom we can’t provide any further guidance.

Also note that you could give a try to the new Stone Web viewer, that might not be affected by this issue, as it doesn’t use the “…/frames/1” URI:
https://www.orthanc-server.com/static.php?page=stone-web-viewer

Sébastien-

What we finally did was make our proxy between Orthanc and Ohif change the “accept” in the headers.

When we test it with real patients on our production platform, we will tell them how it went.

Thanks!