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

On Mon, 08 Mar 2004 10:18:26 -0800, Darren New <dne### [at] sanrrcom>
wrote:

>FWIW, I tested the images with PaintShopPro8.1, and assuming Windows was 
>showing me the TIFFs correctly, it looks like
>1 - OK
>2 - Hosed in ways hard to explain
>3 - B&W
>4 - OK
>5 - B&W
>6 - OK
>7 - Also hosed, but in different ways
>8, 9 - OK
>
>I think any file format complex enough to have such a wide variety of 
>failure modes probably ought to be several file formats. I don't 
>understand the point of putting both lossy and lossless compression in 
>the "same" file format.

I'm quite disappointed with PSP on this score.

>
>> anyone know about mozilla, newsgroups and a "don't display posts from"
>> option
>> much previous is humerous or meant to be, immediately above is serious
>
>Message->Create filter from

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

Post a reply to this message

Ive <ive### [at] lilysoftcom> wrote:
> 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.

  Can't you use different compression levels on different parts of the image
in JPEG2000?

> The JPEG2000 file header is just XML

  And I thought they wanted the file to be as small as possible...

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

  I wouldn't compare it to that.
  I would compare it to 16-bit vs. 24-bit sound sampling. A layman does
not hear any difference at all between 16-bit (eg. CD) and 24-bit sound,
but professionals would not work with anything less than 24. The same
goes for 44kHz vs. 96kHz sample rate...

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

>   I would compare it to 16-bit vs. 24-bit sound sampling. A layman does
> not hear any difference at all between 16-bit (eg. CD) and 24-bit sound,
> but professionals would not work with anything less than 24. The same
> goes for 44kHz vs. 96kHz sample rate...

That is exactly to the point: "would not _work_ with anything else 
than...". The extra resolution with 24bit/96kHz comes very handy when 
you have to normalize, compress, equalize etc. Same way as in image 
editing. But I doubt if there are many professionals who can hear the 
difference between 16/44 and 24/96 _all other things being equal_.

And everyone who has ever gotten familiar with Hi-Fi world know how full 
of "magic bullets" it is: weights on CDs to make it sound better, all 
the fancy techniques to reduce jitter in CD players. The differences in 
sound quality are huge when the listener knows which equipment/brand he 
is using but in a blind test the differences almost allways magically 
disappear. Well, I went to off-topic, but still, the differences allways 
seem to be mach larger on the paper than in practice.

Severi

Post a reply to this message

Severi Salminen <sev### [at] not_thissibafi> wrote:
> But I doubt if there are many professionals who can hear the 
> difference between 16/44 and 24/96 _all other things being equal_.

  Believe me: There are.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:

> Severi Salminen <sev### [at] not_thissibafi> wrote:
> 
>>But I doubt if there are many professionals who can hear the 
>>difference between 16/44 and 24/96 _all other things being equal_.
> 
> 
>   Believe me: There are.

Well, there might be but I believe you _fully_ not until I have heard 
the difference myself (I don't consider myself as being a "layman" in 
this regard). But as I have not yet used such equipment I can't comment 
more.

Severi "if I can't hear it, nobody can ;-)" S.

Post a reply to this message

>   Can't you use different compression levels on different parts of the image
> in JPEG2000?

Yes, you can, even in two different ways.
1.) j2k can consist of tiles of eg 128x128 pixels (or whatever dimension you
like)
and the decompressor can be reinitialized (for different quality settings) for
each tile.
2.) The ROI-tag  (Region Of Interest) to store a part of the image even in
higher
resolution.

BUT, none of those nine test images uses any of these features and already
with them you'll find not much reliable software to decode them and with those
*extended* features (but still ISO part 1 standard) the situation becomes
really worse.
I really do not want to advertise this Kakadu thing, but it was the only one
that
did it right.


> > The JPEG2000 file header is just XML
>
>   And I thought they wanted the file to be as small as possible...
>
Well, I do not know how the ISO works...

> > 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.
>
>   I wouldn't compare it to that.
>   I would compare it to 16-bit vs. 24-bit sound sampling. A layman does
> not hear any difference at all between 16-bit (eg. CD) and 24-bit sound,
> but professionals would not work with anything less than 24. The same
> goes for 44kHz vs. 96kHz sample rate...

Yes, sure you are right and your example is much better. It was just the case
that a few minutes before writing this I did read a posting where somebody
seriously did say this.

-Ive

Post a reply to this message

> QuickTime decodes all images except image 6 (just blank) correctly.
> GraphicConverter does decodes them all without problems.
>

Thanks, and good to hear that at least in the mac-world it is not such
a big problem.

-Ive

Post a reply to this message

Warp wrote:
> Severi Salminen <sev### [at] not_thissibafi> wrote:
>> But I doubt if there are many professionals who can hear the
>> difference between 16/44 and 24/96 _all other things being equal_.
>
>   Believe me: There are.

Wouldn't that involve being able to hear sounds at a frequency higher than
22 kHz or with a higher dynamic range than 100 dB?

Do you have a link to a 24/96 sample file I could use to compare?  I suspect
my amplifier and speakers drop off quite soon after 20kHz though, and the
SNR is probably less than 100dB, making it rather pointless :-)

Post a reply to this message

> 
> Wouldn't that involve being able to hear sounds at a frequency higher than
> 22 kHz or with a higher dynamic range than 100 dB?

Not really.
For example, there are some amplifiers that can work from 0 Hz to 200 
KHz (hi ends ones... and far more than a month salary worth...). Some 
can say that it is stupid, because it is far beyond the ears range. But 
there are some signal modulations that are generated at aprox. (I don't 
really remember) half the max frequency of the amplifier. By setting 
that max frequency that far higher, you can be sure that it does not 
affect the frequency range you can hear.

For hearing the difference between 16/44 and 24/96, on some signals, a 
lot of people can! Even those that are not professional.
I explain:
The ear is more sensitive that most think.
If you connect a fonction generator to your amplifier, you can hear the 
difference between a sin waveform and a triangular waveform at 20 KHz.
Record it on a CD, and you can no more! There is not enough precision at 
high frequencies. On a 24/69 signal, you can.

regards,

-- 
Laurent ARTAUD (lau### [at] freefr)

Post a reply to this message