Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect image when decoding multiframe pixeldata #561

Closed
thomas-tribus opened this issue Sep 3, 2024 · 3 comments · Fixed by #562
Closed

Incorrect image when decoding multiframe pixeldata #561

thomas-tribus opened this issue Sep 3, 2024 · 3 comments · Fixed by #562
Labels
A-lib Area: library bug This is a bug C-pixeldata Crate: dicom-pixeldata

Comments

@thomas-tribus
Copy link

I've noticed that pixeldata is decoded incorrectly when using decode_pixel_data() and then exporting individual frames. When exporting using decode_pixel_data_frame I get correct results. I'm using 2D ultrasound with ybr_full_422 photometric interpretation.

So this works:

let frame = 0;
let pix = dicom.decode_pixel_data_frame(frame)?;
let img_data = pix.to_dynamic_image(0)?;
img_data.save("out.png")?;

And this doesn't:

let frame = 0;
let pixel_data = dicom.decode_pixel_data()?;
//The colors in the output are wrong
let img_data = pixel_data.to_dynamic_image(frame)?;
img_data.save("out.png")?;

Correct result:
frame_0

Result when decoding all frames:
frame_0

I've found a likely culprit too, when using decode_pixel_data a new photometric interpretation is computed based on the number of channels in the input image (see below). The single frame decode_pixel_data_frame doesn't have this (seemingly incorrect) transformation.

// pixels are already interpreted,
// set new photometric interpretation
let new_pi = match samples_per_pixel {
    1 => PhotometricInterpretation::Monochrome2,
    3 => PhotometricInterpretation::Rgb,
    _ => photometric_interpretation,
};

I've created a PR that removes the code and that seems to fix the issue.

@thomas-tribus
Copy link
Author

PR: #562

It seems I can't link it in the development panel, so here it is in the comments.

@Enet4 Enet4 added bug This is a bug A-lib Area: library labels Sep 3, 2024
@Enet4
Copy link
Owner

Enet4 commented Sep 3, 2024

Thank you for reporting. Seeing #562, this seems to be specific to the GDCM integration, correct? Is the ultrasound in JPEG baseline?

@thomas-tribus
Copy link
Author

Tbh, I only tested with the GDCM implementation. And you are right, the ultra sound is in JPEG baseline: Transfer Syntax: 1.2.840.10008.1.2.4.50 (JPEG Baseline (Process 1))

From dicom-dump (some tags omitted):

Media Storage SOP Class UID: 1.2.840.10008.5.1.4.1.1.3.1 (Ultrasound Multi-frame Image Storage)
Media Storage SOP Instance UID: 1.2.840.113619.2.118.541852079.1603983996.11.7.512
Transfer Syntax: 1.2.840.10008.1.2.4.50 (JPEG Baseline (Process 1))
Implementation Class UID: 1.2.840.113619.6.118
Implementation version name: ECHOPAC_201
Source Application Entity Title: VIVIDS70-000384

----------------------------------------------------------
(0008,0008) ImageType                    CS (4, 22 bytes): ["DERIVED", "PRIMARY", "", "0011"]
(0008,0016) SOPClassUID                  UI (1, 28 bytes): "1.2.840.10008.5.1.4.1.1.3.1"
(0008,0018) SOPInstanceUID               UI (1, 50 bytes): "1.2.840.113619.2.118.541852079.1603983996.11.7.512"
(0008,0070) Manufacturer                 LO (1, 24 bytes): "GE Healthcare Ultrasound"
(0008,1090) ManufacturerModelName        LO (1, 10 bytes): "Vivid S70"
(0008,2142) StartTrim                    IS (1,  2 bytes): "1"
(0008,2143) StopTrim                     IS (1,  2 bytes): "18"
(0008,2144) RecommendedDisplayFrameRate  IS (1,  2 bytes): "13"
(0018,0040) CineRate                     IS (1,  2 bytes): "13"
(0018,0072) EffectiveDuration            DS (1,  4 bytes): "1.27"
(0018,1020) SoftwareVersions             LO (1, 18 bytes): "Vivid S70:201.84.0"
(0018,1063) FrameTime                    DS (1,  8 bytes): "74.7059"
(0018,1066) FrameDelay                   DS (1,  2 bytes): "0"
(0018,1088) HeartRate                    IS (1,  2 bytes): "95"
(0018,1242) ActualFrameDuration          IS (1,  2 bytes): "74"
(0018,1244) PreferredPlaybackSequencing  US (1,  2 bytes): 0
(0018,6060) RWaveTimeVector              FL (3, 12 bytes): [15.934, 659.238, 1113.335]
(0028,0002) SamplesPerPixel              US (1,  2 bytes): 3
(0028,0004) PhotometricInterpretation    CS (1, 12 bytes): "YBR_FULL_422"
(0028,0006) PlanarConfiguration          US (1,  2 bytes): 0
(0028,0008) NumberOfFrames               IS (1,  2 bytes): "18"
(0028,0009) FrameIncrementPointer        AT (1,  4 bytes): (0018,1063)
(0028,0010) Rows                         US (1,  2 bytes): 708
(0028,0011) Columns                      US (1,  2 bytes): 1016
(0028,0014) UltrasoundColorDataPresent   US (1,  2 bytes): 1
(0028,0100) BitsAllocated                US (1,  2 bytes): 8
(0028,0101) BitsStored                   US (1,  2 bytes): 8
(0028,0102) HighBit                      US (1,  2 bytes): 7
(0028,0103) PixelRepresentation          US (1,  2 bytes): 0
(0028,2110) LossyImageCompression        CS (1,  2 bytes): "01"
(0028,2112) LossyImageCompressionRatio   DS (1,  2 bytes): "95"
(7FE0,0010) PixelData                    OB (PixelSequence, 19 Items)

@Enet4 Enet4 added the C-pixeldata Crate: dicom-pixeldata label Sep 3, 2024
@Enet4 Enet4 closed this as completed in #562 Oct 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lib Area: library bug This is a bug C-pixeldata Crate: dicom-pixeldata
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants