Panic when trying to serialize encapsulated pixel data
Closed this issue · 2 comments
qarmin commented
fn check_file(path: &str) {
let Ok(res) = open_file(path) else {
return;
};
let mut item_to_dump = Vec::new();
let _ = DumpOptions::new().dump_object_to(&mut item_to_dump, &res);
let _ = dicom_json::to_string(&res);
let mut item_to_dump = Vec::new();
let _ = res.write_dataset(&mut item_to_dump);
}file compressed.zip
causes panic
thread 'main' panicked at /home/runner/.cargo/git/checkouts/dicom-rs-165e2a1669724caa/239cba5/json/src/ser/mod.rs:220:17:
serialization of encapsulated pixel data is not supported
stack backtrace:
0: rust_begin_unwind
at /rustc/d9284afea99e0969a0e692b9e9fd61ea4ba21366/library/std/src/panicking.rs:665:5
1: core::panicking::panic_fmt
at /rustc/d9284afea99e0969a0e692b9e9fd61ea4ba21366/library/core/src/panicking.rs:74:14
2: dicom_json::ser::<impl serde::ser::Serialize for dicom_json::DicomJson<&dicom_core::header::DataElement<dicom_object::mem::InMemDicomObject<D>>>>::serialize
at /home/runner/.cargo/git/checkouts/dicom-rs-165e2a1669724caa/239cba5/json/src/ser/mod.rs:220:17
3: <serde_json::ser::Compound<W,F> as serde::ser::SerializeMap>::serialize_value
at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde_json-1.0.120/src/ser.rs:652:22
4: serde::ser::SerializeMap::serialize_entry
at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde-1.0.204/src/ser/mod.rs:1817:9
5: dicom_json::ser::<impl serde::ser::Serialize for dicom_json::DicomJson<&dicom_object::FileDicomObject<dicom_object::mem::InMemDicomObject<D>>>>::serialize
at /home/runner/.cargo/git/checkouts/dicom-rs-165e2a1669724caa/239cba5/json/src/ser/mod.rs:90:13
6: serde_json::ser::to_writer
at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde_json-1.0.120/src/ser.rs:2145:5
7: serde_json::ser::to_vec
at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde_json-1.0.120/src/ser.rs:2180:10
8: serde_json::ser::to_string
at /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/serde_json-1.0.120/src/ser.rs:2211:20
9: dicom_json::ser::to_string
at /home/runner/.cargo/git/checkouts/dicom-rs-165e2a1669724caa/239cba5/json/src/ser/mod.rs:19:5
10: dicom::check_file
at ./src/crates/dicom/src/main.rs:32:13
11: dicom::main
at ./src/crates/dicom/src/main.rs:22:9
12: core::ops::function::FnOnce::call_once
at /rustc/d9284afea99e0969a0e692b9e9fd61ea4ba21366/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
timeout: the monitored command dumped core
##### Automatic Fuzzer note, output status "None", output signal "Some(6)"
Enet4 commented
Thank you for reporting. Yes, serialization of encapsulated pixel data as DICOM JSON is not supported because it is not even standardized by the DICOM JSON model structure. Even if it were to provide a way to encode the entire encapsulated pixel data into JSON, it would be nonstandard.
A service wishing to provide pixel data via QIDO or similar should instead exclude the attribute from the DICOM object and replace it with a bulk data URI that depends on the service itself. If anything, the dicom-json crate could incorporate some helper logic for translating these large fields into bulk data URIs, though we should guide this logic with a real world scenario.