YBR_FULL_422

[Valentí Montoya]

Hi;

We are having trouble displaying a DICOM object.

This is a compressed object and is YBR_FULL_422. We believe that the object is not well formed, since YBR_FULL_422 and TransferSyntaxUID=JPEGLossless:Non-hierarchical-1stOrderPrediction do not appear in the standard.

Nut, MicroDicom viewer does not display the image correctly, while the RadiAnt does. If we use the DCMTKs to decompress the DICOM object, the result is not displayed correctly neither with the MicroDicom nor with the RadiAnt.

Specifically, it has this data:

COMPRESSED:
(0002,0010) UI =JPEGLossless:Non-hierarchical-1stOrderPrediction # 22, 1 TransferSyntaxUID
(0028,0004) CS [YBR_FULL_422] # 12, 1 PhotometricInterpretation
(0028,0006) US 0 # 2, 1 PlanarConfiguration
(0028,0010) US 576 # 2, 1 Rows
(0028,0011) US 720 # 2, 1 Columns
(0028,0100) US 8 # 2, 1 BitsAllocated
(0028,0101) US 8 # 2, 1 BitsStored
(0028,0102) US 7 # 2, 1 HighBit
(0028,0103) US 0 # 2, 1 PixelRepresentation
(0028,2110) CS [01] # 2, 1 LossyImageCompression
(0028,2112) DS [7] # 2, 1 LossyImageCompressionRatio
(0040,0253) SH (no value available) # 0, 0 PerformedProcedureStepID
(7fe0,0010) OB (PixelSequence #=2) # u/l, 1 PixelData
(fffe,e000) pi 00\00\00\00 # 4, 1 Item
(fffe,e000) pi ff\d8\ff\c4\00\50\00\01\00\02\03\01\01\01\00\00\00\00\00\00\00\00... # 813366, 1 Item
(fffe,e0dd) na (SequenceDelimitationItem) # 0, 0 SequenceDelimitationItem

Any idea what is going on??


Thank you and take care!!

[Chris O'Donnell]

1.2.840.10008.1.2.4.70 JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1])
can be used with any colorspace, the JPEG Lossless encoding works just fine. Finding some viewer that can interpret this combination of data, is another story.

Assuming the image data is in fact good, since you had success with the RadiAnt viewer. So the output of the DCMTK, is it handling the colorspace conversion back to RGB so you can get a displayable image? If the output of the decoding is still YBR_FULL_422, then you'll have to do something else to get to the desired RFB colorspace.

-thanks

[Mathieu Malaterre]

On Friday, September 23, 2022 at 7:49:20 PM UTC+2, uve...@gmail.com wrote:
> Hi;
>
> We are having trouble displaying a DICOM object.
>
> This is a compressed object and is YBR_FULL_422. We believe that the object is not well formed, since YBR_FULL_422 and TransferSyntaxUID=JPEGLossless:Non-hierarchical-1stOrderPrediction do not appear in the standard.

Correct:

* https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_8.2.html#table_8.2.1-1

while:

* https://dicom.nema.org/medical/dicom/current/output/chtml/part05/sect_8.2.html#table_8.2.1-2

[Chris O'Donnell]

Interesting I've never seen that particular table, but congrats on finding the info.

Again this is another "grey area" of PixelData (yes really bad joke), simply too many encoding possibilities, and any vendor's Conformance may or may not go into details beyond simple support of SOP Class / Transfer pairs. In any event, if the original creator of this image knew what they were doing, then the image started life as JPEG Lossy since (0028,2110) CS [01] # 2, 1 LossyImageCompression == 1, and the colorspace is YBR_FULL_422, also what JPEG Lossy uses. Then somewhere the image being decompressed, then possibly re-encoded as Lossless, all the while maintaining the original colorspace, and hence the current state of the image. Real world case, ultrasound image to PACS to some archive, then later retrieve, is enough to demo this workflow.

Seems unusual that YBR_FULL is supported but not YBR_FULL_422, perhaps whoever decided this table was trying to keep things simple or simply missed some combinations.

So JPEG Lossless does not care about colorspace (Photometric), essentially binary blob going in ==> binary blob coming out later when decoding, and the burden is still on the user of the decoder to convert the colorspace into something usable, whatever that means for your application.

I've also seen images from the wild, that are both Planar and YBR_FULL, this combination is not on the table of JPEG Lossless support, but not surprising.

What do we do with these DICOM grey areas? Depends on what you're trying to achieve.

-thanks

[Valentí Montoya]

Thanks for your answers.

I don't have so clear the key point, and for that, I attach my dicom file if you want to test and check my DICOM file.

https://we.tl/t-eQo2X1hFHk

I guess that is a YBR_FULL_422 but every compoenent in YBR_FULL_422 (Y1,Y2,Cb1,Cr1 , Y3,Y4,Cb2,Cr2) compressed is 12 bits and not 8. I think so because, after uncompress this object the pixel data size is not rows*columns*2, is rows*columns*samplesPerPixel.


We transfer has a Preview option, if you don't trust this content. Please, check it.


Thanks

[Chris O'Donnell]

Mathieu is 100% correct, the DICOM standard says your combination is *not* supported, so that could be your final deciding factor.

If you still want to try and support it anyways, then read on. You did mention that one viewer RadiAnt did show these images, or does it have some error?

(0028,0010) US 576 # 2, 1 Rows
(0028,0011) US 720 # 2, 1 Columns
(0028,0100) US 8 # 2, 1 BitsAllocated
(0028,0101) US 8 # 2, 1 BitsStored

So it should be 8 bits / channel. The YBR_FULL_422 colorspace is using chroma subsampling, so you will get fewer pixels than with RGB:
https://en.wikipedia.org/wiki/Chroma_subsampling
RGB:
720 * 576 * 3 = 1,244,160 pixels
YBR_FULL_422:
Y (720 * 576) * 1
B (720 * 576) * 0.5
R (720 * 576) * 0.5
720 * 576 * 2 = 829,440 pixels

But looking at the PixelData size from your original post, it says 813,366

(fffe,e000) pi ff\d8\ff\c4\00\50\00\01\00\02\03\01\01\01\00\00\00\00\00\00\00\00... # 813366

That seems wrong, with anything lossless, you should get approximately 33% to 50% of original size, as a rough guide. So maybe it is not well-formed after all?

-thanks

[Mathieu Malaterre]

There is no subsampling in the DICOM/JPEG file uploaded. This is a plain regular JPEG Lossless (no sub-sampling).

$ jpegdump < input.jpg >& output.txt
$ cat output.txt
[...]
Offset 0x0054 Marker 0xffc3 SOF3 Huffman Lossless Sequential length variable 0x11
JPEG_SOF_Parameters:
SamplePrecision = 8
nLines = 576
nSamplesPerLine = 720
nComponentsInFrame = 3
component 0
ComponentIdentifier = 1
HorizontalSamplingFactor = 1
VerticalSamplingFactor = 1
QuantizationTableDestinationSelector = 0
component 1
ComponentIdentifier = 2
HorizontalSamplingFactor = 1
VerticalSamplingFactor = 1
QuantizationTableDestinationSelector = 0
component 2
ComponentIdentifier = 3
HorizontalSamplingFactor = 1
VerticalSamplingFactor = 1
QuantizationTableDestinationSelector = 0

[David Gobbi]

On Tuesday, 27 September 2022 at 06:13:14 UTC-6, Mathieu Malaterre wrote:
> There is no subsampling in the DICOM/JPEG file uploaded. This is a plain regular JPEG Lossless (no sub-sampling).

It is truly a Frankenstein DICOM. It seems that it was subsampled and then fed into the JPEG compression as if it was _not_ subsampled. I can make it into a "valid" image like this, with dcmtk:

# force PhotometricInterpretation to RGB (no subsampling) and decompress
dcmodify -m "0028,0004=RGB" ko_c_anon.dcm
dcmdjpeg ko_c_anon.dcm ko_c_anon_decompressed.dcm

# force PhotometricInterpetation back to YBR_FULL_422 (subsampled)
dcmodify -m "0028,0004=YBR_FULL_422" ko_c_anon_decompressed.dcm

# convert to pnm for viewing (I used dcmtk 3.6.6)
dcm2pnm ko_c_anon_decompressed.dcm ko_c_anon_decompressed.pnm

After the above commands, I get a .pnm that displays propertly.
The .pnm format can be read by GIMP and possibly by some other programs.

To make a long story short, even the encapsulated JPEG is messed up.

[David Gobbi]

Apologies for the double-post, but here is a full pipeline for rescuing the file with dcmtk 3.6.6:

dcmodify -m "0028,0004=RGB" ko_c_anon.dcm
dcmdjpeg ko_c_anon.dcm ko_c_anon_ybr_422.dcm
dcmodify -m "0028,0004=YBR_FULL_422" ko_c_anon_ybr_422.dcm
dcm2pnm --write-bmp ko_c_anon_decompressed.dcm ko_c_anon_ybr_422.bmp
img2dcm --dataset-from ko_c_anon.dcm --input-format BMP ko_c_anon_ybr_422.bmp ko_c_anon_repaired.dcm

The resulting file "ko_c_anon_repaired.dcm" is uncompressed RGB.

Note that the PixelData in the intermediate "ko_c_anon_ybr_422.dcm" file contains 829440 bytes of 422 data following by 414720 bytes of unused zeros.

[Valentí Montoya]

Thanks a lot. it works perfectly.

Can you explain the clues that made you think the pixel data was subsampled, but when the pixeldata was compressed, it was made as if it wasn't subsampled? Tools and atributes that argues this point?

Thanks to all!!

[Chris O'Donnell]

From examining the JPEG header (from Mathieu's post):

JPEG_SOF_Parameters:
SamplePrecision = 8
nLines = 576
nSamplesPerLine = 720
nComponentsInFrame = 3
component 0
ComponentIdentifier = 1
HorizontalSamplingFactor = 1
VerticalSamplingFactor = 1
QuantizationTableDestinationSelector = 0
component 1
ComponentIdentifier = 2
HorizontalSamplingFactor = 1
VerticalSamplingFactor = 1
QuantizationTableDestinationSelector = 0
component 2
ComponentIdentifier = 3
HorizontalSamplingFactor = 1
VerticalSamplingFactor = 1
QuantizationTableDestinationSelector = 0

All channels have both HorizontalSamplingFactor = 1, and VerticalSamplingFactor = 1, this indicates "no subsampling", you can look this up.

My suspicion that the image was subsampled, was that I actually trusted the PHOTOMETRIC_INTERPRETATION when it said YBR_FULL_422, the 422 portion here means sub-sampled.

-thanks