Comments (20)
Hi! I'm just seeing this for the first time. Apologies for missing it earlier. I'm working on the Azure DICOM implementation. Let me run this error to ground. Thanks for all the context in the posts above. Although @hackermd let us know about the problem early on.
from dicomweb-client.
From an application perspective (e.g. to a user of Slicer's DICOMwebBrowser extension) we would be looking for ways to make the code "just work" as often as possible without needing to know in advance that we wanted to be permissive or not. So I might expect the default behavior to be permissive. Unfortunately the end user often doesn't control the server, or even if they administer the server they don't have the ability to fix non-compliance. So they are relying on the application to handle as much as possible, meaning that the application developer wants to rely on the library developer to handle as much as possible. Unless it impacts performance or some other important thing the user probably doesn't care that the server is not compliant.
Perhaps the library could provide a way to audit servers for compliance (something like dciodvfy
does for instances). This would give a basis for helping server developers to improve compliance.
from dicomweb-client.
@hackermd using media_types=('application/dicom', )
in client.retrieve_instance() fixes the issue for me! Thanks - I can use the latest version now!
from dicomweb-client.
Do you have a way to replicate this on a public instance with anonymized data?
from dicomweb-client.
@athanell Thanks for the PM with more detail. Is it correct that no studies can be pulled from Microsoft's dicomweb server using Slicer's dicomweb browser? (i.e. it's not specific to this data). I haven't used their server before.
It looks like the underlying issue is the accept
header options that Microsoft's server supports vs google and dcm4chee.
I can reproduce this with curl:
curl "https://<public-server>/studies/1.2.<...>/series/1.2.<...>/instances/1.2<...>/frames/1"
The request headers are not acceptable
but
curl -H 'accept: multipart/related; type="application/octet-stream"' "https://<public-server>/studies/1.2.<...>/series/1.2.<...>/instances/1.2<...>/frames/1"
Gives me a stream of data that looks valid (this is the header accept string that ohif uses).
Compare their conformance statements:
https://cloud.google.com/healthcare/docs/dicom#dicom_studyseriesinstances
@hackermd do you have experience with this?
MDN indicates that 406 codes are rarely helpful and maybe Microsoft should be more flexible, but it's also possible that a workaround in the client is preferred.
@lassoan might also have ideas.
from dicomweb-client.
@pieper yes I can verify that in order to pull data from Microsoft's dicomweb either with python or curl one needs to use the header "accept: multipart/related".
The same error came up with different datasets so I think that it is not a data-specific issue.
from dicomweb-client.
Thanks @athanell for reporting the issue and @pieper for looking into it.
I am not sure I understand what the problem is and whether it is a problem with the library or the Slicer application.
The dicomweb_client.api.DICOMwebClient.retrieve_instance_frames()
method sends requests with mulipart/related type="application/octet-stream"
accept header (see here).
Do you have or could you create a debug log, i.e., configure the dicomweb_client
logger with logging.DEBUG
?
from dicomweb-client.
The downloading in Slicer is fairly straightforward:
instances = self.DICOMwebClient.search_for_instances(
study_instance_uid=selectedStudy,
series_instance_uid=selectedSeries
)
...
for instanceIndex, instance in enumerate(instances):
...
retrievedInstance = self.DICOMwebClient.retrieve_instance(
study_instance_uid=selectedStudy,
series_instance_uid=selectedSeries,
sop_instance_uid=sopInstanceUid)
pydicom.filewriter.write_file(fileName, retrievedInstance)
Do you see anything suspicious in this?
from dicomweb-client.
Thanks @lassoan!
Do you see anything suspicious in this?
No, looks good to me.
from dicomweb-client.
@pieper @lassoan what version of dicomweb-client is used by this Slicer version?
The Microsoft dicom-server has an issue with the media type for the retrieve transaction. We updated the dicomweb-client after #41 (included in release 0.51.0.
from dicomweb-client.
Latest DICOMWebBrowser extension installs 0.52.0:
@athanell Please check the version in your Slicer version by opening the Python console (Ctrl+3) and typing these:
>>> import dicomweb_client
>>> dicomweb_client.__version__
'0.52.0'
from dicomweb-client.
@lassoan yes I can verify that my version is the '0.52.0'
from dicomweb-client.
Thanks @lassoan and @athanell for double-checking. It should not be the client version then. I have limited experience with the Microsoft dicom-server and will need to explore further.
from dicomweb-client.
Thanks @StevenBorg! We updated the dicomweb-client in version 0.51.0 such that it tolerates a response with content-type application/dicom
or multipart/related; type="application/dicom"
(see here). However, the client still includes the Accept: multipart/related; type="application/dicom"
header in the request (see here). Technically, we should also include application/dicom
in the accept header field, but were reluctant to do that because it's not compliant with the standard and may cause issues with other origin servers.
from dicomweb-client.
Hello @pieper . I can replicate this error using Slicer's sample head CT on the server http://dicomweb.azurewebsites.net/ found in https://github.com/DICOMcloud/DICOMcloud
from dicomweb-client.
Thanks @athanell - let's see what @hackermd thinks when he gets back. I know he's reluctant to have the client support non-standard behavior and may be more inclined to work with the server developers for better compliance.
from dicomweb-client.
Thanks for performing the additional tests @athanell! As @pieper pointed out, we are generally reluctant to support non-standard behavior. However, I've also come to painfully realize that sometimes there is not much one can do but work around a compliance issue. We should thus find a way to unblock users while working with the server implementer on resolving compliance issues.
@agharwal recently introduced a permissive
flag for the constructor(s) of the dicomweb_client.uri.URI
class (see PR #49) to relax enforcement of standard compliance. I wonder whether we want to extend this logic to the dicomweb_client.api.DICOMwebClient
class?
@pieper @ntenenz what do you think about that?
from dicomweb-client.
I have the same issue. I pinpointed the issue arising going from 0.55.0 to 0.55.1 (and all following versions).
My solution is to use 0.55.0 for now.
Here's my code:
from dicomweb_client.api import DICOMwebClient
client = DICOMwebClient(url=url)
pydicom_dataset = client.retrieve_instance(
study_instance_uid=study_uid,
series_instance_uid=series_uid,
sop_instance_uid=object_uid,
)
The error is:
406 Client Error: Not Acceptable for url: http://......../studies/........../series/............../instances/.............
Note I'm running into this when trying to pull from an MGB VNA. I can provide more details on a private channel if desired. My email is delton at mgh . harvard
from dicomweb-client.
In version 0.55.1, changes were made related to the handling of media types (see #63). These changes were not intended to be break anything, but the following change may lead to a change in server behavior (although it shouldn't from the perspective of the standard):
8ea25c5#diff-437b51b3f115cd02de5408a04dedfcc86f4110edec2a79f7f28ac96d88d06184R2664-R2665
@delton137 could please try setting the media_types=('application/dicom', )
explicitly and see whether that fixes things?
from dicomweb-client.
@delton137 That is an indication that the archive has standard compliance issues. It appears it does not understand/handle the transfer-syntax
part of the Accept
header field.
from dicomweb-client.
Related Issues (20)
- Enable insecure connections to DICOMweb endpoints HOT 2
- [FEATURE REQUEST]: UPS-RS Support HOT 2
- Minimum python requirement question HOT 4
- Missing image data when using `retrieve_*` or `iter_*` HOT 4
- Error retrieving instance: Unexpected media type: "application/dicom". Expected "multipart/related". HOT 14
- Stow-RS fails with current verion sending to orthanc HOT 5
- use 'asks' for concurrent requests HOT 11
- Support for WADO-URI HOT 3
- Query regarding the body of STOW-RS request HOT 2
- Retrive metadata is QIDO-RS or WADO-RS? HOT 2
- Implementation of DICOMs3Client based on DICOMwebProtocol HOT 27
- ImportError: cannot import name 'Protocol' from 'typing' (python 3.7.11) HOT 5
- Orthanc Support HOT 3
- Outdated JPEG-LS media type for retrieval of frames
- Something broke for me going from 0.55.0 to 0.55.1 HOT 1
- Make pillow and numpy optional HOT 2
- Double trailing slash problem HOT 5
- Cannot find reference 'load_json_dataset' in 'api.py' HOT 1
- [Doc] Broken link in "Introduction" HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dicomweb-client.