dicomweb-client
dicomweb-client copied to clipboard
dcmjs-org
BulkDataURI response should handle non-multipart as per the DICOMweb standard
The DICOMweb standard specifies that single part BulkDataURI responses are encoded in application/octet-stream, and not as multipart/related responses. That is specified here: https://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_8.7.3.3.1
If the bulk data retrieve is done to fetch all bulk data for an instance or group, then I agree it comes back as multipart, but single retrieve is done not encapsulated, at least according to the standard.
Suggestion is to add a retrieveBulkData which knows how to retrieve either in multipart/related or in single part, handling either one transparently.
@pieper - can I have your thoughts on implementing this one? I was going to modify my local copy to handle either response type and submit a PR for it.
Thanks for chiming in @hackermd. We should work to provide the same behavior in both the python and js clients.
@wayfarer3130 you may want to see this https://github.com/MGHComputationalPathology/dicomweb-client/pull/56 discussion.
Yes, a PR to handle this well would be great.
Uncompressed bulkdata responses need to be multipart/related.
That is only true for the Study/Series/Instance bulkdata response, but the BulkDataURI response itself is actually required to be single part. It doesn't actually allow multipart responses for a single instance, although most implementations work otherwise. The relevant section is: https://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_8.6.1.1 There is a table that says: Bulkdata - The Bulkdata resource contains a Bulkdata Value. which, combined with 8.6.1.1 says that the BulkDataUri used as a direct call, NOT as Instance/Series/Study Bulkdata returns single part data..
So you are saying that the resources in Table 10.4.1.5-1. Retrieve Transaction Bulkdata Resources are either multipart/related or not depending on the resource and whether the items are compressed or uncompressed?
So you are saying that the resources in Table 10.4.1.5-1. Retrieve Transaction Bulkdata Resources are either multipart/related or not depending on the resource and whether the items are compressed or uncompressed?
@hackermd - not quite, the Study, Series and Instance Bulkdata retrieves are all multipart all the time because they are considered to be multiple item retrieves - even if there happens to only be a single item.
{BULKDATA} is always a single item, regardless of whether compressed or uncompressed, and is retrieved as a single item.
That isn't ambiguous for pixel data frames - the frames query is:
.../frames/{frames}
where the {frames} is a set of instances to return. The that is 'multiple', even if it only happens to reference 1 item, then the response is multipart by default. It is permitted to request/return it as single part in that case as far as I can tell - there is a real need for a CP on this area of the standard to clarify when different things get returned.
@wayfarer3130 I am not sure that is correct. Unfortunately, Part 18 was "refactored" a few times (starting with Supplement 183) and several things got more confusing rather than clearer. However, none of these changes in text were supposed to change behavior and break backwards compatibility.
Take a look at section 6.5.5 WADO-RS - RetrieveBulkdata in the 2018e edition. It explicitly specifies multipart/related for both the Accept header field of the request as well as the Content-Type header field of the response.
@hackermd - I see what you are saying. I was aware of the refactoring of Part 18, having done a bunch of cleanup up CP's on it recently. Looks like it needs at least one more cleanup CP. The discussion with WG-06 was to leave the "enhancements" to the standard that got added, but to ensure that the pre-refactoring behaviour is permitted. So, I think that means that the CP should allow both single part and multipart responses for BulkDataURI. What the default behaviour has been wasn't specified previously, so probably that should be tightened up as well, and explicit support for the Range request be added back in. I will bring that up at this month's WG-27 meeting. Still, the reading as of right now at least permits single part responses, so the PR I have in right now to dynamically choose between single and multipart responses is worthwhile.
Thanks for the clarification and follow up @wayfarer3130. Unfortunately, Part 18 is not in great shape at the moment and the CPs are urgently needed.
So, I think that means that the CP should allow both single part and multipart responses for BulkDataURI. What the default behaviour has been wasn't specified previously, so probably that should be tightened up as well, and explicit support for the Range request be added back in. I will bring that up at this month's WG-27 meeting. Still, the reading as of right now at least permits single part responses, so the PR I have in right now to dynamically choose between single and multipart responses is worthwhile.
If that's what is (or will be) in the standard, then let's allow both single and multipart responses. I am just pushing back on workarounds, because I am afraid that those will hurt interoperability in the long run.
Part18 F.2.6 BulkDataURI states
If an attribute contains a "BulkDataURI" , this contains the URI of a bulk data element as defined in Table A.1.5-2 in PS3.19
The description for BulkData in Part19 Table A.1.5-2. DICOM Data Set Macro states:
There is a single BulkData Infoset element representing the entire Value Field, and not one per Value in the case where the Value Multiplicity is greater than one
This implies that the response message must be multipart/related in order to support values with multiplicity greater than one.
@wayfarer3130 we should leave that part of the standard untouched and don't allow servers to response with a single part message. This would break parsing of metadata.