First two bytes are not an SOI marker error
sparalic opened this issue · 12 comments
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 backtraceThanks!
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?
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
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.
Thank you @Enet4. Makes sense, thank you for all of your work on this package! It's very helpful.
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",
] }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.
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.
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.
@Enet4 Hey thanks a lot for responding if you don't mind can you reopen this issue? Also this can be tested now?
@IsmailAlamKhan Feel free to file a new issue, so it can be tracked independently. You may also test the changes in the pull request.
@Enet4 Thanks. Yes I have tested the changes in the pull request and its working properly, so should I create a new issue?