dicomweb-server icon indicating copy to clipboard operation
dicomweb-server copied to clipboard

Fix the correct return formats for instance endpoints

Open emelalkim opened this issue 4 years ago • 1 comments
trafficstars

We need to define the correct return formats for WADO-RS and WADO-URI endpoints and fix them. This is related to #59 and further discussion can be found in links there Is the correct format this?

WADO Path Return format
WADO-RS instance multipart/related
WADO-URI instance application/dicom (DICOM Part 10)

Are we going to support/respect accept header sent from the client? which types we need to support? I created this issue to start a discussion to define the best solution. We appreciate any input @pieper, @swederik, @hackermd, @lassoan

emelalkim avatar Jan 09 '21 13:01 emelalkim

The retrieve instance resource is a bit of a mess. In principle, clients can request instances as Part10 files (multipart/related; type="application/dicom"; transfer-syntax=*) or as bulkdata (multipart/related; type="application/octet-stream"; transfer-syntax=* for uncompressed images and multipart/related; type="image/*" for compressed images). The latter is a bad idea in my opinion, since the resource may not actually represent an instance, but only parts of it (i.e., data elements above a given size threshold, such as Pixel Data). However, an origin server that would claim compliance with the standard would need to support all of these media types as far as I know.

On the client side, I decided to always request instances from the origin server using multipart/related; type="application/dicom".

hackermd avatar Jan 11 '21 12:01 hackermd