Photometric Interpretation
grego...@yahoo.com
Those characteristics not explicitly specified in the compressed data
stream (e.g. color space which is
not specified in the JPEG Interchange Format), or implied by the
definition of the compression scheme
(e.g. always unsigned in JPEG), can therefore be determined from the
DICOM Data Element in the
enclosing data set.
According to this, (0028,0004) describes the color space of the
compressed data stream. So what describes the color space of the
uncompressed data stream?
ClearCanvas Workstation 1.3 interprets the lossless decoded color
space based upon this tag, but it implies that lossy decoded color
space is RGB. Isn't one of these wrong?
As I contemplate the issue further, I come to the conclusion that what
is wrong is simply a lack of information within the data set. There is
no information to say what color space the original pixels are to be
placed in. And if there were, would it be enough? Could you transform
the color space, encode, and repeat several time, meaning you could
have multiple color spaces in the chain? (Not that one would, but for
completeness this would need to be addressed).
It seems that (0028,0004) should have multiple color spaces that
indicate at the very least "before" and "after" color spaces, such as
"RGB,YBR_FULL".
Or am I missing something.
David Clunie
> Part 5, 8.2.1 notes (2):
>
> Those characteristics not explicitly specified in the compressed data
> stream (e.g. color space which is
> not specified in the JPEG Interchange Format), or implied by the
> definition of the compression scheme
> (e.g. always unsigned in JPEG), can therefore be determined from the
> DICOM Data Element in the
> enclosing data set.
>
> According to this, (0028,0004) describes the color space of the
> compressed data stream. So what describes the color space of the
> uncompressed data stream?
Nothing in the standard !
> ClearCanvas Workstation 1.3 interprets the lossless decoded color
> space based upon this tag, but it implies that lossy decoded color
> space is RGB. Isn't one of these wrong?
>
> As I contemplate the issue further, I come to the conclusion that what
> is wrong is simply a lack of information within the data set. There is
> no information to say what color space the original pixels are to be
> placed in.
No there isn't, and nor does there need to be.
> And if there were, would it be enough? Could you transform
> the color space, encode, and repeat several time, meaning you could
> have multiple color spaces in the chain? (Not that one would, but for
> completeness this would need to be addressed).
You can do whatever you like ... the standard describes only what it
transmitted.
> It seems that (0028,0004) should have multiple color spaces that
> indicate at the very least "before" and "after" color spaces, such as
> "RGB,YBR_FULL".
>
> Or am I missing something.
Yes, you are missing something fundamental.
A DICOM image instance is encoded as described, e.g., JPEG lossy
compressed and YBR_FULL_422.
DICOM does not describe what the color space was "before compression"
if there every was such a state.
DICOM does not define what you do with it when you decompress it !
That is entirely up to the receiving application; i.e., your codec
might decode it into RGB and the application display it as RGB, or
your codec and application might make it CMYK and print it; the
standard doesn't dictate the recipients behavior.
Now you may say that for multi-channel lossless compression when there
is a color space transformation it might affect the lossless nature of
the compression and you would be correct.
This is why you cannot use JPEG lossless compression with a color
space transformation. I.e., if you send an RGB image as JPEG lossless,
you must not do the color space transformation to YBR_FULL_422, since
that involves both loss in the YCbCr calculations and downsampling of
the chrominance channels. JPEG 2000 has a reversible color
transformation for that reason, but again, if you send a lossless JPEG
2000 YBR_RCT compressed DICOM image, the standard does not define what
color space you decompress it into.
I mention this distinction between lossless and lossy because that may
be the reason for the behavior you are seeing in ClearCanvas, but
regardless, the DICOM Photometric Interpretation element defines only
what is encoded, no more, and no less.
David
grego...@yahoo.com
So you are saying that if 0028,0004 says YBR_FULL_422, then it is
stating the color space of the compressed image. If I decompress it,
it is still in YBR color space AND I can change it to RGB if I would
like?
This makes a lot of sense now.
gunterze
It depends on your JPEG decoder: It's quite common, that JPEG Lossy
decoder transfer the decoded pixel values from YBR_FULL_422 to RGB
during decompression.
gunter