1. Forum
  2. Usenet
  3. COMP.PROTOCOLS.DICOM

  • 1.2.840.10008.1.2.4.51 with 8 bit YBR_FULL_422 color images

    From kuldiprindani@gmail.com@21:1/5 to All on Fri Dec 17 08:53:59 2021
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From kuldiprindani@gmail.com@21:1/5 to kuldip...@gmail.com on Fri Dec 17 14:05:04 2021
    On Friday, December 17, 2021 at 10:54:01 AM UTC-6, kuldip...@gmail.com wrote:
    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.

    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)