Enet4 / dicom-rs

Rust implementation of the DICOM standard
https://dicom-rs.github.io
Apache License 2.0
428 stars 82 forks source link

UnexpectedDataValueLength { tag: Tag(0x0002, 0x0001) } #565

Open manfroms opened 1 month ago

manfroms commented 1 month ago

Hello everyone!

I have a little question about _dicomobject crate. I'm trying to read a valid DICOM file exported from NewTom scanner using, for example, this snippet of code:

use std::error::Error;

use dicom_object::OpenFileOptions;

fn main() -> Result<(), Box<dyn Error>> {
    let obj = OpenFileOptions::new().open_file("test.dcm")?;
    let patient_name = obj.element_by_name("PatientName")?.to_str()?;
    println!("{patient_name}");
    Ok(())
}

But there is such error: Error: ParseMetaDataSet { source: UnexpectedDataValueLength { tag: Tag(0x0002, 0x0001), length: Length(0),... I tried some other different read options but no positive result. All DICOM tags in a file are presented except this one which is empty, that's the feature of DICOMs made on this type of scanner and never had problems reading DICOMs from other manufacturers.

Is there a way to read all DICOM tags anyway, ignoring this error (emptiness of such tags)? Or maybe turn of Snafu to make logs clear?

Glad to hear you solutions, thanks :)

Enet4 commented 1 month ago

Hello! From that description, it appears that the DICOM file has an empty File Meta Information Version (0002, 0001). This field must have a value containing two bytes (00h, 01h) for compliant DICOM files as per PS3.10 section 7.1.

Is there a way to read all DICOM tags anyway, ignoring this error (emptiness of such tags)?

Not right now, but I suppose we could change this to provide a default for the meta attribute with a tracing warning when it is empty or missing. It might affect future-proofing in the event that DICOM defines a second version of the file information version, but in the worst case it might just break in subsequent reading, so this may be a good compromise. Would you be interested in sending a pull request?

Or maybe turn of Snafu to make logs clear?

You can use Snafu reporting capabilities to improve the readability of that error. More info on this here.

#[snafu::report]