Tomorrow, we will be having our next weekly hangout at 10:00 AM ET until 11:00 AM ET
Anyone is welcome to join to ask questions at https://bit.ly/slicer-googlemeet-hosted-by-kitware
Please post to this thread to put a topic on the agenda! We will try to prioritize agenda items during the meeting.
Sam and J-Christophe
I propose two (unrelated) agenda topics:
- Considerations for extending DICOMweb STOW-RS support in 3D Slicer
- Standardizing scene data representation with OpenUSD
FYI, Slicer already supports STOW-RS - Slicer can push DICOM information objects to a DICOMweb server: right-click on the item to send in the DICOM browser and choose “Send to DICOM server” and DICOMweb protocol.
Also note that a completely new, patient-centered (typical in clinical use) visual DICOM browser (with real-time thumbnail display, simultaneous local and remote content display) is almost ready (see development branch here). It uses backgrund tasks for all local and remote data parsing, sending, and receiving. It currently uses classic DIMSE protocol, but it is designed to be extensible with DICOMweb protocol. The main question is if we want to add DICOMweb networking classes to CTK in C++ (this would be ideal, but it seems hat DCMTK does not support DICOMweb; so we would need to look for another C++ implementation or implement it ourselves) or add wrapper for a Python DICOMweb toolkit (but it may complicate multithreading and adds Python dependency for a core feature).
FYI, Slicer already supports STOW-RS
Thanks @lassoan , and yes, very helpful to see this laid out in your earlier Discourse post as well!
On my side I’d like to understand current capabilities and obstacles and possibly extend existing STOW-RS support for the following limited features:
- Authentication for STOW-RS communication, possibly adding or extending UI elements for this
- Uniform DICOM series UID and series instance numbering for generating DICOM instances within a single Slicer session
Happy to chat further this morning.