after having read the funny and entertaining thread about JPEG2000 from the
weekend here are some observations of mine on this "future" image file format.
I will try to give some facts and avoid too much rants and rambling, but let's
see.
Some weeks ago I did implement a JPEG2000/J2K decoder/encoder and did
a lot of research on this topic, so I hope to be qualified to do some rant about
all this...

First about the claim of the superior image quality of J2K compared to the
conventional jpeg DCT encoding. Well, I would say it depends. For highly
compressed images (with a ratio of lets say 1:80) it is definitely true. While
JPG consists only of the well known ugly block artefacts, J2K gives a smooth
but blurry image that is much more pleasant to the eye. But for less compressed
images, when image quality is the main issue, the file size will be quite the
same and it simply depends on the kind of image and it is also a matter of
personal taste.
Imagine a picture with a smooth sky gradient and some small wires in the
foreground. JPG will introduce some artefacts (and color banding) in the sky but
J2K will tend to blur out the wires and make them vanish - so anyway, a loss of
information is a loss of information.
In my opinion, the impression of getting a better image quality with JPEG2000 is
mostly the result of the advertising of some commercial companies to point out
the neccessarity of purchasing their product (library, plugin or whatever).

But there is also the possibility of using lossless compression with JPEG2000
and this gives in most cases a much better compression ratio than e.g. PNG's
zlib compression and it beats LZW (as used by e.g. TIFF) all the time. So here
goes a clear point to JPEG2000. And I think it is also quite nice to use one
file format that allows both, lossless and adjustable lossy compression,
depending on your needs.

Another issue is: JPEG2000 can be streamed. This means (well, this would
mean, in case your browser would support the format) you can view the complete
image immediately at low quality and the quality does successive increase while
downloading the image. Nice feature, sure. Especially for slow connections
and/or huge images. But remember this is also possible with progressive
encoded jpeg files but IE downloads first the complete image until it displays
something, with non progressive jpeg's it shows them at least line by line.
Firebird works meanwhile nicely with progressive jpeg files. How long does jpeg
exist? Not sure, but I guess so about 15 years.

Next point: JPEG2000 supports full colorimetric information stored within the
file. The files posted by IMBJR are an example for this, they include an ICC
profile. Fine, but PNG, JPG and TIFF do support ICC profiles also. The problem
is, very few applications and none of the browsers does make use of this. In
fact, the only application I am aware of is Photoshop.
The Gimp (and the complete linux world)  seems to be completely unaware of
color management issues. :(
But the funniest thing is: Windows includes (since  Windows 95 !!!) a color
management module that would be able to handle ICC profiles. It's called ICM and
was not developed by Microsoft but licenced from Heidelberger Druckmaschinen.
But there is not even a Microsoft application (including IE) that makes any use
of it. I guess the licencing devision did forget to inform the developers about
it, or maybe they used Outlook and the mail got lost ...  enough. And I know
nothing about the Mac.


A defined file format and an ISO standard is fine but of less practical benefit
until it is not really supported by application software, so lets have a look at
the availability and quality of J2K en/decoders, libraries, plugins and the
applications using them.

At first, if you do not want to trust blindly to my words or in case you want to
test the quality of the j2k implementation of your favorite viewer/browser by
yourself here are the official JPEG2000 test files:
http://www.crc.ricoh.com/~gormish/jpeg2000conformance/j2kp4files_v1_4.zip
but be warned, 50MB !
It is so big because it contains also uncompressed TIF files as a reference.
Note: These are only the files that are currently available to the public, there
are more but due to some copyright issues you need to be a registered
developer to access them.

(BTW, Thorsten or anybody else who uses a Mac, I would be very interested to
hear something about the QuickTime J2K implementation: how many test
images are correctly displayed and wich of them?)

There is currently only one non-commercial library available called JasPer but
it implements only part 1 of the ISO standard (and in fact only a subset of it).
You can find JasPer (and a list of software that uses this library) here:
http://www.ece.uvic.ca/~mdadams/jasper/
JasPer fails on 4 out of 9 test images.

There is one more a non-commercial j2k-library, http://j2000.org/  but it
implements only the j2k code stream and not the JPEG2000 file format, also
it seems to be in a state of hibernation, so I'm just ignoring it.

Then we have a wide range of commercial libraries. I do not know all of them,
but the company I'm working for did buy 2 of them to check them out and I did
some more tests by playin' with applications where the used library was known.
Well, for short, the result was not very promising, most of them failed also on
3 to 5 images and as these are not alwayws the same they are also quite
incompatible to each other.

In fact, the only one I would recommand is Kakadu at
http://www.kakadusoftware.com/
Kakadu works really fine and fails on 0 out of 9 images. To give you an idea: to
purchase a "freeware-licence", the POV-team would have to pay 550$. The
commercial ones go up to 12000$ which would mean nothing for a company like MS.
And just an observation: Prof. David Taubman, the developer of Kakadu is also
a member of the ISO for JPEG2000 and somehow it seems to me he developed the
library first. And I have also a strange feeling when I think about the fact
that he gets payed by public money but has no problem in selling the product he
has developed at his work (I guess with help of his students). OK, call me old
fashioned.

And just because it seems to be so widely used around here: IrfanView uses the
Luratech plugin (to be more exact the former Luratech now AlgoVision because
Luratech didn't survive) and it also fails on 4 out of 9 images. And (just a
little rambling, I cannot resist) I always was wondering why IrfanView did
become so popular (among the Windozers around here). For sure, it somehow
"displays" all of the images, but some of them with simply plain wrong colors,
and it does this without any warning or notice to the user that there might be a
problem. This does happen also with some TIFF images (especially if they are
not encoded in rgb color space) and even jpeg (cmyk's) and png files (ignoring
the gamma chunck). I never liked this behaviour and I guess some of you have
viewed images with IrvanView without ever realizing that what you see is not
even near the way it should be. Well, enough of that.

Finally my own implementation fails on 0 out of 9 test images but it fails on 4
out of 30 more unusual code streams - so after all it is not so bad :)

Another side note for Torsten: from a programmers point of view, implementing
the DWT is not more sophisticated than a DCT, I have done this also a few years
ago. In fact, en/decoding a J2K code stream is quite streightforeward. The
JPEG2000 file header is just XML so any XML parser will do (and luckily I had
not to write one).


And about the 16bit/8bit per channel color banding controversy. Somehow this
reminds me on people who seem to think a 64bit CPU is twice as fast as a
32bit one. It's not that simple and even color scientists do not share the same
opinion about this (the 16/8bit color I mean, not the CPU ;)  If you are really
interested look e.g. here:
http://www.brucelindbloom.com/DanMargulis.html


All this are just my 2 euro cent and it is quite possibly that some of the
information is already outdated. The time of my research is about 4 months
back and since then I was not much interested in the topic.

Final note: I do not care much about the file format one is posting. I can see
JPEG2000 without problems and I have a fast connection, so everything is fine
for me. But I really doubt the benefit of posting a JP2 file - especially a
16bit/channel one.


so long
-Ive

Post a reply to this message