Newsgroups: sci.image.processing
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!udel!gatech!swrinde!cs.utexas.edu!howland.reston.ans.net!ix.netcom.com!netcom.com!tgl
From: tgl@netcom.com (Tom Lane)
Subject: Re: lossless integer RGB <-> YCbCr ???
Message-ID: <TGL.95Mar19210837@netcom22.netcom.com>
Sender: tgl@netcom22.netcom.com
Organization: Netcom Online Communications Services
References: <3kfjg8$rh3@hpsystem1.informatik.tu-muenchen.de>
Date: Mon, 20 Mar 1995 05:08:37 GMT
Lines: 30

paula@sgizenger2.informatik.tu-muenchen.de (Andreas Paul) writes:
> I'm looking for a lossless integer conversion between the RGB and YCbCr
> colorspaces.
> I have integer RGB-values ranging between 0 and 255.  I want to convert them
> to integer YCbCr-values with values in the ranges 0-255 (Y) and -127 to
> 127 (CbCr).
> Trying to do this with the factors I found in the Colorspace-FAQ (great
> document by the way) leads to differences between the original RGB-values
> and the values after the conversion to YCbCr and back.

Yup.  The above transformation *cannot* be lossless with integer arithmetic,
because there aren't enough YCbCr values.  The RGB cube transforms to a
tilted, skewed cube in YCbCr space; this shape is only about a quarter of the
volume in the YCbCr cube [0..255,0..255,0..255].  So if you round your YCbCr
results to integers, you lose information.  There aren't enough "legal"
(physically realizable) integer-valued YCbCr colors to have one for each
integer-valued RGB color.

> If the RGB- and YCbCr-values are floats and rint() is used, input and output
> RGB-values are identical.

Not surprising; you're keeping more than 8 bits of precision in the YCbCr
values.

I believe it takes 10 or 11 bits of precision in the YCbCr values to be able
to convert 8-bit RGB losslessly.  You can think of this as 8-bit YCbCr with a
couple of fractional bits added, if you like.

			regards, tom lane
			organizer, Independent JPEG Group
