14 releases (7 breaking)
0.8.0 | Nov 6, 2024 |
---|---|
0.7.0 | Apr 25, 2024 |
0.6.2 | Nov 21, 2023 |
0.6.0 | Jul 23, 2023 |
0.1.0 | Aug 31, 2019 |
#537 in Development tools
9,449 downloads per month
Used in 23 crates
(9 directly)
795KB
15K
SLoC
DICOM-rs transfer-syntax-registry
This sub-project implements a registry of DICOM transfer syntaxes, which can be optionally extended.
An implementation based on inventory
can be used through the Cargo feature
inventory-registry
. inventory
allows for users to register new transfer
syntax implementations in a compile time plugin-like fashion,
but not all environments support it (such as WebAssembly).
lib.rs
:
This crate contains the DICOM transfer syntax registry.
The transfer syntax registry maps a DICOM UID of a transfer syntax (TS) into the respective transfer syntax specifier. This specifier defines:
- how to read and write DICOM data sets;
- how to decode and encode pixel data.
Support may be partial, in which case the data set can be retrieved
but the pixel data may not be decoded through the DICOM-rs ecosystem.
By default, adapters for encapsulated pixel data
need to be explicitly added by dependent projects,
such as dicom-pixeldata
.
When adding dicom-transfer-syntax-registry
yourself,
to include support for some transfer syntaxes with encapsulated pixel data,
add the native
Cargo feature
or one of the other image encoding features available.
By default, a fixed known set of transfer syntaxes are provided as built in.
Moreover, support for more TSes can be extended by other crates
through the inventory pattern,
in which the registry is automatically populated before main.
This is done by enabling the Cargo feature inventory-registry
.
The feature can be left disabled
for environments which do not support inventory
,
with the downside of only providing the built-in transfer syntaxes.
All registered TSes will be readily available
through the TransferSyntaxRegistry
type.
This registry is intended to be used in the development of higher level APIs, which should learn to negotiate and resolve the expected transfer syntax automatically.
Transfer Syntaxes
This crate encompasses basic DICOM level of conformance, plus support for some transfer syntaxes with compressed pixel data. Implicit VR Little Endian, Explicit VR Little Endian, and Explicit VR Big Endian are fully supported. Support may vary for transfer syntaxes which rely on encapsulated pixel data.
transfer syntax | decoding support | encoding support |
---|---|---|
JPEG Baseline (Process 1) | Cargo feature jpeg |
✓ |
JPEG Extended (Process 2 & 4) | Cargo feature jpeg |
x |
JPEG Lossless, Non-Hierarchical (Process 14) | Cargo feature jpeg |
x |
JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]) | Cargo feature jpeg |
x |
JPEG-LS Lossless | Cargo feature charls |
✓ |
JPEG-LS Lossy (Near-Lossless) | Cargo feature charls |
✓ |
JPEG 2000 (Lossless Only) | Cargo feature openjp2 or openjpeg-sys |
x |
JPEG 2000 | Cargo feature openjp2 or openjpeg-sys |
x |
JPEG 2000 Part 2 Multi-component Image Compression (Lossless Only) | Cargo feature openjp2 or openjpeg-sys |
x |
JPEG 2000 Part 2 Multi-component Image Compression | Cargo feature openjp2 or openjpeg-sys |
x |
High-Throughput JPEG 2000 (Lossless Only) | Cargo feature openjp2 or openjpeg-sys |
x |
High-Throughput JPEG 2000 with RPCL Options (Lossless Only) | Cargo feature openjp2 or openjpeg-sys |
x |
High-Throughput JPEG 2000 | Cargo feature openjp2 or openjpeg-sys |
x |
JPEG XL Lossless | Cargo feature jpegxl |
✓ |
JPEG XL Recompression | Cargo feature jpegxl |
x |
JPEG XL | Cargo feature jpegxl |
✓ |
RLE Lossless | Cargo feature rle |
x |
Cargo features behind native
(jpeg
, rle
) are added by default.
They provide implementations that are written in pure Rust
and are likely available in all supported platforms without issues.
Additional codecs are opt-in by enabling Cargo features,
for scenarios where a native implementation is not available,
or alternative implementations are available.
charls
provides support for JPEG-LS by linking to the CharLS reference implementation, which is written in C++. No alternative JPEG-LS implementations are available at the moment.openjpeg-sys
provides a binding to the OpenJPEG reference implementation, which is written in C and is statically linked. It may offer better performance than the pure Rust implementation, but cannot be used in WebAssembly. Includeopenjpeg-sys-threads
to build OpenJPEG with multithreading.openjp2
provides a binding to a computer-translated Rust port of OpenJPEG. Due to the nature of this crate, it might not work on all modern platforms.jpegxl
adds JPEG XL support usingjxl-oxide
for decoding andzune-jpegxl
for encoding.
Transfer syntaxes which are not supported,
either due to being unable to read the data set
or decode encapsulated pixel data,
are listed as stubs for partial support.
The full list is available in the entries
module.
These stubs may also be replaced by separate libraries
if using the inventory-based registry.
Dependencies
~6–14MB
~137K SLoC