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
>

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
>

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

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.

"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