Compression - Please help on lossy and loss less compression in JPEG2000

Author

Please help on lossy and loss less compression in JPEG2000

hswnetin

2005-03-24, 8:55 am

Hi All,

This is w.r.t. my previous mail with subject “Please help us in
understanding motion JPEG2000”. I have basic doubt on JPEG2000. My
understanding on lossy and loss less compression is, the difference
between the original image and the reconstructed image from JPEG2000
stream should be zero in ideal case.

Case 1:
I will use the filter coefficient for lossy and loss less hardware
separately. I use the same image to pass through. If I am right there
is definitely difference between the lossy and the loss less image.
How the loss is introduced in the lossy JPEG2000 stream? Also in case
loss is introduced only by the filter coefficients, why one should go
for lossy compression instead of loss less compression?

Case 2:
The suggestions from the group for achieving the speed and hardware,
we need not code all the bit planes. I agree with the input
suggestion. I will use this new hardware, which codes only the
required bit planes. Assume in our case we use 8-bit planes out of
16-bit planes. The error introduced at the input itself. The
percentage of error introduced is calculated as follows.

16-bits, max value = 2^16 = 65536.
8-bits, max value = 2^8 = 256.

Maximum percentage of error introduced = ((256)/65536)*100 = 0.390625
%. At the input itself image is 0.390625 % erroneous. Even use of
loss less compression will not give 100 % accurate image. In this
case, is the compression is considered lossy? Or can I go ahead with
the input error 0.390625 %? Which will save my lot of hardware and
time.

We are targeting the video and medical applications, we are planning
to use 4-bits out of 16-bits. The percentage of error introduced is
as given.

16-bits, max value = 2^16 = 65536.
12-bits, max value = 2^12 = 4096.

Maximum percentage of error introduced = ((4096)/65536)*100 = 6.25 %.

Is this error acceptable in video and medical applications? I
personally feel this error is acceptable, human eye may not recognize
this error.

Please help us about the real time scenario.

Thanks and regards,
hswnetin

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

Thomas Richter

2005-03-24, 3:55 pm

Hi,

> This is w.r.t. my previous mail with subject ?Please help us in
> understanding motion JPEG2000?. I have basic doubt on JPEG2000. My
> understanding on lossy and loss less compression is, the difference
> between the original image and the reconstructed image from JPEG2000
> stream should be zero in ideal case.

For lossless: The difference between original and reconstructed is
zero (unless your codec is broken).

For lossy: Given an output file size(!), a coder shall try to minimize
the mean square difference between original and reconstructed image.
That is, the quality (as defined by PSNR) is minimized for a given
side condition. In other words: You define how large the image
shall be, and the codec tries to introduce the least amount of
errors such that the compressed image still fits into this size.
There's no problem getting a 1:2000 compression ratio - just the
reconstructed image will look desasterously. (-;

> Case 1:
> I will use the filter coefficient for lossy and loss less hardware
> separately. I use the same image to pass through. If I am right there
> is definitely difference between the lossy and the loss less image.

I don't quite understand the question, sorry. The basic difference
between lossy and lossless is a) there is no quantization for
lossless, and b) lossless uses a different wavelet (namely, one
that allows an integer lifting).

> How the loss is introduced in the lossy JPEG2000 stream?

a) Explicitly by quantizing the wavelet coefficients; once by
the (pre-)quantizer, and furthermore by not encoding all bitplanes
in the EBCOT entropy coder.
b) Additionally, due to numerical loss while performing the 9/7
wavelet filter (which is not applicable for an integer lifting).

> Also in case loss is introduced only by the filter coefficients,
> why one should go for lossy compression instead of loss less
> compression?

Because of the compression ratio. Lossless guarantees to reconstruct
the image pixelwise identically. There is a lot of rate required
for that. For lossy compression, the coder does not attempt this,
but rather tries to find an image that contains the least error for
a given compression ratio. You won't get much better than 1:4 with
lossless, but depending on the image size, type and quality, you
can go up to 1:100 for lossless.

> Case 2:
> The suggestions from the group for achieving the speed and hardware,
> we need not code all the bit planes. I agree with the input
> suggestion. I will use this new hardware, which codes only the
> required bit planes. Assume in our case we use 8-bit planes out of
> 16-bit planes.

Do not cut bitplanes at the input; this will affect the (visual and
mean square) error much more than performing a rougher quantization.
Cut bitplanes at the EBCOT, which is the major speed brake. Whether
you do wavelet transformation with 4 bits or 16 bits typically
makes no difference - there is no fast 4 bit arithmetic on modern
machines either. (-;

> The error introduced at the input itself. The
> percentage of error introduced is calculated as follows.

> 16-bits, max value = 2^16 = 65536.
> 8-bits, max value = 2^8 = 256.

> Maximum percentage of error introduced = ((256)/65536)*100 = 0.390625
> %. At the input itself image is 0.390625 % erroneous.

Easier. Quantizer's rule of thumb: 6dB error per dropped bit. According
to this rule, you come to a maximum quality of 96dB for 16bpp and
48dB for 8bpp. Thus, in worst case, you lose 48dB. If your target
quality is around 35dB (visually lossy, but acceptable), it doesn't
make much difference whether the original image had 48dB or 96dB
quality.

> Even use of
> loss less compression will not give 100 % accurate image. In this
> case, is the compression is considered lossy?

Yes. But you introduced the loss in a very suboptimal way. Dropping
bits in the image domain will of course "compress" the image. But
the visual error will be much larger than dropping bits of the wavelet
coefficients. The whole idea of transform coding (DCT as in JPEG or
DWT as in JPEG2000) is to transform the image into a domain where
errors have less visual impact than in the original domain.

> Or can I go ahead with
> the input error 0.390625 %? Which will save my lot of hardware and
> time.

All this depends on the quality you want to archive, the hardware
you've available, the frame rate you're targetting at and the image
sizes you want to compress. There is no general answer.

> We are targeting the video and medical applications, we are planning
> to use 4-bits out of 16-bits. The percentage of error introduced is
> as given.

Medical images require typically at least 12bpp, today even 16bpp.
This rules 4bpp in the image domain out, definitely. You should
provide at least a quality of around 40..50dB.

> 16-bits, max value = 2^16 = 65536.
> 12-bits, max value = 2^12 = 4096.

> Maximum percentage of error introduced = ((4096)/65536)*100 = 6.25 %.

Ehem. No. What's an error for you? You will notice that these "tiny"
6% difference in the image domain make a *huge* difference. Besides,
one typically understands error as in "mean square error", that
is, compute

MSE = sum_pixels (original_pixel - reconstructed_pixel)^2

Not that this is a very good error measure since it doesn't
correlate well to the visual performance, but it's at least
well accepted.

> Is this error acceptable in video and medical applications?

If you drop these bits in the image domain? No. Not even close.
This is completely unacceptable. If you compress the images down
to 4bpp using a codec (i.e. you drop these bits in the DCT or
wavelet domain) then you're back in business. However, you first
have to transform the image into that domain - that's the idea
how image compression works.

> I personally feel this error is acceptable, human eye may not recognize
> this error.

Try this yourself. Run an image manipulation program (i.e. "gimp"),
remove the low-order bits. You will see the difference, definitely.

> Please help us about the real time scenario.

Without having more information, hardly, I afraid.

So long,
Thomas

Sponsored Links