I’ll start by stating, I’m a developer, so this is a bit of reaching for me with a pacs server. There are a number of things with dicom files where I just don’t know what things SHOULD be.
That being said, let me explain my problem. I’m hoping someone can help me diagnose, and if lucky, resolve my issue. I’m running a study where sites are uploading cath lab images. The images are anonymized and stored for review. The issue I’m hitting is that the images aren’t all visible. It seems like some of them aren’t loading.
I’ve run this process in the past and never encountered a problem. My setup hasn’t changed either so I don’t know why I’m suddenly having an issue now.
I’m suspecting two potential issues but they’re kind of guesses at this moment.
- Caching. I don’t know if that’s the case, but it feels like caching where the images aren’t being properly extracted and cached, but that being said, I’d expect things to be cached eventually instead of remaining broken.
- Encoding. Maybe it’s a weird encoding issue? Though why do some images load and others don’t? They’re all coming from the same site. I’d expect them to have the same encoding.
Either way, I’m not able to properly test any of these theories, because I don’t know where to start. I’m hoping for a little input. If I can get a decent diagnoses of the problem, then I should be able to start looking for some solutions at least.
Hello,
If Alain’s instructions don’t help you, you’ll have to post a minimal working example (i.e. DICOM files) so that other people can independently reproduce your issue:
https://book.orthanc-server.com/users/support.html#discussing-a-minimal-working-example
Sébastien-
Hello, I’ll start with the version data. I’m running this with docker-compose. We have a few things so you’ll see traefik for port forwarding between applications on our server, but I won’t bother to supply that data. since it’s very specific to our configuration:
orthanc:
image: osimis/orthanc:latest
container_name: orthanc
ports:
- 8042:8042
- 4242:4242
restart: unless-stopped
depends_on:
- postgresql13
networks:
- internal
- traefik
volumes:
- $USERDIR/docker/orthanc/orthanc.json:/etc/orthanc/orthanc.json:ro
- $USERDIR/docker/orthanc/perms.lua:/etc/orthanc/scripts/perms.lua:ro
- $USERDIR/docker/orthanc/db:/var/lib/orthanc/db/
environment:
VERBOSE_ENABLED: “true”
VERBOSE_STARTUP: “true”
OSIMIS_WEB_VIEWER1_PLUGIN_ENABLED: “true”
As for the console tab when I open the viewer: Here is one anonymized study: https://pacs.bmc2.org/osimis-viewer/app/index.html?study=fd3506e3-f6efd2ad-7f700962-5441706d-ab216735 - so you can see the output and results yourself
{
“type”: “failure”,
“status”: 400,
“response”: {
“name”: “HttpRequestError”,
“message”: “Failed HTTP request”,
“stack”: “Error\n at new HttpRequestError (blob:https://pacs.bmc2.org/7f44d98c-945d-4ff6-b7e8-8066ce5d90e6:499:23)\n at xhr.onreadystatechange (blob:https://pacs.bmc2.org/7f44d98c-945d-4ff6-b7e8-8066ce5d90e6:449:32)”,
“data”: {},
“status”: 400,
“statusText”: “”
}
}
If you want to look at the files specifically, you can download the study. I’m still a bit mixed on my thoughts of what has changed between previous studies we’ve run and this round. The pacs configuration hasn’t changed, but some server configurations do tend to change. I’m between it being a caching issue (or extraction from compressed files), or an encoding issue since we do get lots of files from multiple sites. I’m suspecting it’s caching, but I just don’t know how to test for it.
I can also provide any specific items you might want to see from my config file.
Hi John,
Take care that, when you use “latest”, you actually don’t know which version you are using. I recommend using a specific tag.
I don’t have your orthanc.json file. At this time, all I can suspect is that you are using StorageCompression and Orthanc 1.11.0 or 1.11.1 and are therefore affected by the bug described here. If this is the case, I would revert to osimis/orthanc:22.6.2 while waiting for the release containing the bug fix.
HTH
Alain
Hi Alain. I want to give you a HUGE thanks for the help with this. You really nailed it on the issue. I was running 1.11.1 with compression.
I changed the orhtanc version as you recommended and it seems to have fixed everything. I was honestly worried that I’d need to re-upload all of the images, but it seems to have corrected itself.
I did want to note, changing the image to osimis/orthanc:22.6.2 from latest took me from version 1.11.1 to 1.11.0 - is it likely I’ll see this issue coming back up since I’m on one of the two versions mentioned?
Also, this might be a stupid question, but how can I check the image vs orthanc version? Is there a link you can pass long that states osimis/orthanc:22.6.2 runs Orthanc 1.11.0?
Again, I really appreciate your help with this, I’m not sure how long it’d have taken me to find this issue without your help!!
Hi John,
Glad I could help.
To know what Orthanc version is included in each osimis/orthanc image, you can check:
- the Dockerhub page should show the content of the latest version. But I just noticed that I was publishing the wrong README file. This should be fixed by tomorrow. In the meantime, here’s the link to the dockerhub readme.
- the release notes will show you the history
I double checked the change logs and the storage cache bug was actually introduced between 1.11.0 and 1.11.1 so what you observe makes sense.
Best regards,
Alain.
Again, I really appreciate the help with this!