LuraWave JPEG2000 images are blurry

I've just started using IrfanView's LuraWave JPEG2000 plugin (at
resolutions beyond 640x480) and have noticed serious blurring
artifacts at the "default" setting of 95.

Using the max setting of "100" the files are huge and it still doesn't
look that impressive. Large sections of images look blended like
smooth water, with certain areas in sharp detail. The only super clean
images I get are in the non-lossy mode of JPEG2000, which makes huge
files. The quality is far worse than standard JPEG (even at "80" or
below).

However, before I registered LuraWave to allow JPEG2000 saves beyond
640x480, the images looked quite good. Are their known bugs with the
full version of LuraWave and/or IrfanView's implementation?

K2

 

Forget about JPEG2000 and Wavelet technology!
It is a hoax and is inferior compared with standard DCT JPEG!
Go with standard DCT JPEG - it's fine and the best method
currently available!
There will be advances in the future, but *not* in the JPEG2000
or Wavelet direction, but based on the current DCT JPEG standard.

Regards
Guido

 

Heaven knows what their setting "95" actually means, but there is
something seriously wrong with the codec if you can see any visible
artifacts on a J2k file that was saved at highest quality.

That is odd. Using the (experimental) release of Jasper I found that for
some digicam images the wavelet representation of a raw image was almost
exact. Sharp edge pixels were different but not very many.

There is something wrong then. My experience with Jasper was that J2k
achieved the same quality as JPEG in about 70% of the file size.

Some of the compression improvement being due to it using arithmetic
coding (when does that patent expire?).

I don't know. You could try running the original files through the
(rather tedious) command line interface for Jasper to see how they
compare.

It could be that you have found a pathological case where J2k performs
badly, but on balance I think it more likely you have run into a bug.

Regards,

 

Is this really the case ? Could somebody provide (scientific) evidence to
argue this one way or the other ? I'm interested both in a comparison
between JPEG Baseline and the JPEG2000 standard as well as sinusoidal
transforms vs. wavelets in general. Guido, can you justify you statement
that wavelets will not form the basis of future compression techniques ?

Rahul

 

According to what I've heard the biggest problem is simply that the JPEG2000
standard is not being adopted very widely and is therefore effectively useless,
no matter how good it may or may not be. To start using it on the web for
instance would require that the browsers you target support it, etc.

-dhaley

 

Rahul, Guido does have some very fixed opinions, although he has provided
useful software for the original JPEG standard as well. I would also be
interested in some evidence for his statement.

I have been using a wavelet-based lossless transform in a non-JPEG
application for over a year now, and I have no problems with it.

Cheers,
David

 

Many years of experience with JPEG and the fact that I recently discovered
the most important and previously unknown property of the DCT as used in
standard JPEG have convinced me that the DCT is the best basis for image
compression and superior to the Wavelet techniques.

I consider the Wavelet approach as just an academic and commercial artifact
with no practical advantage and several disadvantages.
I find it rather amusing that those "image compression experts" who pursue
the sophisticated and yet unsuccessful Wavelet approach do not even have
a clue about the basic simple DCT property! They have shown to be
unteachable and ignorant.

There *will be* future advances in image compression, but *not* with
Wavelets, but with the common DCT! The potential of the DCT approach
is currently far from being exploited, because until recently nobody
knew the basic DCT property which makes it ideal for image compression,
even the original JPEG authors didn't know about that and therefore
failed to exploit all opportunities!
With this knowledge it will be possible to introduce important
improvements in image compression with only *slight* modifications
of the current JPEG standard! Furthermore, it will be easy to
maintain compatibility with existing JPEG.

BTW, image blur is the basic property of Wavelet techniques, similar
to the obsolete mosaic sensor technique used in digital photography.
Insofar both techniques might well match for people who like blurry
images. If you look at the current digital camera market you must
think that there are lots of them...

Regards
Guido

 

[]

Guido, thanks for your feedback - are there any references available
online to support your claims?

I have been using lossless wavelet compresssion in a non-JPEG application,
where there is no blurring of the data.

Cheers,
David

 

You wouldn't think that people would start adopting something which is
inferior to what you already have, which does not have a useful advantage,
and which does have several disadvantages.
Oh, sorry, I forgot, the advantage of Wavelet is that some people can
make themselves important, and can earn money from credulous people...

Regards
Guido

 

Many people and I myself experienced the same properties with Wavelets
as described by the original poster. I also remember some web site,
but sorry I'm too lazy to dig it out now.

You can find some of my findings in a paper for the German Color Group:

http://kb-bmts.rz.tu-ilmenau.de/gcg/GCGMAT1.HTM

or with additional material here:

http://jpegclub.org/temp/

Well, as far as I remember, you are also one of the folks who still
accept the blurry images of current mosaic sensor cameras.
So, as said, this is a good match.
But not for me, because for me the digital images from cameras with
mosaic sensor are too blurry to be acceptable.

Regards
Guido

 

[]

Thanks for those references.

The images I am referring to:

(a) are not from digital cameras, but from satellite images

(b) are losslessly compressed, so no blurring is involved. The output
data is identical to the input data. The transform process is purely used
to reduce the bandwidth required for image transmission.

Please withdraw your remarks, which I find insulting and clearly
irrelevant to the points I raised.

David

 

There are other lossless compression schemes which work at lest as good,
if not better, than lossless wavelets.
Even with plain standard DCT JPEG I can get good lossless compression.

Sorry, couldn't resist - you must have some fat skin when debating with me...

Regards
Guido

 

[]

Apology accepted!

By the way "a thick skin" would be the normal term.

Fortunately the wavelet transform code I needed for this project was
supplied free-of-charge, so no extra cost was involved. In this case, the
data is 10 bits deep, so using the 12-bit JPEG word length may have meant
that the file sizes were not quite as compact as the 10-bit wavelet coded
files. Lossless coding was essential.

Cheers,
David

 

Thanks, I'm learning...

Well, the original JPEG standard supports up to 16 bits per component
in the lossless coding mode. It should be quite effective especially
with the arithmetic entropy coding back-end. Perhaps you could also
use the "point transform" feature to support 10 or 12 bits better.
There are several options.

But I was rather thinking about my recent extensions in the common
*DCT* JPEG mode which also allow for lossless coding!
(See comments on http://jpegclub.org/cjpeg/)
I have performed few experiments, and the efficiency seemed quite
good, at least noticeably outperforming compressed TIFF and PNG.

Regards
Guido

 

[]

If the word length can be kept to 10 bits internally, then DCT lossless
JPEG might be acceptable for this application, but if the word length is
12 or 16 bits then any consequent increase in file size might render it
unsuitable.

The project I am referring to has already fixed on using wavelet
transforms, but if you are interested I could send you a 12MB zipped PGM
version of a sample image (3712 x 3712 x 10 bit greyscale).

Cheers,
David

 

The correct scientific comparison here is to use your eyes. I have a
visual comparison of baseline JPEG and JPEG2k artifacts at
http://www.ailab.si/aleks/jpeg/artifacts.htm

Indeed, blurring is the worst JPEG2000 artifact, apart from ringing.

Aleks

 

I have only experimented in the 8-bit mode.
The Independent JPEG Group software is supposed to also work
in 12-bit mode when compiled appropriately, but I haven't
tried that. For the mentioned lossless application it
should work with no problem because the pixels are then
directly treated as DCs and no further 'real' DCT is done
(just 1x1 with the DC which is just some scaling/quantization).

The 10-bit case could be handled by an appropriate quantization
factor, or by point-transforming in progressive mode (shifting
by 2 and omitting the lower bit scans altogether). Something
like the latter is also what I've done in my experiments to
get the desired performance gain: coding just the DCs in a
progressive mode scan and omitting the (all-zero) AC scans
altogether (otherwise the EOB code in each block after the
DC with all-zero ACs in sequential mode would noticeably
drop the performance).

This is all in experimental state, I plan to perform more
investigations later. You could keep your sample image
for request later...

Regards
Guido

 

[]

Yes, I should always have something available, as I get the raw data all
the time (a continuous satellite data stream averaging 1.1Mb/s).

Cheers,
David

 

Pray tell, what defines your limits of "acceptable"?

 

How can you say that without knowing anything about the data that David
works with, *or* the wavelet-based algorithm that he uses?

So far, this isn't much of a debate. You made a sweeping statement, and
David pointed out that it is wrong at least in the domain where he
works. So your statement is incorrect.

You might be able to fix your statement by qualifying what sort of
wavelet algorithm you were talking about (just JPEG2000?) and what sort
of images you tested on, and how you determined whether an image is "too
blurry" or not. Then it might become a debate.

Dave