-
Notifications
You must be signed in to change notification settings - Fork 87
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.
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.
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: mostly done, the API will be designed iteratively.
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. However, we have yet to see more service class providers (SCPs) and service class users (SCUs) other than scpproxy.
There is interest in creating some utility standalone SCPs and SCUs into individual crates under the umbrella of the project.
Concrete tools will be proposed and developed, which will also help to validate and reiterate on the ul component.
Status: a baseline is already available via the Association API in ul, plus some SCU implementations. More DICOM components may be made available over time.
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: under review
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: under review; some integration tests already fetch complete DICOM objects from the third-party dicom_test_files package.
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: planned, see #49
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: baseline already available, although with grounds for improvements