-
Notifications
You must be signed in to change notification settings - Fork 81
Roadmap
This page contains a set of functionalities and other requirements which are either planned or under review for the DICOM-rs project. While a reasonable order of importance is sometimes hard to establish, a best effort is made to keep these topics in descending order of priority.
This roadmap is currently incomplete. If you would like to provide feedback on the contents or structure of the page, please feel free to file an issue or create a discussion thread.
DICOM files may be very large, and often not all of the contents need to be retrieved and interpreted immediately upon opening the file for reading. As part of this topic, users should be able to partially load the contents of a DICOM file through the same DicomObject abstraction. As an example, loading one of the frames of a multi-frame instance should not require loading all frames in memory.
Status: planned, under development.
Networking is a crucial aspect of the DICOM standard that DICOM-rs should indeed cover.
The ul component contains low-level utility functions and data types for the upper-layer protocol, thus making way for DICOM-rs to provide usable components in a PACS. An additional utility in ul is the Association API. However, we have yet to see more service class providers (SCPs) and service class users (SCUs), made available not only as tools but also through their own API.
There is interest in:
- Writing common abstractions for building application entities with a specific purpose, including easier presentation context negotiation and command data set construction.
- Creating standalone SCPs and SCUs into individual crates under the umbrella of the project, to exist both with a command line interface and a programming interface.
- Currently available are
dicom-storescu,dicom-storescp, anddicom-findscu, but only as command line tools.
- Currently available are
Status: planned, under development
As DICOM access and manipulation comprises I/O intensive operations for the most part, it is reasonable for DICOM-rs to provide an API which does not block on I/O, which may be achievable through future-based interfaces. While the story on asynchronous Rust is somewhat new, both the futures API and the async/await syntax are stable. Integrating asynchronous APIs into the existing code base would require understanding which parts should become asynchronous and how to make this integration while keeping the library cohesive and intuitive to use.
Status: planned
The DICOM object API exposes the contents of a DICOM object as a dynamic dictionary of attributes indexed by their tag. When an application expects objects with a conforming SOP class, the set of attributes expected is usually fixed and known a priori. In order to assist these use cases, an IOD module API will define macros that let consumers declare the set of required and optional attributes as Rust structs. The macros will take care of implementing deserialization and serialization from/to a standard DICOM representation.
Status: planned
Allow for users to abstract away from the raw contents of the Pixel Data attribute (which might even be encoded) to obtain a more usable representation. Objects would be able to provide methods which return a multi-dimensional array of pixels, for example. Multiple representations could be possible and should be considered:
- An
ndarrayof pixels, to be treated as a generic tensor object. - An
imagedata type, to be used in an image processing and visualization environment. Integration with this crate would facilitate the development of a DICOM image preview tool. - Custom, built-in types for any piece of media which could be in a Pixel Data attribute. This might not be ideal, but could perhaps solve certain edge cases.
The same abstraction may also be applied to similar attributes. Implementations would have to deal with concerns which are specific to the type of image, including modality, window levels, etc.
Status: ✅ practically done; follow issue #125 for the level of support
Throwing errors in the event of an unexpected situation isn't always ideal, because we may not wish to change the execution flow when they happen. However, still keeping track of what happened may be important. Moreover, for a solution of this scale, it may be useful to inspect the inner workings of certain components.
The DICOM-rs ecosystem should integrate a flexible logging API. An ideal candidate would be lightweight and serve as a façade to any other logging back-end of choice.
Status: ✅ done, tracing is used by crates in the ecosystem
The Rust ecosystem presents itself as an excellent ground for targeting WebAssembly, thus enabling solutions to be run on web browsers and many other controlled platforms.
Future developments for DICOM-rs should seek to retain support for WebAssembly whenever possible and reasonable. Additional capabilities in crates under the project which are not compatible with WebAssembly may be put behind a Cargo feature (see for example the feature named inventory-registry). When in doubt of whether a certain change may compromise this compatibility, please see the Rust and WebAssembly book. Useful pages are "Which Crates Will Work Off-the-Shelf with WebAssembly?" and "How to Add WebAssembly Support to a General-Purpose Crate".
Status: ✅ already available, with room for improvement.
DICOM validation sets already exist, exactly for the purpose of checking a software's compliance with the standard. Not only should one seek to increase test coverage in general, this project should have a test harness on which the outputs of our components would be tested against ground truth. This harness could then be exploited to measure the overall implementation coverage.
Status: 🗒️ feedback welcome; some integration tests already fetch complete DICOM objects from the third-party dicom-test-files package, which can be extended to provide more DICOM test files. A more extensive suite of data-based tests would be beneficial.