First two bytes are not an SOI marker error

[Sparkle Russell-Puleri]

Hi @Enet4 ,
I am new to Rust (from python) and was just trying to do some basic image loading tasks with this library. However, I keep getting the above error, I did try your sample code from the dicom-rs documentation. But I am not sure, can you please let me know what I am missing?

use dicom::object::open_file;
use dicom_pixeldata::PixelDecoder;

fn main() {

    let path = "../0003.dcm";
    let _obj = open_file(&path).unwrap();
    let data = _obj.decode_pixel_data().unwrap();

    println!("{:?}", data)
}

Error:

Finished dev [unoptimized + debuginfo] target(s) in 0.36s
Running `target/debug/dicom_testing`
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error(DecodePixelData { source: Custom { message: "JPEG decoder failure", source: Some(Format("first two bytes are not an SOI marker")) } })', src/main.rs:24:41
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Thanks!

[Eduardo Pinho]

Thank you for reporting, @sparalic! It seems like a possible lack of support for decoding that particular file. Is there a chance you can share an anonymized version of that file, or additional details of it?

[Sparkle Russell-Puleri]

Hi @Enet4,
Thank you for your quick response! Yes, it's an open source image. I did check the type of encoding via pydicom and from what I see it's: '1.2.840.10008.1.2.4.50' --> JPEG Baseline

0003.dcm.zip

[Eduardo Pinho]

Thank you @sparalic! That's a spicy one! This sample DICOM file from the RUBO DICOM viewer contains encapsulated pixel data with odd-lengthed fragments (though it's not fully DICOM-compliant, some systems are tolerant to this). And due to a quirk in the current JPEG adapter implementation, it was assuming that the fragments were padded to even length, which is why it failed to read these frames.

I threw in a draft patch (#414), although I have yet to decide whether to keep this implementation with the patch or go with something completely different.

[Sparkle Russell-Puleri]

Thank you @Enet4. Makes sense, thank you for all of your work on this package! It's very helpful.

[Md Ismail Alam Khan]

Hey @Enet4 we are facing the same issue with the following .dcm file. Here is my Cargo.toml and also the .dcm file

dicom = "0.7.0"
# dicom-pixeldata = "0.7.0"
dicom-pixeldata = { version = "0.7.0", default-features = false, features = [
    "image",
    "rayon",
] }

US000002.dcm.zip

[Md Ismail Alam Khan]

Investigating further I have found that every 2 instance of that series have this issues and specially the instance inside the SR CAR series doesn't open at all. I have attached the zip.

20240611100616C6EC JONES MARY.zip

[Eduardo Pinho]

Thank you for reporting, @IsmailAlamKhan. This may be a different cause to the same symptom, though I haven't quite figured it out yet. Unwrapping the JPEG out of the DICOM files, they seem to be valid JPEG.

[Eduardo Pinho]

OK so, the JPEG adapter was trying to decode more than one frame, probably due to some trailing bytes at the end of the fragment. I can investigate further, but an easy patch is to limit the number of frames to decode. I pushed this to #535 for now.

[Md Ismail Alam Khan]

@Enet4 Hey thanks a lot for responding if you don't mind can you reopen this issue? Also this can be tested now?

[Eduardo Pinho]

@IsmailAlamKhan Feel free to file a new issue, so it can be tracked independently. You may also test the changes in the pull request.

[Md Ismail Alam Khan]

@Enet4 Thanks. Yes I have tested the changes in the pull request and its working properly, so should I create a new issue?

[Eduardo Pinho]

@Enet4 Thanks. Yes I have tested the changes in the pull request and its working properly, so should I create a new issue?

Yes please go head. I can then link the PR to it.