Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for downloading DICOMweb files #1429

Merged
merged 12 commits into from
Jan 22, 2024

Conversation

psavery
Copy link
Collaborator

@psavery psavery commented Jan 9, 2024

Each girder item represents a series. Previously, each item would contain a single file with the same name.

Now, each instance (DICOM file) within a series is represented by separate girder files within the item.

This PR includes download support, so individual DICOM files can be downloaded, or all DICOM files in a series can be downloaded together by downloading the girder item.

Range requests for the DICOM files are attempted if requested. However, the DICOMweb standard doesn't guarantee that they will be supported, and none of the DICOMweb servers we have tried have supported range requests for DICOM files.

To do:

  • Figure out why downloading the file has the wrong mimetype (which results in the web browser displaying the contents rather than downloading)

Fixes: #1309

@psavery psavery force-pushed the dicomweb-separate-files branch 2 times, most recently from 208fd54 to e6e9629 Compare January 10, 2024 20:33
@psavery psavery marked this pull request as ready for review January 10, 2024 20:39
@psavery
Copy link
Collaborator Author

psavery commented Jan 10, 2024

This is ready for review! I added a test for downloading an item (which downloads each file).

During local testing, I downloaded some DICOM files, uploaded them back to girder, and confirmed I could view them with large image (so this confirms that the downloaded DICOM files work correctly).

@psavery psavery requested a review from manthey January 10, 2024 20:44
@psavery psavery force-pushed the dicomweb-separate-files branch 2 times, most recently from d05a1a3 to b9a1a16 Compare January 15, 2024 18:07
@psavery psavery force-pushed the dicomweb-separate-files branch from b9a1a16 to 305a705 Compare January 17, 2024 02:47
@psavery
Copy link
Collaborator Author

psavery commented Jan 17, 2024

Ready for review...

This also adds download support.

Signed-off-by: Patrick Avery <[email protected]>
This attempts a range request for file downloads, even though for every
case we've seen, the DICOMweb server does not honor it...

Signed-off-by: Patrick Avery <[email protected]>
This is more descriptive of what it contains compared to 'dicomweb_meta'.

Signed-off-by: Patrick Avery <[email protected]>
Signed-off-by: Patrick Avery <[email protected]>
This also re-organizes a little code and adds FIXMEs for the range
requests parts.

Signed-off-by: Patrick Avery <[email protected]>
This prevents loading all of the data into memory, which is what we were
doing before.

It is somewhat complicated, but that is because the DICOMweb specification
requires it to be multipart/related with boundaries. We have to be sure
we remove those boundaries and stream only the DICOM file contents.

Signed-off-by: Patrick Avery <[email protected]>
Although I don't think it is likely (unless the chunk size is large), it is
possible that the section right after the header might contain part of the
ending. Thus, we should wait and check it, just as we do for all other chunks,
before yielding it.

Signed-off-by: Patrick Avery <[email protected]>
We also now verify that each download contains a certain amount of bytes.

Signed-off-by: Patrick Avery <[email protected]>
If the ending is split between two chunks, then at most, the second
chunk will contain ending_size - 1 bytes of the ending. So we should
just check for this.

We also don't need to add extra bytes to check for in the ending, because
we don't care what comes after the ending.

Signed-off-by: Patrick Avery <[email protected]>
This prevents a misleading file size of 0 bytes being displayed in
girder.

This is working without issues so far.

Signed-off-by: Patrick Avery <[email protected]>
@psavery psavery force-pushed the dicomweb-separate-files branch from c23b4a0 to 15476f6 Compare January 22, 2024 17:39
@manthey manthey merged commit 247f711 into girder:master Jan 22, 2024
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for downloading files from a DICOMweb server
2 participants