OHIF viewer downloading more than 2x data as compared to the size of actual image

[Bhavesh Pandey]

Hi,

I have a dcm4chee-arc-light server and I have connected an OHIF viewer to it. In the following image in the network its showing 28.7 MBs

Now if I download the image directly from the dcm server the downloaded zip file is of only 11.4 MBs. 

I guess because of this issue XRays take forever to open in the viewer. Is there any issue in this?

If this is not the issue then is there any compression we can put to reduce the size of XRay images?

[Tomas Zubiri]

Hello Bhavesh,

I can confirm that 28MB is the expected uncompressed size of a 4280x3520 x ray, assuming 2 bytes per image. The 11MB file you show was compressed with ZIP, so I suspect that it wasn't transferred over any DICOM protocol.

What's happening is that OHIF is requesting any transfer syntax and dcm4che is providing lots of transfer syntaxes, for some reason the default is uncompressed. OHIF doesn't have great support for alternative transfer syntaxes. You could try to change the transfer syntaxes offered by dcm4che and offer just JpegLossless (1.2.840.10008.1.2.4.70 I believe)

[Bhavesh Pandey]

The config which you just mentioned is to be done like this? I have already configured this in my dcm4chee-arc-light server. Should I change the transfer syntax?

[Tomas Zubiri]

Interesting, OHIF should support this transfer syntax. https://github.com/cornerstonejs/cornerstoneWADOImageLoader/blob/master/docs/TransferSyntaxes.md

is that the only transfer syntax you are offering? Try disabling all other transfer syntaxes, in case ohif is ignoring the rule priority, or negotiating another transfer syntax due to an error (The conformance statement does mention something about requiring a codec).

[Bhavesh Pandey]

I have only one transfer syntax configured. Is the dcm4chee-arc-light has some other transfer syntax internally which is not displayed in the UI?

[gunterze]

Does the OHIF viewer use C-MOVE, C-GET or WADO to retrieve the objects?

If it uses WADO-URI, it has to specify to accept the compressed Transfer Syntax by Query Parameter: "transferSyntax=*" .

For WADO-RS, it has to specify "multipart/related;type=application/dicom;transfer-syntax-uid=*" as accepted media type.

[gunterze]

Why did you configured dcm4chee-arc to use JPEG 2000 for compression. According David Clunie's "Lossless Compression of Grayscale Medical Images - Effectiveness of Traditional and State of the Art Approaches" , you get the same compression rates much cheaper with JPEG-LS.

[Bhavesh Pandey]

I removed all the compressions, I guess your previous comment is correct about putting transferSyntax=* in query parameter, I am trying to put that in my viewer. Because I saw the same being configured while setting up weasis and it works without even putting any compression rule in dcm4chee-arc. I will try that and will update.

[gunterze]

dcm4chee-arc does not support compression on retrieve. If you do not receive the objects already compressed, you have to compress them on receive, if you want to retrieve them compressed.

[Bhavesh Pandey]

Okay. I came across the following issue for OHIF viewer where Danny has told how to set the transfer syntax. Basically he mentioned to set multipart/related; type="image/jp2" in accept header. This is working for Xray images but not CT is not loading but if I am setting multipart/related; type="application/octet-stream"; transfer-syntax="1.2.840.10008.1.2.1" this as header, CT is loding but XRays are again not compressed. is there any header which is common for all type of modalities?

[gunterze]

As mentioned in my previous message, objects can only be retrieved compressed, if they are stored compressed. Particularly retrieving compressed raw Pixel Data by WADO-RS  "Accept: multipart/related; type="image/jp2" requires, that the image(s) are stored JPEG 2000 compressed in the archive.

[Bhavesh Pandey]

Resolved it by removing the type parameter in accept header, just configured accept header as 'multipart/related; transfer-syntax=*' and every thing is not coming compressed. All my images are stored as JPEG 2000 compressed in the archive.

[gunterze]

You should better use

Accept: multipart/related;type=application/dicom;transfer-syntax=*

Otherwise, it depends on the implementation of the WADO-RS server, if you get just the Raw Pixel Data or the whole DICOM object.

[Bhavesh Pandey]

Its giving 406 

[gunterze]

Not for me:

gunter@gunter-nb:~/work/dcm4chee-arc-light$ curl -vo wado.compressed -H 'Accept: multipart/related;type=application/dicom;transfer-syntax=*' http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457
* Expire in 0 ms for 6 (transfer 0x5597e4c8b5c0)
* Expire in 1 ms for 1 (transfer 0x5597e4c8b5c0)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Expire in 0 ms for 1 (transfer 0x5597e4c8b5c0)
* Expire in 0 ms for 1 (transfer 0x5597e4c8b5c0)
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5597e4c8b5c0)
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457 HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.64.0
> Accept: multipart/related;type=application/dicom;transfer-syntax=*
>
< HTTP/1.1 200 OK
< Access-Control-Allow-Headers: origin, content-type, accept, authorization
< Date: Wed, 04 Sep 2019 15:27:22 GMT
< Connection: keep-alive
< Access-Control-Allow-Origin: *
< ETag: "-54168404"
< Last-Modified: Wed, 04 Sep 2019 14:54:54 GMT
< Access-Control-Allow-Credentials: true
< Transfer-Encoding: chunked
< Content-Type: multipart/related;start="<1f706a3c-7b11-425f-97c0-58959de7c369@resteasy-multipart>";transfer-syntax=*;type="application/dicom"; boundary=64003faa-c7e5-44e1-88ec-7d346751eabd
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
<
{ [16392 bytes data]
100  177k    0  177k    0     0  8046k      0 --:--:-- --:--:-- --:--:-- 8429k
* Connection #0 to host localhost left intact
gunter@gunter-nb:~/work/dcm4chee-arc-light$ curl -vo wado.uncompressed -H 'Accept: multipart/related;type=application/dicom' http://localhost:8080/dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457
* Expire in 0 ms for 6 (transfer 0x558358ba95c0)
* Expire in 1 ms for 1 (transfer 0x558358ba95c0)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* Expire in 0 ms for 1 (transfer 0x558358ba95c0)
* Expire in 0 ms for 1 (transfer 0x558358ba95c0)
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x558358ba95c0)
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.3.6.1.4.1.5962.1.2.1.20040826185059.5457 HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.64.0
> Accept: multipart/related;type=application/dicom
>
< HTTP/1.1 200 OK
< Access-Control-Allow-Headers: origin, content-type, accept, authorization
< Date: Wed, 04 Sep 2019 15:27:41 GMT
< Connection: keep-alive
< Access-Control-Allow-Origin: *
< ETag: "-54168404"
< Last-Modified: Wed, 04 Sep 2019 14:54:54 GMT
< Access-Control-Allow-Credentials: true
< Transfer-Encoding: chunked
< Content-Type: multipart/related;start="<407376de-5111-4e2f-ae83-912313720512@resteasy-multipart>";type="application/dicom"; boundary=78dbee9b-22d7-4670-8205-67d2e2ac45ae
< Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS, HEAD
<
{ [16392 bytes data]
100  518k    0  518k    0     0  9605k      0 --:--:-- --:--:-- --:--:-- 9430k
* Connection #0 to host localhost left intact
gunter@gunter-nb:~/work/dcm4chee-arc-light$ ls -l wado.*
-rw-r--r-- 1 gunter gunter 181276 Sep  4 17:27 wado.compressed
-rw-r--r-- 1 gunter gunter 531142 Sep  4 17:27 wado.uncompressed

[gunterze]

What's your dcm4chee-arc version?

[Bhavesh Pandey]

5.17

[Bhavesh Pandey]

I am facing a bigger issue now after putting compression, the browser takes too much RAM to render. just opening 9 studies together takes more than 6 GBs of RAM. and for systems with 4 GBs of RAM browser starts saying 'Ran out of memory'. Any solution for this ?

On Wednesday, 4 September 2019 21:00:58 UTC+5:30, gunterze wrote:

[gunterze]

Using JPEG-LS instead JPEG 2000 for compression may reduce the memory acquisition on decompression.

[gunterze]

But, it will not help, if the OHIF viewer keeps all dicom images in memory...

[Bhavesh Pandey]

yeah I tried this but no luck

[Marco Politi]

Hi pande... Can you help me to install and setting ohif? I can't able to

[Juan Pablo Bizantino]

Hello All,

I am facing an issue related to transfer size while opening studies from the OHIF viewer.

I have implemented DCM4CHEE ARC 5 VERSION: 5.29.1  and OHIF (Version Number 4.12.50)

My PACS server has only one compression rule. I have followed steps from this link.

https://github.com/dcm4che/dcm4chee-arc-light/wiki/Compression-of-received-images

JPEG LS Lossless

1.2.840.10008.1.2.4.80

As you can see in the above images compression rule is working.

• Original study folder size (According to Ubuntu) is 724,4 Mb
• fs1 folder (149 Mb)     (du -h | sort -h)
• DCM4CHEE UI: (153 Mb)

Study without Compression

fs1 folder - Ubuntu folder Size (149 M)

DCM4CHEE  UI  File Size (153)

__________________________________________________________________________

Here is my OHIF Configuration.

OHIF Version     Version Number   4.12.50

Config file

window.config = {
  // default: '/'
  routerBasename: '/',
  // default: ''
  showStudyList: true,
disableServersCache: false,
  studyPrefetcher: {
    enabled: true,
    order: 'closest',
    displaySetCount: 10,
    preventCache: false,
    prefetchDisplaySetsTimeout: 300,
    maxNumPrefetchRequests: 100,
    displayProgress: true,
    includeActiveDisplaySet: true,
  },

  servers: {
    dicomWeb: [
      {
        name: 'CSMDICOM',
        wadoUriRoot:
          'https://pacs.xxxxxxxxxxx/dcm4chee-arc/aets/xxxxxx/wado',
        qidoRoot:
          'https://pacs.xxxxxxxxxxxxxxx.com/dcm4chee-arc/aets/xxxxxxx/rs',
        wadoRoot:
          'https://xxxxxxxxxb.com/dcm4chee-arc/aets/xxxxx/rs',
        qidoSupportsIncludeField: false,
        imageRendering: 'wadors',
        thumbnailRendering: 'wadors',
        requestOptions: {
          auth: 'admin:changeit',
        },
      },
    ],
  },
  studyListFunctionsEnabled: true,
};

I also hardcoded the transfer Syntax on OHIF code to be sure that there is no other option.

  params.push('transferSyntax=1.2.840.10008.1.2.4.80');

  const paramString = params.join('&');

  console.log(`********************   ${server.wadoUriRoot}?${paramString}`);

  return `${server.wadoUriRoot}?${paramString}`;

__________________________________________________________________

When I open the study from OHIF and run  iftop (a tool to monitor traffic for Ubuntu). I noticed that the study is NOT compressed. 

I was expecting a total transfer size of 150 Mb but I received 707 Mb.

It seems that DCM4CHEE is not sendig the study compressed despite it was stored compressed and transferSyntax was forced on the request.

What could be my config error?

___________________________________________________________________________________

sudo iftop -i wlp2s0

Console log from OHIF

********************   https://xxxxxxxxxxxxxxx/dcm4chee-arc/aets/xxxxxxx/wado?requestType=WADO&studyUID=1.2.392.200036.9116.2.6.1.44063.1797455977.1674096279.609983&seriesUID=1.2.392.200036.9116.2.6.1.44063.1797455977.1674098289.251473&objectUID=1.2.392.200036.9116.2.6.1.44063.1797455977.1674098289.428195&contentType=application/dicom&transferSyntax=1.2.840.10008.1.2.4.80

[Todd Jensen]

On Tuesday, January 24, 2023 at 11:41:58 AM UTC-6 jpbiz...@gmail.com wrote:

>I am facing an issue related to transfer size while opening studies from the OHIF viewer.

>[...]

>When I open the study from OHIF and run  iftop (a tool to monitor traffic for Ubuntu). I noticed that the study is NOT compressed. 

>I was expecting a total transfer size of 150 Mb but I received 707 Mb.

>[...]

If you follow all the DICOMweb traffic from OHIF, I think this is because OHIF is requesting the pixel data via a WADO frame request without setting an accept parameter,(see https://petstore.swagger.io/index.html?url=https://dcm4che.github.io/dcm4chee-arc-light/swagger/openapi.json#/WADO-RS/RetrieveFrames), so dcm4chee decompresses the pixel data before sending it it on as a byte stream.

You'll need to dig into the OHIF request to see if it sets the accept parameter and then how dcm4chee actually handles it.

Todd Jensen, PhD

Jensen Informatics LLC

[Juan Pablo Bizantino]

Hello Jesen,

I found the solution.

On Viewers/platform/viewer/public/config/default.js   I set qidoSupportsIncludeField to false and commented the following lines.

After restarting the viewer, the total transfer size matched the DCM4CHEE Size.

qidoSupportsIncludeField: false,
//        imageRendering: 'wadors',
//        thumbnailRendering: 'wadors',
//        requestOptions: {
//          auth: 'admin:admin',
//        },

I don´t know if this is the right solution but it works.

--
You received this message because you are subscribed to a topic in the Google Groups "dcm4che" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dcm4che/aDv6Xs-6rDc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dcm4che+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dcm4che/d9f898b4-6a24-4b50-bf9e-76bac57fad52n%40googlegroups.com.