Slashdot Mirror
JPEG 2000 Specs
Richard Finney
writes ""JPEG 2000 might be the graphics file format
that even dazzles the pros": at a ZD article entitled
JPEG
2000 to give the Web a new image. JPEG 2K will have
multiple channels, metadata, variable decompression levels
and progressive decompression. "
The biggest problem with the web today is the lack of professional color management. When I download a Slashdot article and print it out on my $10000 dye sublimation printer, I always feel very uneasy: is that really the shade of green that Rob intended when he made the logo? JPEG 2000 fixes that; now my Slashdot headlines and CNN stories will all be in true, calibrated color, ready for prepress.
In addition, JPEG 2000 will ride to victory on the shoulders of wavelet compression formats, which are taking the web by storm. I have seen the future and it is wavelet. It's everywhere; here is a list of sites that use it:
(nil)
Not only that, JPEG 2000 isn't just a JPEG/GIF/PNG killer, it's also the RIAA-endorsed MP3 killer! Said RIAA spokesman Ana L. Retentive, "by promoting the revolutionary new JPEG 2000 file format for music distribution, we can stop the MP3 plague, ride the wavelet of the future, and increase the American public's sheet music literacy in one fell swoop. Once the filthy, groveling peons out there succumb to the sheer joy of making their own music from lyrics and sheet music (JPEG 2000 encoded, of course) they find on the web, they will quickly realize what poor musicians they are and will head in droves to record stores."
Wavelet theory is cool.
But then, we've been promised PNG for years, and it too contains many excellent ideas. But for the entire park of current technology browsers to shrink down to 5% of all browsers in use, we shall have to wait an awfully long time. Especially as less and less people (proportionally) care about using the latest versions. Things will only get worse.
So it's a fair bet to say that this new format will never amount to anything much on the Web. I hope I'm proven wrong, but the way things are going, the current Web standards are slowly but surely congealing into a qwertyuiop-like mass of immovable standards. People are happy enough with GIF and JPEG, and as line speeds get upgraded, people don't really care any more about an image that takes .02 secs to transfer rather than .12 secs. It just doesn't matter any more.
Not only are there already too many graphics and video formats to choose from, but there will also be as many new formats as we care to write.
:) Combining raw image formats with generic compressors seems like a great idea for lossless compression, even if that does only get you so far.
What do I use for lossy compression? JPEG, due to its popularity. Lossless compression? GIF, PNG, xcf.bz2, ps.gz... Use the right tool for the job.
I'd love to see a new, openly developed, lossy compression scheme. Unfortunately, I wouldn't know where to begin, because most of this work is done by commercial software companies and whatnot...
pb Reply or e-mail; don't vaguely moderate.
However, given the perceived "good enoughness" of GIF and current JPEG, any new format faces an uphill battle.
Can anyone here give us a meaningful comparison between JPEG 2000 and AT&T's DjVu compression, which is also supposed to be wavelet-based? Are these two similar, or are we talking apples and oranges?
Also, it was unclear in the JPEG2K article whether the new image format maintained the current distinction between compression and file format. Currently most "JPEG" files use a format called JFIF, but the file format and compression are separate -- so the file format can be used to store information other than the image, or could be used to store images compressed with other compression algorithms. Conversely, you can have JPEG-compressed images stored in other file formats. Some digital cameras like the Kodak DC-260 do this -- use JPEG compression but not the JFIF file format.
Anyway, that seemed like a good design, but it seems clear that the new JPEG2K requires both new compression (wavelet) and a new file format (for multiple channels). I hope they manage to keep the two separated as in the original JPEG.
--JT
I have to agree. Web site designers are terrified to use PNGs on their site because they know that a sizeable percentage of their viewers can't... well, view 'em. And browser support for them still isn't where it should be.
JPEG 2K might be God's own personal image format, but if a format falls in a forest and no one is around to implement it, does it make for pretty pictures?
For those not familiar with DCT or wavelet compression methods, what we're talking about are ways of telling the computer how to generate the image mathematically from a much smaller set of data. The "ideal" algorithm would quickly reproduce any image accurately with the smallest possible dataset. The problem is, different techniques work better for different images. Which is why I suggest that until hard numbers are available, I wouldn't add momentum to this particular bandwagon. One of the folks working with me on wavelets said it way better than I ever did -- "the math is truly hairy", which means that even if JPEG2000 is a wonderful algorithm, moving it into code for alternative platforms will still be a daunting task. "Hairy math" takes time for the computer to resolve.
Meanwhile PNG... From my limited work and reading, PNG appears to be an excellent format -- but one that hasn't reached the critical mass that Linux has. HowToHelp: plug ins. M$ probably won't listen [ever tried to run IE for Linux? ;')] but Mozilla's developer's will listen. Octave's developer's will too. (I haven't checked to see if there is already a PNG code branch in Mozilla or Octave, so apologies if I'm speaking out of turn.)
A last question for the /. world: (later in the article) Speaking about Lizard Tech's MrSID, I noticed a feature I wondered about: "...MrSID supports an exact coordinate system that lets a user zoom in on an area of the picture." Does anybody know if this particular feature is covered under any patents?
...Open Source isn't the only answer -- but it's almost always a better value than the alternatives...
Interesting. But I have some *ahem* concerns. First off let me mention that I work in "multimedia", and a bit more than a year ago I did a lot of research into different image compression formats, as we were starting on specifying a new product.
So, with that disclaimer:
1). I seem to recall that JPEG already had a facility for storing multiple resolutions in one image, with all general compression info stored at the start of the file (in JFIFs), and the lowest res version next, followed by the 2nd lowest res, and so on, until you reach the highest res at the end.
2). Whilst looking at different compression formats, I also looked at several different wavelet based implementations. Without exception they looked worse than JPEG at the same file size. Yes, you read right - WORSE. Both in a 256 colour display (JPEG at its worst, as dithering looks really quite bad in palettised display), and with millions of colours. We dropped the idea of using wavelets. Oh, and the decompression speed _appeared_ to be slower for wavelets than for JPEGs. Not significantly enough for it to have affected our decision, but still...
3). JPEG, even though it is lossy, makes most photos look better than they started off. This is due to the way that the sampling for the DCT works. It takes into account how the human eye works, and leaves out things that our brains wouldn't even notice anyway. Kinda like the psycho-acoustic sampling used for MP3. Many people are reported to prefer that sound to the original digital sounds aswell.
Of course, we would never use JPEGs for line drawings, or maps (with lots of text). For those we use a lossless compression. Sadly the choice here had to be GIF (supported by Java, and our app is being written in Java. *sigh*).
JPEG2K does, however, sound interesting due to the combination of a lossy and a lossless compression scheme into the same "standard". On the other hand, the same thing could be done with JFIF, and already IS done with BMPs and PICTs. And coming from JPEG, it is likely to be fully supported by Sun years before PNG is finally supported. *sigh*
~m.
More information on JPEG 2000 can be found at http://www.jpeg.org.
I am wondering if the IJG is planning to (and has sufficient resources to) implement JPEG 2000 support quickly as the specification finalizes. Does anyone know? I asked Tom Lane about this indirectly a while ago, and he just pointed me to the www.jpeg.org web page.
The IJG did a great job on the current library, and I hope that they can do JPEG2000. I also think that if they need support (manpower/money) it would behoove the OSS comunity to provide it.
If for one agree that wavelet based approaches to compression are the future off lossy continuous tone compression. The MrSID technology for instance is great, but they hold a very tight hold on their proprietary technology. I think it is important to establish a popular, and public format and technology to fill this void or proprietary interests will damage OSS efforts.
Geospatial Programmer for Rent
Nothing is happening within IJG; we are waiting to see what emerges from the ISO JPEG committee, and in particular whether it is (a) patent-free and (b) enough better than JPEG-1 to be worth a universal upgrade cycle.
On point (a), I have made my views quite clear to the JPEG committee, but I dunno whether they are listening. There will not be an IJG implementation of JPEG-2000 unless it is freely distributable and freely usable under essentially the same restrictions (ie, none to speak of) as our current code. Patent licenses are a show-stopper. But from what I've heard, all the proposals before the committee have some amount of patent encrustation.
On point (b), the poor track record of progressive JPEG has left me unenthused about pushing incompatible standards that offer only marginal or special-purpose improvements. JPEG-1 took the world by storm because it was an order of magnitude better than anything else available. Unless JPEG-2000 is that much better again, it faces at best an agonizing uphill fight; the world might be better off without the ensuing confusion. (I have not heard anything about what performance improvements they actually expect to get ... but I am suspicious that we are going to see percentage points, not integer factors.)
So, I'm waiting and watching.
Geospatial Programmer for Rent
I would hope JPEG would give a sample implimentataion and C libs like they have done with the past specification.
They have seemed to be pretty open in the past.