toimage utility exports jpeg with 411 vs 422 sampling
bmarks-as-software opened this issue · 3 comments
I have a test dicom file with:
- (0028,0004) PhotometricInterpretation = YBR_FULL_422
- (0028,0100) BitsAllocated = 8
- (0028,0101) BitsStored = 8
- (0028,0002) SamplesPerPixel = 3
Command: cargo run cine.dcm -o cine.jpg
When I use the toimage
utility to export the image as a jpeg the subsampling is 411 vs. 422. See output from jpegsnoop:
*** Marker: APP0 (xFFE0) ***
OFFSET: 0x00000002
Length = 16
Identifier = [JFIF]
version = [1.2]
density = 1 x 1 (aspect ratio)
thumbnail = 0 x 0
*** Marker: SOF0 (Baseline DCT) (xFFC0) ***
OFFSET: 0x00000014
Frame header length = 17
Precision = 8
Number of Lines = 852
Samples per Line = 1136
Image Size = 1136 x 852
Raw Image Orientation = Landscape
Number of Img components = 3
Component[1]: ID=0x01, Samp Fac=0x11 (Subsamp 1 x 1), Quant Tbl Sel=0x00 (Lum: Y)
Component[2]: ID=0x02, Samp Fac=0x11 (Subsamp 1 x 1), Quant Tbl Sel=0x01 (Chrom: Cb)
Component[3]: ID=0x03, Samp Fac=0x11 (Subsamp 1 x 1), Quant Tbl Sel=0x01 (Chrom: Cr)
The utility "dcmj2pnm" outputs the jpeg with 422 subsampling correctly.
Thank you for reporting. The situation is that toimage
will first decode any image to native pixel data before proceeding with encoding and saving it to an image file. In the process, it becomes oblivious of any subsampling that was applicable to the original DICOM file.
Is the original image also in JPEG baseline transfer syntax?
One capability that toimage
would benefit from is an "unwrapper" of individual frames from the encapsulated pixel data, so that it could return the JPEG data exactly as encoded.
Otherwise, making it return an image with the same subsampling would require inspecting the encoding characteristics of the original image and devising some heuristics for optimal re-encoding to the target format, which would be much more complicated.
The latest version of dicom-toimage
supports the --unwrap
option, which allows you to take the original JPEG data from a DICOM file without any encoding changes. If this is still not what you were hoping for, please file a new issue with more details.