Strange YBR_FULL encoding - DICOM

This is a discussion on Strange YBR_FULL encoding - DICOM ; Hi: I am trying to figure out how to decode an Ultra Sound image where the Photometric Interpretation is YBR_FULL. Originally, the image comes in with aa RLELossless transfer syntax (1.2.840.10008.1.2.5). After I run it through my archimed decompressor, the ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Strange YBR_FULL encoding

  1. Strange YBR_FULL encoding

    Hi:

    I am trying to figure out how to decode an Ultra Sound image where the
    Photometric Interpretation is YBR_FULL.

    Originally, the image comes in with aa RLELossless transfer syntax
    (1.2.840.10008.1.2.5). After I run it through my archimed
    decompressor, the pixel data is 307200, which is the width X the
    height. The samples per pixel value is set to 3. I assume that means
    that the samples have sub-byte values, but where in each byte are the
    pixel boundaries?

    Any help would be appreciated.

    -carlos rodriguez


  2. Re: Strange YBR_FULL encoding


    > Originally, the image comes in with aa RLELossless transfer syntax
    > (1.2.840.10008.1.2.5). After I run it through my archimed
    > decompressor, the pixel data is 307200, which is the width X the
    > height. The samples per pixel value is set to 3.


    With YBR_FULL photometric interpretation, you need to have width x
    height x 3 x (bits allocated) x (number of frames) bits in the
    decompressed pixel data element. If not, something has gone wrong -
    either the source image was incorrect or the RLE codec did not work
    correctly.

    YBR_FULL works very much like RGB, i.e. three samples per pixel, just
    the color space is YCbCr instead of RGB. This is particularly useful
    for doppler ultrasound where most of the image is grayscale (i.e. only
    populates the Y components) and Cb and Cr are mostly zero, except for
    the few patches of color on the image. On such images, RLE achieves
    a compression ration that is much better than the compression ratio
    on an equivalent RGB image.

    Regards,
    Marco Eichelberg
    OFFIS


  3. Re: Strange YBR_FULL encoding

    Thanks for replying, Marco:

    Something is very wrong, then. Here are some tags before and after the
    decompress. The decompressor works pretty much blind and in-place:

    (0002,0010) UI [1.2.840.10008.1.2.5] # 20 1 TransferSyntaxUID
    (0028,0002) US [3] # 2 1 SamplesPerPixel
    (0028,0004) CS [YBR_FULL] # 8 1 PhotometricInterpretation
    (0028,0006) US [1] # 2 1 PlanarConfiguration
    (0028,0010) US [480] # 2 1 Rows
    (0028,0011) US [640] # 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

    (7fe0,0010) OB [00\00\00\00\00\00\...] # 151796 2 PixelData

    after decompression:
    (0002,0010) UI [1.2.840.10008.1.2.1] # 20 1 TransferSyntaxUID
    (0028,0002) US [3] # 2 1 SamplesPerPixel
    0028,0004) CS [YBR_FULL] # 8 1
    PhotometricInterpretation
    (0028,0006) US [1] # 2 1 PlanarConfiguration
    (0028,0010) US [480] # 2 1 Rows
    (0028,0011) US [640] # 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 [00] # 2 1
    LossyImageCompression
    (7fe0,0010) OW [00\00\00....] # 307200 1 PixelData

    -carlos


+ Reply to Thread