An error occurs when viewing DICOM images of study using dicomweb-proxy "version": "1.6.4"

[thanhtd1012]

Hi @knopkem! When viewing DICOM images of study using dicomweb-proxy "version": "1.6.4" Github: (1) . Dicomweb-proxy: https://github.com/knopkem/dicomweb-proxy ( "version": "1.6.4") (2) . Webviewer: https://github.com/OHIF/Viewers/tree/v3-stable/

Example: I viewed image of study with StudyInstanceUIDs = 1.2.392.200036.9123.100.11.15000165473693810149439210000183743 (3) .There is the following issue: "file does not exist: data\1.2.392.200036.9123.100.11.15000165473693810149439210000183743\1.2.392.200036.9123.100.11.15000165473693810149595123800360593". Note:

• 1.2.392.200036.9123.100.11.15000165473693810149439210000183743 : StudyInstanceUIDs of study
  • 1.2.392.200036.9123.100.11.15000165473693810149595123800360593: SOP Instance UID of image

I followed the config of Dicomweb-proxy (1) above as same as: https://github.com/knopkem/dicomweb-proxy/issues/2 However, it is still the issue (3) above.

I want the image streaming, no download need when viewing DICOM images. What should I do? Thank you so much !

[knopkem]

Hi, if you get the error above than there is a problem with retrieving the images from PACS. The proxy doesn't stream the data but rather first downloads it to the local data directory than reads it again and sends it to the client. While this isn't perfect streaming would not help (except that there would be a different error message). So you need to investigate why c-get (or c-move depending on your config) doesn't work. I recommend to enable verbose logging. Also check firewalls, whitelists on PACS and the PACS logs. Good luck. Cheers.

[lam0620]

I get the same error.

Hi @knopkem,

At the first time, your proxy support view dicom by wado standards that stream images from PACS server (the proxy no need to download images). Refer my issues: https://github.com/knopkem/dicomweb-proxy/issues/2

This is my config that worked using WADO to stream dicom images from my CC pacs server.

servers: { dicomWeb: [ { name: 'PROXY', wadoUriRoot: 'http://192.168.201.41:8082/wado', qidoRoot: 'rs', wadoRoot: 'rs', qidoSupportsIncludeField: true, imageRendering: 'wadouri', thumbnailRendering: 'wadouri', enableStudyLazyLoad: true, }, ], },

Now, I use the proxy version 1.6.4, it doesn't work right now with the same config.

My question is: Your proxy doesn't support wado to stream images. is it right? If it also support , what do I config to work?

It is appreciate if you help me this issue Thanks

[knopkem]

Hi @lam0620, I think the issue that you have is different to @thanhtd1012 although the error message etc. is the same. From your setup I can see that you use the proxy only for QIDO to C-FIND translation but use the native CC interface for getting the images (which is fine). I'm not too familiar with CC but from a quick look it seems they don't support full dicomweb but rather only Wadouri, which is why you choose this setup. (correct me if I'm wrong here) Back to your issue: I think the reason why this setup broke with the latest version must be the updated version of the OHIF viewer which is responsible to do the routing. What I think must have changed is how they interpret the config. It seems that now using relative paths (the rs route on qido) together with the absolute route on wado somehow is not used correctly anymore. Apparently it now falls back to use relative paths for everything. This means that your search goes correctly via the proxy but than it also tries to fetch images via the proxy which didn't work as there is a setup issue (e.g. C-Get not supported or C-Move not whitelisted) this is because you didn't intend to route it via the proxy. So while you could fix the setup to route everything via the proxy it would be slower (as it first needs to download to the proxy), you should try to use the old OHIF viewer first with the new version of dicomweb-proxy (just replace the public folder) and check if it works again, then you should first try the latest OHIF version to make sure they did not already fix the issue and only then you should create an issue here: https://github.com/OHIF/Viewers Hope this was clear. Good luck.

[lam0620]

Hi @knopkem

Thank you so much for your quick and detail response. I understood and I am going to try old ohif version first to find out the problem.

[lam0620]

Hi @knopkem

I don't try old OHIF viewer with current proxy (v1.6.4) yet. However, ohif v3 stable (that doesn't work with the proxy 1.6.4) also works with your first proxy version (1.0.11) with the same config (as above).

I checked your source and found out that you have done re-structure source code at v1.1.5. The error occured in api '/rs/studies/:studyInstanceUid/series/:seriesInstanceUid/metadata' of routes.ts.

With new version, it's using: const rsp = await fetchMeta(query, studyInstanceUid, seriesInstanceUid); fetchMeta() checks and calls c-get (or c-move) to download images if files no exist (while I configed native CC wado to stream images from CC server dirrectly). The download should be in api '/wadouri' of routes.ts (correct me if I'm wrong).

With v1.0.x, it used: let json = await utils.doFind("IMAGE", query, tags); that no download bussiness

Could you help me check?

Thanks,

[knopkem]

Hi @lam0620,

good catch, I forgot about this change. The reason for this change was that in order to enable MPR in OHIF you need to use wadors (so when using wadouri MPR will always be disabled). Unfortunately wadors needs a lot of metadata, more than you can gather via C-FIND, which is why fetchMeta now needs to really fetch all images to perform file based meta data parsing. What needs to be done is to detect if wadors or wadouri is used and switch the logic in fetchMeta. I'll do this asap. Cheers.

[lam0620]

Thanks @knopkem , I look forward to receiving your fix!

I understood the situation.

1.That means MPR won't be anabled if I use native CC wado (metadata is retured by C-FIND is not enough), will it? ( Yes, CC don't support full dicomweb but rather only Wadouri.)

2. How can I config to be able to enable MPR with current proxy version (download images and view)? Is this config correct? dicomWeb: [ { name: 'PROXY', wadoUriRoot: 'wadors' qidoRoot: 'rs', wadoRoot: 'rs', qidoSupportsIncludeField: true, imageRendering: 'wadouri', thumbnailRendering: 'wadors', enableStudyLazyLoad: true, supportsFuzzyMatching: true, }, ],

[knopkem]

Hi @lam0620,

I've added a new config to default.json "fullMeta" which by default is true. Setting it to false will only use c-find for meta information fetching. You also need a patched version of the OHIF viewer for this to work, so I updated the version here to the latest (4.12.25).

Regarding MPR, I was not precise, in fact it works with wadouri but requires that fetchMeta returns the detailed meta data that it can only get from the images, so streaming like in your case won't work (this is a limitation of the OHIF viewer). So in order to have MPR enabled, make sure to leave fullMeta true and use the default app.config.js + make sure the proxy can fetch the images via GET or MOVE from the pacs. Btw. this also allows the proxy to compress images (by default using jpeg-ls).

Regarding the app.config.js: wadoUriRoot: needs to point to the proxy wadouri route which is called the same with imageRendering and thumbnailRendering you can tell OHIF what to use: wadouri or wadors

[lam0620]

I got it.

Thank you so much @knopkem