-
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: planned, API is in the design phase.
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
Although error types are already statically delimited, errors emerging from this ecosystem currently contain little to no context about where they happened. This is an example of an error value which may emerge when opening a file: DataSetSyntax(PrematureEnd)
Requesting a backtrace is not useful because the error was raised with the ? operator, without keeping the full backtrace from the origin of the error at the library level. quick-error has been originally employed as a means to easily create error types, but for a solution of this scale, it becomes harder to work with and does not contribute to good errors.
This topic proposes changing the error handling to become more informative and organized. A good candidate for this refactor is with the use of snafu, as its error handling paradigm scales better and leads to more informative error values.
Status: under review
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 is log, which is lightweight and serves as a façade to any other logging back-end of choice.
Status: under review
The Rust ecosystem presents itself as an excellent ground for targetting 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. 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".