[Bug] Dicom overlay [6000,3000] not displayed in viewer V3

[myoussef90]

Describe the Bug

i was using OHIF V2 and was displaying dicom overlay fine, it get from meta file as inline binary string from tag [6000,3000] and parse it to get buffer array. now when switching to V3 with same meta file it dosn't display any overlay
How can i display it in V3 ?

this is the dicom file

DicomOverlay.zip

Steps to Reproduce

1- upload the dicom file
2- compare between V2 and V3 displaed image

The current behavior

Dicom Overlay dosn't display

The expected behavior

Dicom Overlay should display like V2

OS

Windows 11

Node version

18

Browser

Chrome

[sedghi]

This is fixed and merged in master

[whage]

@sedghi Are you sure this is part of master? We are using the ohif/app:v3.7.0 docker image and I also tried it with ohif/app:v3.8.0-beta.36 to see if the current latest has it but neither showed the overlay image. I tried with the sample data that @myoussef90 posted and also with some of our own. Is there maybe a configuration flag that has to be turned on for OHIF to show the overlay?

[whage]

Some more info (using the sample data provided by @myoussef90): in v3.7.0, even when I turn on the "Image Overlay" tool, nothing is displayed and there aren't any errors in the browser console. It's okay, I guess this wasn't yet in v3.7.0.
In v3.8.0-beta.36 however, when the tool is turned on I noticed some errors about the overlay data:

[sedghi]

Could you kindly provide the data if it has been anonymized and you can confirm that there is no patient health information present in any of the headers or embedded within the pixel data?

[whage]

Could you kindly provide the data if it has been anonymized and you can confirm that there is no patient health information present in any of the headers or embedded within the pixel data?

I reproduced it with the data posted by @myoussef90 in the original post above: https://github.com/OHIF/Viewers/files/12331299/DicomOverlay.zip

[sedghi]

I dragged and dropped and tried orthanc and it looks fine

What are your steps

[whage]

Hm, I'm not sure what "steps" I can provide. I have an Orthanc instance serving the data with quite a few customizations.
I suppose I'm missing some configuration in Orthanc or OHIF.
Is there a specific setting for the overlay tool to work? Anything required in the dataSources section of the OHIF config json maybe?
This is my datasources array in the config file:

dataSources: [
    {
      friendlyName: 'Orthanc',
      namespace: '@ohif/extension-default.dataSourcesModule.dicomweb',
      sourceName: 'dicomweb',
      configuration: {
        name: 'AE_RMCPACS',
        wadoUriRoot: '/pacs/wado',      // nginx should proxy it to the orthanc container
        qidoRoot:    '/pacs/dicom-web', // nginx should proxy it to the orthanc container
        wadoRoot:    '/pacs/dicom-web', // nginx should proxy it to the orthanc container
        qidoSupportsIncludeField: true,
        imageRendering: 'wadors',
        thumbnailRendering: 'wadors',
        enableStudyLazyLoad: true,
        requestTransferSyntaxUID: '1.2.840.10008.1.2.4.70'
      },
    }
  ],

With no other ideas, I kept looking at the debugger while the image is being rendered and I noticed the following, maybe this could help find the cause:

What I'm trying to highlight is that as overlay data is being processed, at one point the code puts it into this missingOverlay array because overlay.dataUrl is not there. I'm wondering where that dataUrl should come from, maybe I have something turned off in Orthanc that should be served?
There is also this pixelData.BulkDataURI with the value

http:///pacs/dicom-web/studies/1.3.12.2.1107.5.1.4.38373.4.0.3079176420572422/series/1.3.12.2.1107.5.1.4.38373.4.0.3079176822219296/instances/1.3.12.2.1107.5.1.4.38373.4.0.30799074411846/bulk/60003000

But there were no requests sent to that URL. Why could it be that there is no request for the data? Maybe I'm heading in the wrong direction with this.

I saw that it was @wayfarer3130 who committed the mentioned lines, maybe he could provide some info.

Any help is greatly appreciated!

[wayfarer3130]

Add in the ds configuraiton block:
bulkDataURI: {
enabled: true,
},
That will setup a function callback to fetch the data. Probably it should get enabled by default.

[jianghuaw]

I met the same issue while using dicomjson. But it works well with dicomlocal provider. They use different dicom parsers: cornerstonejs/dicomParser v.s. dcmjs. In csjs dicomParser, it seems not process the overlay data properly.

[jianghuaw]

Add in the ds configuraiton block: bulkDataURI: { enabled: true, }, That will setup a function callback to fetch the data. Probably it should get enabled by default.

I may have a try with this proposal. Where should I put this setting? Seems not working with app-config.cfg?

[jianghuaw]

I confirm the bulkDataURI setting doesn't work for the dicomjson source data provider. Probably should some fix in cornerstonejs/dicomParser.

[whage]

Add in the ds configuraiton block: bulkDataURI: { enabled: true, }, That will setup a function callback to fetch the data. Probably it should get enabled by default.

Wow, thanks a lot, this solved it!
Here is what my datasources look like now:

dataSources: [
    {
      friendlyName: 'Orthanc',
      namespace: '@ohif/extension-default.dataSourcesModule.dicomweb',
      sourceName: 'dicomweb',
      configuration: {
        name: 'AE_RMCPACS',
        wadoUriRoot: 'pacs/wado',
        qidoRoot:    'pacs/dicom-web',
        wadoRoot:    'pacs/dicom-web',
        qidoSupportsIncludeField: true,
        imageRendering: 'wadors',
        thumbnailRendering: 'wadors',
        enableStudyLazyLoad: true,
        requestTransferSyntaxUID: '1.2.840.10008.1.2.4.70',
        bulkDataURI: {
          enabled: true,
        },
      }
    }
  ]

Important note for the Orthanc people: OHIF treats the mentioned BulkDataURI as absolute, as pointed out here: #1602 (comment) so we have to make sure that Orthanc generates the correct absolute URL for it. It uses its DicomWeb.Host configuration parameter or the contents of the "Forwarded" HTTP header (preferred, especially when Orthanc is behind a reverse proxy) to build that URL. In my case, I had to change DicomWeb.Host from /pacs to localhost/pacs for my local setup (obviously this will vary depending on how you made Orthanc accessible, the point is, it needed a host part too).

[jianghuaw]

Andras, congrats!
So the "bulkDataURI" is the resolution for Orthanc. Still need help on dicomjson at here:-) Thanks for any clue @wayfarer3130 @sedghi

[sedghi]

please take a look at the latest master and re-open this if still an issue