Gibberish images

Google Groups archive
1

Hello All,

I have been using Orthanc for some time along with OHIF viewer, all works well. My current configuration is, I pass JSON file which has metadata along with url for the instance.

I decided to try Dicom-web but somehow my images are all gibberish. I approached someone at OHIF and he suggested that I should check my Orthanc configuration, maybe something is missing.

Any idea what could be the issue?

Attached are results of same study pulled via Stone-Web and Osimis-Viewer, both works well. Also, attached same study pulled via OHIF which has gibberish result.

My current Orthanc version is 1.9.7, Dicom-web 1.7, GDCM 1.4

Thank you!

Osimis-Viewer.png

OHIF.png

Stone-Web.png

dicomweb.json (662 Bytes)

orthanc.json (35.7 KB)

2

Hello,

Please provide a sample (possibly anonymized) DICOM image, as well as your Orthanc logs in “–verbose” mode:
https://book.orthanc-server.com/users/support.html

Regards,
Sébastien-

3

Thank you so much Sébastien for the response.

Kindly find log file in verbose mode along with anonymized study.

Best regards,
Rick

Orthanc.log (81 KB)

7609a40f-a8299562-36e387f7-c7cca0ff-0882fcab.zip (3.75 MB)

4

Hello,

I do not see any issue with Orthanc. Let us start Orthanc using Docker as follows:

$ docker run --rm -t -i -p 8042:8042 jodogne/orthanc-plugins:1.9.7

Secondly, let us upload your ZIP file with the sample DICOM files as follows:

$ curl http://orthanc:orthanc@localhost:8042/instances -H ‘Expect:’ --data-binary @$HOME/Downloads/7609a40f-a8299562-36e387f7-c7cca0ff-0882fcab.zip

Finally, let us call WADO to generate an image (I used the last instance in your logs):

$ curl ‘http://orthanc:orthanc@localhost:8042/wado?objectUID=1.2.276.0.7230010.3.1.4.476117791.10792.1644251838.203&requestType=WADO’ > /tmp/sample.jpg

You’ll find the resulting JPEG file attached to this message, which shows that everything is fine.

Note that you’ll have to install the GDCM plugin, because your DICOM instances are using the JPEG2k encoding.

HTH,
Sébastien-

sample.jpg

5

Hi all

Once I experienced something similar. Been a long time and I’m recounting from memory. These garbled images are kind of preview-ish images browsers display while loading the images.

Maybe, just maybe, there was a hiccup somewhere, be it network, database, etc. Clearing cache and reloading the page should “solve” the problem.

Hth

Luiz

6

Hello Luiz,

Thanks for your comment, but there is no cache for WADO/DICOMweb in Orthanc.

Regards,
Sébastien-

7

Hi Sébastien

I really meant browser cache. Should have been a bit more explicit. Thanks!

Best,
Luiz

8

Dear Sébastien,

Yes, following your steps does produce a sample.jpg file.

I am perplex now. I am using pretty much both OHIF and Orthanc out of box and I don’t get proper image if I use DicomWeb.

I don’t get any errors on Chrome Console for javascript nor on Network pane. Any suggestion where I should look or what could I do to pin point the issue. Thank you so much!

Following is my server configuration in OHIF for DicomWeb.

dicomWeb: [
{
name: ‘Orthanc’,
wadoUriRoot: ‘http://192.168.86.114:8099/orthanc/wado’,
qidoRoot: ‘http://192.168.86.114:8099/orthanc/dicom-web’,
wadoRoot: ‘http://192.168.86.114:8099/orthanc/dicom-web’,
qidoSupportsIncludeField: false,
imageRendering: ‘wadors’,
thumbnailRendering: ‘wadors’,
enableStudyLazyLoad: true,
supportsFuzzyMatching: true,
},
]

Best regards,

9

Maybe this issue only appears on some specific images from your sample series. You should try to narrow down such specific images.

As a better solution, submit your sample series to the OHIF support team who could help you in this task. Indeed, as far as this forum is concerned, we have not the knowledge about OHIF debugging.

Regards,
Sébastien-

10

Dear Sébastien,

All the images with following Meta Header produces Gibberish images.

Meta header
0002,0010 (TransferSyntaxUID): 1.2.840.10008.1.2.4.90

I was asked by OHIF member to make sure the response from Orthanc is in the correct compression and that Orthanc is not only serving part of the bytestream?

How do I check that?

Many thanks!

11

Dear Sébastien,

I have an interesting finding. I am sure you can tell by now that I am serious about this bug :).

I used the Cornerstone example to load my single image from MRI. Then I used the same image using RadiAnt. Files are attached for reference.

You could see this test is without Orthanc involvement. The issue here seems to be in cornerstone routine or maybe the way image is compressed to jp2k.

If for instance the issue is in the compression then why RadiAnt would work and also why direct URI to OHIF would work?

I don’t have the answer to this. All I know that when I use Dicomweb to OHIF with jp2k transfer syntax I get gibberish image(s).

Best regards,

Cornerstone.png

Radiant.png

12

I have never said you weren’t serious about this issue.

Again, please provide one single sample DICOM image with this issue, together with the associated WADO call that is used by OHIF (which is just a URL that you can track in the console of your Web browser):
https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example

Having to duplicate your private investigation by myself represents a waste of time, given that you visibly have all the required information at hand.

13

Dear Sébastien ,

I think I found what causes the issue. We receive studies which are pre-compressed in jp2k before we store them in Orthanc. Those which are compressed via fo-dicom produce gibberish images, only when accessed through DicomWeb protocol. Meanwhile those which are compressed via Gdcm/DCMTK do not produce gibberish images when accessed through DicomWeb protocol.

I have privately sent those studies to you because when I anonymize, ImplementationVersionName changes from fo-dicom 4.0.1 to OFFIS_DCMTK_366 and I wanted to keep things original.

What perplexes me here is that studies which are compressed via fo-dicom produce normal images in OHIF if pulled as a JSON launch, which is my current way of accessing studies. In fact, I use RadiAnt and Weasis on a regular basis on my desktop to view fo-dicom compressed images and they appear to be normal in both the tools.

One resource at OHIF suspect that the metadata I am getting from Orthanc may not be correctly matching the image that OHIF is trying to decide. I am using WADO-RS.

He also suspects that maybe the response from Orthanc is not in the correct compression or its only serving part of the bytestream.

I do not know the answer to these.

What I do know now is what causes the issue. Going forward I can store all the studies compressed only in Gdcm instead of fo-dicom. But how do I fix my history where studies are compressed in jp2k via fo-dicom?

Any thoughts?

Best regards,

OHIF_ServerInfo.json (471 Bytes)

dicomweb.json (662 Bytes)

14

Dear Ric,

I confirm the reception of your images, unfortunately I’m still unable to reproduce, because you haven’t provided the URL that is used by OHIF for its WADO request and that leads to your issue:
https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example

I have used the following curl command-line, and everything is fine:

$ curl ‘http://orthanc:orthanc@localhost:8042/wado?objectUID=1.2.276.0.7230010.3.1.4.333173554.5108.1644525102.12793&requestType=WADO’ > /tmp/sample.jpg

The WADO URL can be found in the console of your Web browser.

Sébastien-

15

Dear Ric,

I confirm that I’ve received your private message containing 2 links to OHIF with problematic images.

By looking at the console of my Web browser, I confirm that I can see that OHIF does not use WADO as you wrote in your first message, but the DICOMweb protocol (more precisely, WADO-RS).

However, I am not a OHIF developer, so I cannot trace down the issue, that most likely occurs within the JavaScript package used by OHIF to decode the JPEG2k images.

Please ask your contact at OHIF to generate me a minimal working example with a problematic DICOMweb WADO-RS request, indicating what Orthanc actually returns versus what OHIF expects. This minimal working example should only use “curl”, not an actual deployment of OHIF as you pointed me to.

Without this information, I am unable to provide any further guidance.

Regards,
Sébastien-