WADO-RS Inconsistent transfer syntax return #4453
Unanswered
abest-halcaeon
asked this question in
Q&A
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I'm working on a project which is running OHIF 3.7 through AWS's API Gateway to a 5.31.2 arc-light server. API Gateway has a hard limit of 10MB on any single request payload or response. For the image sets we're deal with, this is not normally an issue, if dcm4chee would honor the request, but it seems inconsistent on whether it decompresses the frames before returning pixel data.
For some reason OHIF fetches all instance data as a frame, even when it's not a multi-frame instance. Reading the conformance statement for arc-light ( https://dcm4chee-arc-cs.readthedocs.io/en/latest/networking/specs/wado-rs.html#wado-rs-retrieve-frames ) it removes the ability to fetch application/dicom, and you're left setting Accept as "multipart/related; type=application/octet-stream; transfer-syntax=*" which based on my understanding should attempt to return the frame in whatever encoded TS it currently exists at; but again half the time it's decompressing it.
I can't specify an encapsulated transfer syntax, because DCM4CHEE doesn't appear to transcode on the fly, it will only decompress or return whats on disk. I can't mandate an uncompressed syntax because it causes almost a 40% failure rate due to the API Gateway 10MB limit. I could use storage rules to enforce local storage transfer syntax, but we've had issue where enough poorly formed DICOM comes in that converting syntax results in permament corruption of the pixel data; which is unacceptable.
So given those 3, I need a way to get DCM4CHEE to always always return the instance data as it exists on disk and to stop decompressing it. Whatever is causing it to do it, it's consistent per instance, but not consistent for anything else. I tried seeing if it was tied to transfer syntax, pixel data size, photometric interpretation, etc, and I wasn't able to find any commonality on what caused it to do it or not. And this is me fetching the frame via postman and taking OHIF completely out of the picture, so it's not an OHIF thing.
Anyone have any suggestions?
Beta Was this translation helpful? Give feedback.
All reactions