1.2.840.10008.1.2.4.51 with 8 bit YBR_FULL_422 color images

[kuldip...@gmail.com]

We have a question whether DICOM transfer syntax 1.2.840.10008.1.2.4.51 ( Lossy 12 bit image compression) - can it be also be used for decompressing 8 bit YBR_FULL_422 color images?

We have this question (& confusion) because of below weird findings from test

Some of 8bit YBR_FULL_422 color images are grayed out after passing thru 1.2.840.10008.1.2.4.50 (JPEG baseline 8bit) de-compressor but they are displayed correctly when using 1.2.840.10008.1.2.4.51 (12 Bit Image Compression).
but within same study images with same properties 8bit YBR_FULL_422 are displayed fine after passing thru 1.2.840.10008.1.2.4.50 (JPEG baseline 8bit) de-compressor.

overall we found during test 1.2.840.10008.1.2.4.51 (12 bit) works always.

I know immediate comment here would you to rely on transfer syntax of image but in one of our legacy product we are forced to rely on a private tag to determine image compression.

I'm looking for comment from JPEG de-compression point of view if 1.2.840.10008.1.2.4.51 (12 bit) can take care of 8 bit & 12 bit both.

Thanks.

[kuldip...@gmail.com]

I did more investigation on this and found issue is related to offsetting read from Start of image (SOI) marker in JPEG de-compression.
so if SOI is not offset then we are seeing graying image due to I believe bad input to de-compressor otherwise not.

Can you someone comment on SOI if it is mandatory in JPEG image.

Thanks.