On Mon, 8 Mar 2004 18:53:14 +0100, "Ive" <ive### [at] lilysoftcom> wrote:

>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

It always does.

>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).

Mmm, must say I don't get that impression. I was under the idea that
it was the Standards group themselves who hark on this.

>
>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.

Must say, I've not played with this yet.

>
>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.

Netscape does the same. I remember when they didn't. I think the
implementer got lazy!

>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. 

As all good modern formats should. Yeah!

>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.

Paint Shop Pro does too. Anyone know of others. Plus, this information
is useful for the purposes of print - I believe (that's an area that
I'm very unfamilar with).

>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.

Everytime I boot up, my monitor dims as the colour profile kicks in.

>
>
>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.

Thanks for the heads on on that. I was not aware it was a problem.

>
>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

I know. There's no firm answer on this - I just go with what I have
personally experienced.

>
>
>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.

Again - intent was the intention. But point taken - I dont think I
shall be so tempted by 16-bit anymore.

--------------------------------
My First Subgenius Picture Book:
http://www.imbjr.com

Post a reply to this message