VR and Endianis of RBG images in DICOM. - DICOM

This is a discussion on VR and Endianis of RBG images in DICOM. - DICOM ; I think there is something wrong with the way RBG images are dealt with in DICOM. It seems to me the VR of an RGB image regardless of endianism should be OB. However it seems to me that because the ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: VR and Endianis of RBG images in DICOM.

  1. VR and Endianis of RBG images in DICOM.

    I think there is something wrong with the way RBG images are dealt
    with in DICOM.
    It seems to me the VR of an RGB image regardless of endianism should
    be OB.
    However it seems to me that because the majority of images are OW that
    images are being treated as OW irregardless of the proposed (implicit)
    VR.

    So what should I do? Should I go with the flow and just store my RGB
    images as word oriented images and set the VR to OW and if necessary
    swap the bytes so that images are no longer stored as rgb,rgb,rgb but
    grr,bbg etc?


  2. Re: VR and Endianis of RBG images in DICOM.

    Hi

    SpreadTooThin wrote:
    > I think there is something wrong with the way RBG images are dealt
    > with in DICOM.
    > It seems to me the VR of an RGB image regardless of endianism should
    > be OB.
    > However it seems to me that because the majority of images are OW that
    > images are being treated as OW irregardless of the proposed (implicit)
    > VR.
    >
    > So what should I do? Should I go with the flow and just store my RGB
    > images as word oriented images and set the VR to OW and if necessary
    > swap the bytes so that images are no longer stored as rgb,rgb,rgb but
    > grr,bbg etc?


    Since the successive samples are packed into each encoded OW
    word from the least significant end, the first sample (e.g.,
    the R of RGB) ends up in the least significant byte.

    Since the little endian transfer syntax specifies that the least
    significant byte (e.g., the R byte) is to be sent first on the
    wire, the net result is that little endian transmission of
    OW sends an identical stream of bytes to transmission of OB.

    In the case of RGB encoded images, this is RGBRGB...

    It is only when a big endian transfer syntax is used to send
    OW RGB data that the byte order on the wire would be GRRBBG...
    and different from OB RGB data in the same transfer syntax.

    See the illustrations in PS 3.5 Figures D-7 and D-8.

    The bottom line though is that it is risky in the general case
    to assume any particular organization of samples without actually
    performing the packing and unpacking operations of samples into
    words or bytes as defined by the standard, and paying attention
    to the implicit or explicit byte ordering of the transfer syntax
    when reading and writing those words. For example, if I am
    reading in OW 8-bit RGB data, I read in an array of shorts (16
    bit values) using a routine that accounts for transfer syntax
    specified byte order and then extracts the first and odd numbered
    bytes from the low half of the short word; only if the VR is
    explicitly OB do I read in an array of bytes irrespective of
    byte order.

    But for any multiple-sample per pixel 8 bits allocated image, the
    encoding order of the samples in OB and little endian OW are the
    same.

    David

    PS. The specific reference in PS 3.5 is section 8.2 para 3, which
    says:

    "Native format Pixel Cells are encoded as the direct concatenation
    of the bits of each Pixel Cell, the least significant bit of each
    Pixel Cell is encoded in the least significant bit of the encoded
    word or byte, immediately followed by the next most significant bit
    of each Pixel Cell in the next most significant bit of the encoded
    word or byte, successively until all bits of the Pixel Cell have
    been encoded, then immediately followed by the least significant
    bit of the next Pixel Cell in the next most significant bit of
    the encoded word or byte."


  3. Re: VR and Endianis of RBG images in DICOM.

    I guess my problem is that my software runs on both little and big
    endian platforms...
    RGB images regardless of the platform are in the correct order...
    My problem comes in understanding if I should byte swap the data if
    I'm writing it to an implicite vr little endian file or stream.


+ Reply to Thread