RLE & RGB to YBR_FULL

[Chuck McCrobie]

Part 5, Section 8.2.2 Note 2 states, in part,

"It is unusual to use an RGB color space for RLE compression, since no
advantage is taken of correlation between the red, green and blue
components (e.g. of luminance), and poor compression is achieved (note
however that the conversion from RGB to YBR FULL is itself lossy. A new
photometric interpretation may be proposed in the future which allows
lossless conversion from RGB and also results in better RLE compression
ratios)."

My question is:

Does this mean if I RLE encode an image and do color space conversion
from RGB to YBR_FULL that I must mark the composite as "Lossy"
(0028,2110) with "01" and make a new SOP Instance UID for the newly RLE
compressed composite?

Does color space conversion make for lossy compression? I understand
that JPEG 2000 has both YBR_ICT for lossy color space conversion and
YBR_RCT for lossless color space conversion. Unforunately, the same
does not apply to RLE does it?

Thanks,

Chuck

[Chuck]

On Mar 23, 9:58 pm, Chuck McCrobie <x...@x.com> wrote:
> Part 5, Section 8.2.2 Note 2 states, in part,
>

> "It is unusual to use an RGB colorspace for RLE compression, since no

Sorry for replying to my own message, but I managed to find this:

http://groups.google.com/group/comp.protocols.dicom/browse_thread/thread/720276384fd28a22/2b1a28dbcd15f448?hl=en&lnk=gst&q=rle+color+conversion+lossy#2b1a28dbcd15f448

In short, it is "recommended" that conversion from YBR_* to RGB be
considered lossy and thus require a new SOP UID and setting the Lossy
and LossyCompressionRatio elements. I would imagine the converse is
true too - going from RGB to YBR_*

David Clunie writes:
> Hi Don
>
> Though the rule requiring a new SOP Instance UID is based
> on changing the "interpretation", I would argue strongly
> that whenever there is a non-lossless transformation of
> the pixel data one should err on the side of changing the
> UID, as in this case, even though the loss is small and
> due to calculation error.
>
> david
>
> PS. I can't imagine anyone would ever use RLE and YBR for
> XA images - surely only for color US.

[Marco Eichelberg]

> Does this mean if I RLE encode an image and do color space conversion
> from RGB to YBR_FULL that I must mark the composite as "Lossy"
> (0028,2110) with "01" and make a new SOP Instance UID for the newly RLE
> compressed composite?

I would recommend this. DICOM requires a new SOP instance UID when a
modification takes place that might have impact on the diagnostic quality
of the image. While the error introduced by RGB to YCrBr color space conversion
is very small, it is probably difficult to estimate the effect on the image,
so marking the image as lossy compressed is the safer approach.

> Does color space conversion make for lossy compression? I understand
> that JPEG 2000 has both YBR_ICT for lossy color space conversion and
> YBR_RCT for lossless color space conversion. Unforunately, the same
> does not apply to RLE does it?

In theory, color space conversion is lossless - the conversion from RGB
to YCbCr is an orthogonal coordinate transform and as such reversible.
The problem is the finite precision of the pixel representation,
which introduces rounding errors - these are responsible for the "loss",
i.e. the irreversible nature of the transformation when used with
integer numbers.

YBR_RCT is a transformation that has been designed specifically as
a color space to which a lossless integer transformation from and to
RGB is possible, at the expense of sacrificing a little bit of compression
efficiency. However, YBR_RCT requires 1 bit/sample more storage space
than the original RGB data if I remember correctly, and as such is
not useable in an uncompressed domain. The transformation is tightly
integrated into JPEG 2000.

Regards,
Marco Eichelberg

[tcl...@ieee.org]

On Mar 26, 5:26 am, Marco Eichelberg <eichelberg_nos...@offis.de>
wrote:

Marco makes many excellent points. The only thing I would take issue
with is the idea that the round-off error from color space conversions
is worth marking as lossy. I should say that I work for an ultrasound
company, and it is certainly possible that some imaging modalities may
run this risk. We find that the differences between one monitor and
the next are vastly more significant than any round-off error that
might be involved in color space conversion. So it is almost dishonest
to suggest in our case that the round-off error could be a problem.
The big concern lies elsewhere. I think the DICOM people were just
getting carried away with this suggestion, if ultrasound is any
inidcation of the real risks that are involved in interpreting
electronic data.

[Chuck McCrobie]

Well, being a simple bit-pusher, I would like to err on the side of
being too careful. I would tend to agree, though, that simply
performing color space conversion _shouldn't_ cause the image to become
lossy...

Now, I have to decide if the design of my conversion utilities should
optimize for inputting uncompressed JPEG Baseline YBR planar
configurations directly into JPEG 2000 codec without a double-blind
color transformation... Ummm, does YUV input to JPEG 2000 count as
lossy or lossless ;)

Thanks for both weighing in - I guess my other message about this
subject still hasn't propagated around the newsgroup.

Chuck