Compression - Correct implementation of RGB channel decorrelation

Author

Correct implementation of RGB channel decorrelation

LiloLilo

2008-02-24, 7:56 am

Hello,

I need to implement channel decorrelation of a 24bit RGB image, in the
format (G, R-G, B-G).
Because of each channel is 8 bit wide, R-G and B-G would require 9 bit each
because of the sign. Is this the correct way to implement channel
decorrelation? What about the use of only 8 bit, for example:

R = 10 G = 20 => R-G = 245

Thank you all for help

Jean-Pierre Vial

2008-02-24, 6:56 pm

LiloLilo wrote:
> Hello,
>
> I need to implement channel decorrelation of a 24bit RGB image, in the
> format (G, R-G, B-G).
this is just a change of coding, there will be essentially as much
correlation in the new format as there was in the RGB format.

In this line why not use a standard coding such as HSV which is
known in most graphical software libraries ?

Thomas Richter

2008-02-24, 6:56 pm

LiloLilo schrieb:
> Hello,
>
> I need to implement channel decorrelation of a 24bit RGB image, in the
> format (G, R-G, B-G).
> Because of each channel is 8 bit wide, R-G and B-G would require 9 bit each
> because of the sign.

Yes.

> Is this the correct way to implement channel
> decorrelation?

Probably. What are your objectives? Lossy? Lossless?

What's the problem with YCbCr? Or probably with the RCT in
JPEG2000, if you need a reversible transform?

Greetings,
Thomas

LiloLilo

2008-02-24, 6:56 pm

> Probably. What are your objectives? Lossy? Lossless?

Lossless

> What's the problem with YCbCr? Or probably with the RCT in
> JPEG2000, if you need a reversible transform?

I need channel decorrelation as first step of an image compression algorithm
to help improve compression.
I need a color decorrelation step wich is fast, lossless and easy to
implement. Also patent free.

Thanks

Thomas Richter

2008-02-25, 3:57 am

LiloLilo schrieb:
>
> Lossless
>
>
> I need channel decorrelation as first step of an image compression algorithm
> to help improve compression.
> I need a color decorrelation step wich is fast, lossless and easy to
> implement. Also patent free.

I don't remember whether the RCT was patent free or not, but it's at least trivial
enough. But, yes, it will also expand the range of the chrominance components. It's
something your code must be able to handle. You can also try a lifting based implementation
of the YCbCr transformation with fix-point precision. Will of course also expand the
bitrange.

So long,
Thomas

Stefano Brocchi

2008-02-25, 7:56 am

Hello,

> I need channel decorrelation as first step of an image compression algorithm
> to help improve compression.

I've looked for something like that too some time ago, and one of the
most interesting things I've found is this article that presents an
effective and simple color transform:

http://research.microsoft.com/~malv.../JVT-I014r3.pdf

I don't know if this is patent-free though...

Hope this helped,
Stefano

danilobrambilla@tiscali.it

2008-02-25, 6:57 pm

Thank you all for help. I'll evaluate all your suggestions.
By the way, I still have some dubt about (R-G, G, B-G).
As said above, having 8 bit channels R-G and B-G would require 9 bits.
Also, they will have negative values.
So, how can manage negatives? Do you think the following c macro would
be a good solution?

#define REMAP(Data) ((Data) < 0 ? ((- (Data)) << 1) - 1 : (Data) << 1)

aka if Data < 0 then change it in ((- Data) * 2) - 1 else Data * 2

this would remap every value in a positive order like: 0, -1, 1, -2,
2,

What is the usual way to compute (R-G, G, B-G) if different from the
above?

Thank you

Stefano Brocchi

2008-02-25, 6:57 pm

> As said above, having 8 bit channels R-G and B-G would require 9 bits.
> So, how can manage negatives?

Having 9-bit samples is quite typical in these cases, some transforms
even obtain 10 bit channels. Anyway in the case of G, R-G and B-G you
should be able to use the remainder of the division by 256 to keep
values in the 0-255 interval, but as it has been suggested the
drawback could be that the decorrelation is less effective than with
other transforms.

If you do not expect some particular values in the next phases of the
algorithm, a remapping will not help: characteristics of the image as
enthropy and variance would not change.

So long,
Stefano

Thomas Richter

2008-02-25, 6:57 pm

Stefano Brocchi wrote:
> Hello,
>
>
> I've looked for something like that too some time ago, and one of the
> most interesting things I've found is this article that presents an
> effective and simple color transform:
>
> http://research.microsoft.com/~malv.../JVT-I014r3.pdf
>
> I don't know if this is patent-free though...

If this is the HDPhoto YCbCo transform, no, it's not patent-free.

MS granted patent rights for ISO use, i.e. on a licence fee free basis,
in conjunction with the HDPhoto/JPEG-XR standardization effort. Which
means, if you want to use it outside of the ISO, you would still need
a license from MS.

I cannot comment on the efficiency of the YCbCo transformation as I
haven't tried, but it's surely better than compressing in RGB space.

So long,
Thomas

Thomas Richter

2008-02-25, 6:57 pm

danilobrambilla@tiscali.it wrote:
> Thank you all for help. I'll evaluate all your suggestions.
> By the way, I still have some dubt about (R-G, G, B-G).
> As said above, having 8 bit channels R-G and B-G would require 9 bits.
> Also, they will have negative values.
> So, how can manage negatives?

It's probably a good idea to run a level-shift in first place, i.e. make
samples symmetric in first place. The proper question should rather be,
"how to handle unsigned values". (-:

> Do you think the following c macro would
> be a good solution?

Moving the sign bit into bit 0? Probably, but not the most canonical one
as any loss in the compression (should you introduce loss in one way or
another) destroys the sign bit first. A more typical solution is to
consider a transform that handles signed data (consider, the output of
all popular image transforms is signed by nature, DCT, DWT, etc...) and
to level-shift the input data such that it is symmetric.

> What is the usual way to compute (R-G, G, B-G) if different from the
> above?

The usual way is to deal with signed input and with input of any
magnitude anyhow, so there is usually no problem with this problem. (-:

So long,
Thomas

cr88192

2008-02-25, 6:57 pm

"LiloLilo" <danilobrambilla@tiscali.it> wrote in message
news:47c16478$0$21198$5fc30a8@news.tiscali.it...
> Hello,
>
> I need to implement channel decorrelation of a 24bit RGB image, in the
> format (G, R-G, B-G).
> Because of each channel is 8 bit wide, R-G and B-G would require 9 bit
> each because of the sign. Is this the correct way to implement channel
> decorrelation? What about the use of only 8 bit, for example:
>
> R = 10 G = 20 => R-G = 245
>

this, combined with truncating to 8 bits is a common approach (at least for
lossless codecs).
most lossy codecs, however, prefer YCbCr or some similar system.

for the inverse transform, the output is similarly truncated to 8 bits.

I have before implemented very simplistic image compressors that work this
way:
split image into G, R-G, and B-G planes;
use filter to reduce all of the pixels to differences;
use RLE or RLE+Entropy coding to squeeze down the image.

there are two major kinds of filtering that are possible.

linear filtering of the form:
A B
C P

where P=C+B-A
the value to be encoded being X=D-P

linear horizontal and vertical filtering (we move horizontally and calc
differences, and then vertically calculating differences).

both approaches are more or less equivalent AFAIK.

for many kinds of images, most of the values are 0s (or runs of other small
values), so even plain old RLE will often work well (note that for bytewise
RLE, the RLE scheme should use an "unusual" range of values for runs, such
as 112 to 143 or similar). I had typically had good success with
"last-value" RLE, where a run simply indicates how many times to repeat the
last value. special cases may be needed for longer runs and for range
clashes, such as 112=extra long run (could have an extra byte as a length),
113=escaped byte, 114..143=runs of 2..31 bytes.

RLE+Entropy coding is better, however...

examples would include Rice coding with a special escape for RLE runs (in
schemes where I have done this, I have often left a hole for "-0" or
similar, and used this to encode RLE runs). usually in this scheme, the
bytes are regarded as signed.

in many cases, all this can pull off results that may compress almost as
good as PNG, but at a much lower complexity (aka: good for a special purpose
codec for embedding images in some other format).

however, there are some kinds of images (such as screen shots, or other
images with a lot of repetitive details, such as text, ...) where PNG is
clearly better (in my case, formats like this are often used for cachine
lightmap data or "pre-rendered" imagery, such as for reflection-mapping or
similar...).

> Thank you all for help
>

cr88192

2008-02-25, 6:57 pm

"Thomas Richter" <thor@math.tu-berlin.de> wrote in message
news:fptrvi$ne4$1@infosun2.rus.uni-stuttgart.de...
> LiloLilo schrieb:
>
> I don't remember whether the RCT was patent free or not, but it's at least
> trivial
> enough. But, yes, it will also expand the range of the chrominance
> components. It's
> something your code must be able to handle. You can also try a lifting
> based implementation
> of the YCbCr transformation with fix-point precision. Will of course also
> expand the
> bitrange.
>

dunno much about RCT.

I am not sure if YCbCr can be made lossless...

also, what YCbCr primarily offers (preservation of perceptual color accuracy
in the fast of loss), is not of much use for lossless compression anyways.

additionally, YCbCr is not always the "best fit" anyways (for example, for
those of us who are partly colorblind, and live with the constant experience
that computer-based images always look "off" compared with anything that
exists IRL anyways...).

the original idea, (G, R-G, B-G), though not theoretically ideal, is very
easy to make lossless, and IME works fairly well in practice...

> So long,
> Thomas

Sponsored Links