Can Uncompressed LITTLEENDIAN IMPLICIT image has photometric interpretation of YBR_FULL? - DICOM

This is a discussion on Can Uncompressed LITTLEENDIAN IMPLICIT image has photometric interpretation of YBR_FULL? - DICOM ; Hello: I have an image Uncompressed LITTLEENDIAN IMPLICIT image that has photometric interpretation of YBR_FULL. The DICOM Standard seems to imply that YBR FULL is associated with RLE. But it does not say if an image is uncompressed LITTLEENDIAN IMPLICIT ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Can Uncompressed LITTLEENDIAN IMPLICIT image has photometric interpretation of YBR_FULL?

  1. Can Uncompressed LITTLEENDIAN IMPLICIT image has photometric interpretation of YBR_FULL?

    Hello:

    I have an image Uncompressed LITTLEENDIAN IMPLICIT image that has
    photometric interpretation of YBR_FULL.

    The DICOM Standard seems to imply that YBR FULL is associated with
    RLE. But it does not say if an image is uncompressed LITTLEENDIAN
    IMPLICIT it cannot be YBR_FULL.

    So is the image Photometric interpretation correct if the image is YBR
    FULL and is uncompressed?

    2. Those characteristics not implied by the definition of the
    compression scheme (e.g. always color-by-plane in RLE), can therefore
    be determined from the DICOM Data Element in the enclosing data set.
    For example a Photometric Intepretation of "YBR FULL" would describe
    the color space that is commonly used to losslessly compress images
    using RLE.

    Thanks

    Wayne Tran


  2. Re: Can Uncompressed LITTLEENDIAN IMPLICIT image has photometricinterpretation of YBR_FULL?

    Hi Wayne

    There are some compression transfer syntaxes that require the use
    of specific photometric interpretations, but the converse is
    not true, although the IOD may constrain the definition.

    So, yes, an uncompressed transfer syntax can be YBR_FULL for some
    transfer syntaxes, and although this may be unusual and/or pointless,
    one does see images of this form from time to time, probably from an
    ultrasound device.

    And yes, the DICOM elements specify what is "missing" from the
    definition and/or encoding of the bit stream, such as the color
    space ... this is necessary even for ordinary JPEG, which, contrary
    to popular belief, does not specify the color space in the bitstream
    either, hence the importance of a YBR_FULL_422 (rather than RGB)
    value for Photometric Interpretation in that case.

    David

    enyaw_2010@hotmail.com wrote:
    > Hello:
    >
    > I have an image Uncompressed LITTLEENDIAN IMPLICIT image that has
    > photometric interpretation of YBR_FULL.
    >
    > The DICOM Standard seems to imply that YBR FULL is associated with
    > RLE. But it does not say if an image is uncompressed LITTLEENDIAN
    > IMPLICIT it cannot be YBR_FULL.
    >
    > So is the image Photometric interpretation correct if the image is YBR
    > FULL and is uncompressed?
    >
    > 2. Those characteristics not implied by the definition of the
    > compression scheme (e.g. always color-by-plane in RLE), can therefore
    > be determined from the DICOM Data Element in the enclosing data set.
    > For example a Photometric Intepretation of "YBR FULL" would describe
    > the color space that is commonly used to losslessly compress images
    > using RLE.
    >
    > Thanks
    >
    > Wayne Tran
    >


  3. Re: Can Uncompressed LITTLEENDIAN IMPLICIT image has photometric interpretation of YBR_FULL?

    As an extension to Davids reply,

    > space ... this is necessary even for ordinary JPEG, which, contrary
    > to popular belief, does not specify the color space in the bitstream
    > either, hence the importance of a YBR_FULL_422 (rather than RGB)
    > value for Photometric Interpretation in that case.


    The significant point being that "ordinary JPEG" will be encoded using YCbCr
    hence the requirement that David stated for YBR_FULL_422.

    However, I have in the past encountered several cases where images have
    consisted of RGB components that have been put directly into a JPEG encoder
    without first having been converted to YCbCr but where the manufacturer has
    specified YBR_FULL_422 in the Photometric Interpretation. This causes a
    correctly functioning image application to display images with the colour
    "all messed up" because the application attempts to convert the values from
    YBR_FULL_422 to RGB where they are already RGB.

    I won't name names but they came from a few large vendors ultrasound
    systems.

    HTH

    Ross


    wrote in message
    news:1172538131.927748.131270@j27g2000cwj.googlegr oups.com...
    > Hello:
    >
    > I have an image Uncompressed LITTLEENDIAN IMPLICIT image that has
    > photometric interpretation of YBR_FULL.
    >
    > The DICOM Standard seems to imply that YBR FULL is associated with
    > RLE. But it does not say if an image is uncompressed LITTLEENDIAN
    > IMPLICIT it cannot be YBR_FULL.
    >
    > So is the image Photometric interpretation correct if the image is YBR
    > FULL and is uncompressed?
    >
    > 2. Those characteristics not implied by the definition of the
    > compression scheme (e.g. always color-by-plane in RLE), can therefore
    > be determined from the DICOM Data Element in the enclosing data set.
    > For example a Photometric Intepretation of "YBR FULL" would describe
    > the color space that is commonly used to losslessly compress images
    > using RLE.
    >
    > Thanks
    >
    > Wayne Tran
    >




  4. Re: Can Uncompressed LITTLEENDIAN IMPLICIT image has photometricinterpretation of YBR_FULL?

    To add to David Clunie's comments:
    > There are some compression transfer syntaxes that require the use
    > of specific photometric interpretations, but the converse is
    > not true, although the IOD may constrain the definition.
    >
    > So, yes, an uncompressed transfer syntax can be YBR_FULL for some
    > transfer syntaxes, and although this may be unusual and/or pointless,
    > one does see images of this form from time to time, probably from an
    > ultrasound device.


    It should be noted, however, that certain photometric interpretations
    cannot be safely used with uncompressed images. One example is YBR_FULL_422
    where the padding algorithm for images with an odd number of columns
    is undefined for uncompressed images, other examples are some of the photometric
    interpretations used with JPEG 2000 compression, in particular YBR_RCT which
    requires a different number of bits per sample for the different channels,
    and that cannot be represented in uncompressed DICOM.

    The use of YBR_FULL with uncompressed images, however, is perfectly well-defined
    and might actually be useful when images originating in YCbCr color model
    (for example, digitized video) is converted to DICOM secondary capture -
    a conversion to RGB would be a lossy transformation step in this case.

    Regards,
    Marco Eichelberg
    OFFIS


  5. Screwed up JPEG Photometric Interpretation, was Re: Can UncompressedLITTLEENDIAN IMPLICIT image has photometric interpretation of YBR_FULL?

    Hi Ross

    Ross wrote:

    > The significant point being that "ordinary JPEG" will be encoded using YCbCr
    > hence the requirement that David stated for YBR_FULL_422.
    >
    > However, I have in the past encountered several cases where images have
    > consisted of RGB components that have been put directly into a JPEG encoder
    > without first having been converted to YCbCr but where the manufacturer has
    > specified YBR_FULL_422 in the Photometric Interpretation. This causes a
    > correctly functioning image application to display images with the colour
    > "all messed up" because the application attempts to convert the values from
    > YBR_FULL_422 to RGB where they are already RGB.


    Unfortunately there is no way to detect the case that you describe, since
    it would hardly be practical to assume that the JPEG bitstream was RGB
    in the general case, is there ?

    I find that the converse situation occurs more commonly,
    folks claiming RGB Photometric Interpretation when they send the JPEG
    components as YCbCr, assuming that the codec always does the color space
    transformation as well, in the same manner as normal consumers
    experience with JPEG codecs.

    It is difficult to produce a general purpose display application that will
    tolerate both a standard compliant image and a buggy image.

    I.e. one always has to either assume (when there are three components):

    - that the standard is being followed (bitstream color space is specified
    by Photometric Interpretation)

    - the standard is being ignored (bitstream color space is always YCbCr)
    regardless of what is in Photometric Interpretation

    Frankly, since there is little value in encoding RGB components as
    JPEG, I see a lot of folks doing the latter, and I tend to assume
    it myself when writing display code since it results in fewer screwed
    up colors as far as the user is concerned. It is also the default
    behavior of most codecs to perform the color space transformation
    so it is what folks will get if they ignore or are unaware of this
    issue.

    The only way to do better as far as I know is to key off specific
    patterns of manufacturer, model and version tags, which is tedious,
    or possibly to go looking for the JFIF header if one is present (it
    isn't supposed to be per the standard, but since it is in an APP0
    marker segment it is a comment and is harmless and in some codec
    implementations you have to work to get rid of it).

    > I won't name names but they came from a few large vendors ultrasound
    > systems.


    Actually please do name names, as well as specific models and versions,
    since that would be helpful to us all so we can all code around the
    problem.

    David

    PS. For those interested in checking the images they have, some time
    back I added to my dciodvfy tool a check to flag an error if the
    Photometric Interpretation did not match the expected set that are
    used for specific transfer syntaxes, e.g., of the form:

    Condition="JPEGTransferSyntaxAndThreeSamples" StringEnumValues="PhotometricInterpretationYBRFull422"
    Condition="JPEG2000LosslessTransferSyntaxAndThreeSamples" StringEnumValues="PhotometricInterpretationYBRRCT"
    Condition="JPEG2000TransferSyntaxAndThreeSamples" StringEnumValues="PhotometricInterpretationYBRRCTOrICT"
    Condition="MPEGTransferSyntax" StringEnumValues="PhotometricInterpretationYBRPartial420"
    Condition="RLETransferSyntaxAndThreeSamples" StringEnumValues="PhotometricInterpretationYBRFull"

    Whilst this is more strict than the standard I find it useful to
    give me warning, since chances are the vendor has screwed up and
    the Photometric Interpretation does not match the bitstream,
    rather than genuinely having tried to send a weird encoding but
    properly described. Even in the latter case I like to know
    when someone is doing something weird, since it will inevitably
    cause display problems.

  6. Re: Screwed up JPEG Photometric Interpretation, was Re: Can Uncompressed LITTLEENDIAN IMPLICIT image has photometric interpretation of YBR_FULL?


    "David Clunie" wrote in message
    news:45E583C9.2000704@dclunie.com...
    > Unfortunately there is no way to detect the case that you describe, since
    > it would hardly be practical to assume that the JPEG bitstream was RGB
    > in the general case, is there ?


    Hi David,

    Frustratingly, yes, as you say there is no way to detect this case
    automatically. Nor is there an automatic way to reliably determine if RGB in
    the photometric interpretation really means RGB for a JPEG image - I have
    seen this used deliberately too!!. I'd argue that it's fairly pointless
    (perhaps even dangerous if sub-sampling is also used) to compress RGB with
    JPEG lossy processes even though technically it's perfectly valid.

    > It is difficult to produce a general purpose display application that will
    > tolerate both a standard compliant image and a buggy image.


    I agree, and in fact I've spent a lot of time in the past adding switches to
    applications I've worked on to allow them to be configured to load faulty
    images such that they can then be stored correctly (and the switch
    disabled) - this of course requires manual intervention again tedious at
    best.

    > Actually please do name names, as well as specific models and versions,


    I don't have the information to hand right now I may well post it up if I
    can dig it out.

    Cheers

    Ross




+ Reply to Thread