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.

Functional requirements

Writing DICOM files

DICOM objects which were either built from scratch or loaded from a file should be easily serialized to disk or another media. This functionality can be tackled in a similar fashion as the reading part:

• In the encoding crate, the Encode trait provides the necessary routines for turning DICOM data primitives and headers into bytes. (Done)
• In the parser crate, make it so that data set tokens are serializable through the Encode API. (Not Done)
• In the object crate, have a means to turn a DICOM object into a sequence of data set tokens. (Not Done)

Status: planned, under development.

Lazy loading

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.

Pixel Data abstraction

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 ndarray of pixels, to be treated as a generic tensor object.
• An image data 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.

Non-functional requirements

Data oriented test harness

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

Improved error handling

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

Logging

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

WebAssembly support

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.