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

Implement asynchronous data retrieval via DICOMweb protocol #4743

Open
lassoan opened this issue Mar 18, 2020 · 6 comments
Open

Implement asynchronous data retrieval via DICOMweb protocol #4743

lassoan opened this issue Mar 18, 2020 · 6 comments

Comments

@lassoan
Copy link
Contributor

@lassoan lassoan commented Mar 18, 2020

To allow Slicer to be launched from web browser (by clicking on a custom URL), we would need parallel, asynchronous data retrieval via DICOMweb (see related discussion in #3794).

@pieper

This comment has been minimized.

Copy link
Member

@pieper pieper commented Mar 19, 2020

I had started looking at this. Best would be to improve the python dicomweb-client code to use an asyncio version of requests.

But to use that in Slicer, we need to tie asyncio in with Qt's event loop. Closest I found was asyncqt, which would need to be ported from PyQt/PySide to work with PythonQt. (Plus it looks messy - shouldn't Qt be able to abstract away the window vs unix differences?).

For our Slicer purposes it might be more straightforward to implement the async wado operations using native Qt networking.

@lassoan

This comment has been minimized.

Copy link
Contributor Author

@lassoan lassoan commented Mar 19, 2020

I would very much in favor of implementing this using Qt networking in CTK. Marco Nolden should be able to help with implementation, maintenance, and optimization, too.

@pieper

This comment has been minimized.

Copy link
Member

@pieper pieper commented Mar 19, 2020

Agreed. There's not a lot of code required to implement the dicomweb part. I think we could even imagine refactoring ctkDICOMDatabase to have either an sqlite or dicomweb backend. Or maybe some combination with sqlite or other local caching.

@lassoan

This comment has been minimized.

Copy link
Contributor Author

@lassoan lassoan commented Mar 19, 2020

The current database works nicely as a local cache.

The table views could be used to build queries - similarly to how it is done for DIMSE query/retrieve.

@pieper

This comment has been minimized.

Copy link
Member

@pieper pieper commented Mar 19, 2020

It would be good to have an interface to work with multiple dicom resources, local and remote. The interface should be consistent so you don't need completely different codebases like you do now for dimse vs local cache.

A current use case for me is to iterate through subsets of tcia collections. I download them via tcia downloader and add them to the slicer database then iterate and search using the slicer.dicomDatabase API, but it would be cleaner if I could get the with dicomweb or local with a single API.

@lassoan

This comment has been minimized.

Copy link
Contributor Author

@lassoan lassoan commented Mar 19, 2020

As I think about it more, the database may be usable as is. Only the background indexer would be need to be implementation specific (local filesystem/DIMSE/DICOMweb).

We could add a "database selector" list, which would contain "Local" and various remote databases. The would be all CTK DICOM database instances on local hard disk, but they would use different indexers. Remote databases would probably only query at patient level by default and only download a study/series when a patient or study is selected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.