JPEG2000 Coming Soon 489
Sonny writes "In a few months time, internet users will be able to make use of the JPEG2000 standard which, its developers claim, enables web graphics to be downloaded much faster than is currently possible. This will not only make graphics-heavy web pages easier to download, it will also preserve image quality. The JPEG standard compresses image files which are then transmitted across the web faster than uncompressed files. Now, researchers at universities around the world have developed JPEG2000, the next-generation image-compression technology under the auspices of the International Standards Organisation. It is the first major upgrade of the standard since it first appeared in the early '90s. What is also important about the technology is its ability to send files without loss of data, which is not the case with current JPEG files. To take advantage of a JPEG2000, web browsers will need a Plug-In for either Internet Explorer or Netscape browsers. These free plug-in's are expected to be available later this year. The extension for the new files will be ".jp2"."
Wow! (Score:5, Funny)
Re:Wow! (Score:4, Funny)
A shipping browser plugin and a very good SDK (Score:3, Informative)
Dr. David Taubman was one of the authors of the JPEG 2000 spec. His book on JPEG 2000 is now available. He has also released a very nice SDK for compressing, decompressing, manipulating and streaming JPEG 2000. It's called Kakadu and you can read more at http://www.kakadusoftware.com/. The source code for Kakadu is packaged with the book. There are demo images and software at this site also.
Excellent! (Score:4, Funny)
Oh, and FP, BITCHES!
The most useful and widely used benefit (Score:3, Funny)
It's obvious where this is going. (Score:5, Insightful)
I think we're just stuck with jpeg and gif for about the next 5-10 years, until browsers in general get reinvented.
Re:It's obvious where this is going. (Score:5, Informative)
You're talking about the difference between 300k and 20k. The reason that
JPEG2000 has a few things going for it:
- Familiar Name
- Familiar Standard
- Smaller filesizes
- Likely to be better supported by IE and other browsers
PNG *is* a god-send. (Score:2)
So, the PNG format is a resounding success among those who work with images, and then we dumb it down to JPEG or GIF for the end users.
All that said, I don't see the JPEG2k standard really succeeding--now that more and more users are getting faster and faster connections, there's not that much need for the smaller filesizes. Combine that with the fact that users have to install a plugin to see them--and God only knows which browsers and what versions they may be using--and I don't see webmasters clamoring to adopt it, and if they don't adopt it in large numbers, the format will never catch on. So it's very iffy at the moment, IMHO, as to whether the new standard will ever replace the old--certainly not in 5 months from now, and probably not even in 5 years from now, since the need for file size savings keeps slowly evaporating.
Re:PNG *is* a god-send. (Score:3, Interesting)
However, at the same time that endusers are getting faster connections, more and more webmasters are starting to feel the very real pain of bandwidth costs. I think the adoption of smaller image formats will come more from their side.
If jpeg2000 makes enough of a difference, I can see at least a very large percentage of graphics oriented sites switching - almost forcing the users to follow suit.
Interesting point. (Score:5, Insightful)
Think about it--how many users are set to automatically download plugins as needed? Almost none because of security reasons. herefore, some active decision is needed on behalf of the user to actually install the plugin or not. What will be the user's reaction if he goes to the site of WidgetCo, doesn't know what to do with this dialogue box about installing stuff (especially if he's been told be friends or company that installing strange software can be dangerous, or if he's been molested by the likes of CometCursor), says "No", and gets a page of big X's where all the buttons and banners should be? Well, it might well be to go to the site of WidgetBiz instead to get his widgets there.
This is why I really don't see JPEG2k taking off. It's a risk most companies won't take--you don't want your users not being able to use your site. Look how long it took Flash to become as common as it is today--many years, and then only because it started shipping by default with Windows.
I have no doubt that IE7 will have JPEG2k support--poor and half-hearted support. As with most Microsoft products it'll probably take the until the second major release to get it right, so let's say IE8 will have fully implemented JPEG2k support out-of-the-box. How many years will it be until that's out? And how much further along will available bandwidth be by then?
I could well be wrong, but I just don't see this taking off. Unlike Flash did, it doesn't bring anything spectacularly new to the table--a few people have been talking about the visual effects you can get using wavelet images, but those same effects are common (if poorly implemented) Flash effects today, in addition to the many other effects Flash does. So that leaves us with the better compression over JPEG as its big marketing point...and I just don't see that being enough to get website owners to risk alienating end users. So *at least* until great JPEG2k support ships with IE out of the box, and that version of IE is common, I don't see JPEG2k going anywhere except into some niche markets.
Re:Interesting point. (Score:3, Funny)
> want your users not being able to use your site.
Judging by the state of usability of the vast majority of sites, I'm thinking that most companies couldn't care less whether people can use their sites or not.
Re:PNG *is* a god-send. (Score:3, Informative)
SVG is the most fantastic vector based graphics format ever created. Not only is it fully scalable to what ever size you care to scale it to, but it's all done in XML, which means scripting graphics creation is nigh on basic.
Since SVG is basically text, the file sizes are tiny! Add to this the fact that svgz (gzipped svgs) are part of the svg standard, and you end up being able to create fully interactive vector based animations weighing in at less than 1K (try this [xml.com] -it's a perfect example of how cool SVG is)
As it stands now, SVG can only be viewed on IE and NS4 with a plug-in, but Mozilla supports it natively if you enable it ;) It's a more important standard to propergate than JP2 IMHO.
On the PNG front: PNG is so much better than any other format for layout graphics on web pages. It's alpha tranparency and colour pallet is all you need (it runs circles around GIF). PNGs should be the internet standard for non vector graphics, but alas, IE does not render them properly (the colours get twisted and changed as far as I've experienced). If MS could stick to standards, it'd make the internet a whole lot better.
Anyway, in conclusion, JP2 may sound nice, but there are much more important formats out there that need to be adopted before JP2, which will not only cut down the transfer sizes of graphics, but make web development just that much easier for people like me.
Re:PNG *is* a god-send. (Score:3, Informative)
SVG is a good vector format for the arena it was designed to serve (primarily, the web). For other uses, the text based markup is a tad bloated, and the fact that it's easily scriptable isn't a factor. It's not perfect, but the web needs a good, open vector graphics format, and SVG is a well designed option, in most ways. I just wish they'd get the fonts right [levien.com]. Of course, Flash has been providing web based vector graphics for ages. It's just that it was always aimed at presentation, and didn't take into account accessibility, searching, consistency of navigation and all the other things that we should expect a vector format to provide. In that respect, SVG is a significant step forward, and I hope it starts to gain widespread acceptance soon. But with even Mozilla not supporting it in many of the standard builds, it has a way to go before that stage.
Re:PNG *is* a god-send. (Score:5, Informative)
This site [dpreview.com] illustrates the difference in quality between JPEG and JPEG2K. You get essentially a 5x reduction in storage space without losing quality, and the type of artifacts aren't as annoying, either.
Re:It's obvious where this is going. (Score:3, Interesting)
Sure, shorter download time would be nice, but PNG isn't really providing that. PNG however makes the job of the web developer easier.
(*) I'm still annoyed that IE doesn't support alpha-transparency though.
Re:It's obvious where this is going. (Score:3, Informative)
It does, you just have to use the IE-proprietary AlphaImageLoader filter (it's a CSS extension). I agree this is a pain in the ass, and why they just don't support the alpha channel with regular img tags is beyond me, but at least with a little PHP or Javascript you can make it work.
Jason.
Re:It's obvious where this is going. (Score:5, Informative)
Yes, the reference is on MSDN's site [microsoft.com].
It's not complicated to use, it's just awkward, and you need to use PHP (or Javascript, or some other solution) if you want it to work in both IE in Mozilla. Here's an example of how I've done it in the past:
<img src="blank.gif" style="filter:progid:DXImageTransform.Microsoft.A
<? } else { ?>
<img src="imagewithalpha.png">
<? } ?>
The implementation of this in IE seems to be pretty good -- at least I haven't run into any problems with it.
Jason.
Re:Hypocrite (Score:2)
WTF are you talking about? The poster specifies that it's fine to use the new version as long as it's supported. That is to say that it's unreasonable to prevent him from using the new version as long as it's accessable to others. That's a completely different thing from what MS did, which was to implement a new way of doing things specifically to prevent others from supporting it. There's nothing at all hypocritical about saying 1 and not 2.
Re:It's obvious where this is going. (Score:2)
Who are you ?
I use
Re:It's obvious where this is going. (Score:2)
Re:It's obvious where this is going. (Score:2, Insightful)
That's how the world works my friend...
Re:It's obvious where this is going. (Score:2)
The problem is backward compatibility. Not all of the people who come to our website are technically savvy enough to upgrade a browser (which is why MS was so insistent in bundling IE, you may remember) and those are savvy enough may not have the time, inclination or a fast pipe to get the next version of a browser in a reasonable time. So despite the fact that mozilla and ie could support it in a month, our users might not be able to until they get a new pc, which means a 4 year or so wait before it is worth it.
Is it really worth it do do the browser check for a graphic when an existing format will do what I want? No.
Stupid extensions (Score:5, Insightful)
I still cringe when I see default.htm. It's a frickin' html file, name it properly.
-Ben
Re:Stupid extensions (Score:5, Insightful)
Because they're latching onto the idea (and popularity) of
Re:Stupid extensions (Score:4, Insightful)
Just because names can be made longer doesn't mean that they should.
.jp2 is sufficiently clear, and it won't clutter diretory listings. Save the longer, more descriptive extensions for more obscure things.
Re:Stupid extensions (Score:2, Insightful)
Re:Stupid extensions (Score:3, Interesting)
You're right about 8.3, though. It disgusts me. But this is just the
Re:Stupid extensions (Score:2, Offtopic)
I really hate Windows' use of extenstions. Why should extensions control the application association. Remember OS/2? It had an EA (extended attribute) that assocated the file with an application.
I have all sorts of problems with users renaming files so they associate with the wrong thing, then they wonder why Word won't open an EXE properly - or other similarly stupid thing.
The extension should either not exist, or only exist for additional naming info. It shouldn't have anything to do with application association.
Windows, it seems has never done it right the first time. Every time we get to be the test subjects for MS's stupid ideas. (How about clippy! DAMN!) Sometime they eventually get it right. (How about Network file share rights and inheritance in NT! Every user that has rights to a folder farther down in the tree must have at least browse rights to every directory higher in the tree to use explorer to navigate to the folder they have rights to...that also allows them to see all the files in the folders they shouldn't!)
I'll quit ranting now!
Cheers!
Re:Stupid extensions (Score:2)
for a project I was told I'd need to parse the Excel files that users submitted, and given .xls files. So I looked around for something to allow me to read Excel files from java, found some thing from IBM that actually loaded Excel in the backround to do it, it worked, but crashed all the time. Found something that was supposed to read read the binary format without any MS crap, spent a few hours trying to make it work, no luck - doesn't recognize the format. Of course only then it occured to me to actualy check what the files were, and sure enough, tab delimited text files with .xls extensions (which Excel loaded and converted on the fly, when I was using the IBM thing). I felt very stupid, for a long time.
Re:Smart Extensions (Score:5, Funny)
A few characters per file name - yes those couple of bytes will save gobs of bandwidth.
2. Easier to type.
How often do you actually type file names? I do it once - when I create the file, I think I can afford the few seconds.
3. Backward compatability.
With what??? I am willing to bet that whatever you dig up that requires 8.3 will not be compatible with the actual file format.
I cringe when I see people have named the file some big long gobbledegook like bobbys_8th_book_report.doc when bookrep8.doc would have done just fine.
Yes, that's a stupid name, and no bookrep8.doc is not better. Who numbers their bloody book reports? I think little bobby will get a bit confused a few years down the road when he gets to bookrp48.doc How about "steppenwolf report.doc"? or "glass bead game report.doc", I really do think I see how these are better than stpwlfrp.doc and glbegarp.doc
Re:Stupid extensions (Score:2)
index.hypertextmarkuplanguage.english_UNITEDSTATES OFAMERICA anyone?
A bit late... (Score:3, Informative)
ciao
Never late. (Score:3, Insightful)
Many places are STILL on dial up and will continue to be.
Any new technology that compresses well can only be a good thing.
Re:A bit late... (Score:2)
Beyond that I don't know anyone who feels like he has too much bandwidth. There seems to be a principal that a lot of people (especially windows programmers) subscribe to that says "my use of resources should expand to consume the resources available." I don't understand why this is, especially since we live in, and have been living in for some time, an age of multi-tasking.
-Peter
Bandwidth is always limited. (Score:2)
... shared with all the other phones in the cell, its contiguous neighbor cells, some cells further on, and the other carriers in the area.
Bandwidth is not free and unlimited, especially when it's wireless. Want more, use higher frequencies - and pay your piece of the cost for better equipment, plus a hefty profit. Do you stop when the cell towers are flooding the neighborhood with x-rays, or do you keep going into the gammas?
Better compression means faster downloading at ANY bandwidth, which is significant until the downloads are faster than you can see. Then think movies. Then think movies at HDTV resolutions, in VR total surround video, at flicker-free-during-eye-motion frame rates. Then think separate movies for each of the people in your family at the same time.
They'll keep implementing better chips. But they'll have a REALLY hard time implementing better physics.
And even when they do come up with more bandwidth you'll still have to PAY somebody to supply it to you. Right now the CLECs (Competitive Local Exchange Carriers) are about all dead. Without the competition the ILECs (Incumbent Local Exchange Carriers - mostly the fragments of the old Bell monopoly) have no incentive to sell you a broader pipe and undercut their own pricing on the narrower ones you're already paying for. And with the death of the CLECs it will be a long time before anybody invests a few billions to start up another one of 'em.
Re:A bit late... (Score:2)
I have DSL but only at 144K/sec (fastest availiable because of the phone company here) which is faster than dial up but still large files take time. I welcome some compression on images
Re: (Score:2)
free bandwidth (Score:5, Funny)
excellent, using jpeg2000 increases my bandwidth too!
There I was thinking they downloaded at the same speed but in less time!
Re:free bandwidth (Score:2)
It downloads so quickly, that it goes back in time, creating a prallel universe where jpeg2000 does not exist. This, obviously, causes a normal jpeg file (which has the same image as the jpeg2000 file you were downloading) to appear in our universe, on your computer, at about the same time as when you request the download, but spinning in an opposite direction (also, and I am not sure about this, if you are using IE, the little globe icon also spins in the opposite direction).
Slow to change ... (Score:5, Insightful)
Until the
Just my $0.02.
Re:Slow to change ... (Score:5, Interesting)
[OT] Re:Slow to change ... (Score:2)
Two things scream out at me. One, I can reliably set up layouts with nested tables which, under IE, display in a way which is indisputably incorrect. Two, we have a bunch of machines at work which muck about with several sites we've produced. Essentially, IE doesn't render the images right. Occasionally it doesn't render an image at all (rare but has happened, and it doesn't leave a placeholder because it doesn't realise it hasn't shown it up) until the image is clicked on or scrolled off the screen and back on. More commonly, it sticks a suprious transparency in place of white on some images, or even effectively makes the whole image slightly opaque. When there's an image background, that gets messy...
Bottom line, it's sloppy.
Re:Slow to change ... (Score:2, Interesting)
JPEG does have a lossless mode (Score:5, Interesting)
JPEG does support a lossless mode, it's just that no one uses it. To paraphrase, JPEG supports a lossless spatial algorithm that operates in the pixel domain. Some amount of prediction is used, resulting in about 2:1 compression, but the error terms for the predictions are included in the data stream (encoded using either Huffman or arithmetic coding), resulting in no net errors.
What's a lot more exciting is JPEG2000's use of wavelet compression, which isn't mentioned at all.
Re:JPEG does have a lossless mode (Score:3, Funny)
Horray for wavelets! Now if only someone would re-explain them to me. I didn't catch it the first time and no one has said anything high level enough since (I'm not interested in the nitty gritty at this point)
Re:JPEG does have a lossless mode (Score:2)
Re:JPEG does have a lossless mode (Score:2)
Ogg Tarkin (the video codec) will be using wavelets from the beginning, though.
Re:JPEG does have a lossless mode (Score:2)
See the FAQ [xiph.org] for details.
Re:JPEG does have a lossless mode (Score:5, Interesting)
The lifting algorithm (one way of computing the wavelet transform; actually, the simplest to understand and one of the fastest) works by splitting the original signal into two (in the case of a 1d signal) subsignals. One of these is the "trend" signal. It's sort of a compact version of the original one. Using only this signal, the original signal can be reconsturcted pretty well, but not perfectly. That's where the other signal, the "detail" signal, comes in. It contains the information needed to reconstruct the original signal perfectly. If the trend signal is a good prediction of the original signal, the detail signal will be very small, and can be compressed well.
But, there's no need to stop there. The whole process can be applied to the trend signal again, and even to the detail signal if it's necessary.
I'll give a more concrete example, the Haar wavelet transform. In this case, the trend signal is simply the averages of the original signal. So, if we start with
1,3,4,5
The trend signal would be
2,4.5.
If we were to reconstruct the signal with only this information, we'd get
2,2,4.5,4.5,
which is not too bad. The detail signal would contain the information needed to get from this to the original signal; differences between pairs of consecutive terms will work (Note that these pairs shouldn't overlap; that would just be redundant. Therefore, the detail signal, as well as the trend signal, are each half as long as the original one). So, the detail signal in this case is
2,1.
It's easy to see that if the original signal is constant, the detail signal will be all zeros. It's possible to construct different ways of making the trend and detail signals such that the detail signal will be zero if the original signal is linear, for example.
A good paper about this (that explains it better than I do!) is Building Your Own Wavelets at Home [bell-labs.com]
Re:JPEG does have a lossless mode (Score:2, Informative)
First, compression efficiency. Although lossless and near-lossless quality isn't hugely better, data rates for "good enough" quality (defined as where the image is understandable and artifacts aren't too distracting) are much, much lower. Unlike the old Discreet Cosine Transformation (DCT) method of JPEGs, which get blocky at high compression, wavelets get softer, which is much less obvious. So, this might not help things with pro digital cameras much (which were lightly compressed in the first place), it will help a lot with web images and such, or consumer digital cameras.
The other nice thing about wavelets is that they are constructed in bands. First, the base image is encoded at a low resolution. Then this is used as prediction for the next resolution, and that band only has to store how the image is different from the prediction.
This is groovy, because you can decode the individual bands as they're transmitted, giving a low-resolution proxy image once only a few percent of the file is transmitted, getting progressively higher quality over time. While progressive/interlaced JPEG/GIF gets the same effect, wavelets do it more efficiently.
Many years ago, Intel created a video file format that used these properties, IVF. Didn't ever get any market traction. You can still get the tools from Ligos.
Re:JPEG does have a lossless mode (Score:2)
Lossless JPEG uses patented IBM stuff (I think the rest of JPEG uses various patents as well, but everyone agreed to freely license them, IBM didn't agree for the lossless stuff). I think that is the big reason pretty much nobody uses it.
does this mean that... (Score:2)
tough choice.
Artwalker.com to use JPEG 2000 (Score:3, Interesting)
Mozilla & jpeg2000 (Score:5, Informative)
Doesn't seem too promising:
If you look at appendix L of the jpeg2000 draft, there are 22 companies who believe that implementing the spec may require use of their patents.
PNG still hasn't taken off despite being supported in all major browsers (now if only IE did proper alpha, any year now...), how much chance does an image format that requires third party plugins have?
Re:Mozilla & jpeg2000 (Score:2)
Bwahaahaha!! I sugested doing this before when slashdot linked to bugzilla directly from the story description, i never thought they would actualy do this!
Very nice way to prevent the slashdot effect
Re:Mozilla & jpeg2000 (Score:3, Insightful)
Seriously, this is exactly the position in video compression right now. Dire, in other words.
Dave
The Relevant Entry (Score:5, Interesting)
Here's a summary of the jpeg2000 situation that I wrote up, but never made it into bugzilla:
Uses new compression standard (Score:5, Funny)
Re:Uses new compression standard (Score:2)
You can say that again!
I think it'll catch on (Score:2, Insightful)
However, I think it'll really catch on whenever the next versions of the browsers are released with standard support for JPEG2000.
found this nice comparasion (Score:3, Informative)
JPEG 2000 looks like the right thing at last. (Score:5, Interesting)
Good one. Thanks for the link.
Looks like JPEG2000 finally got things right for the human eye:
- Higher compression ratios just gently blur details, rather than creating artifacts. Losing the extra information leaves the part that DID get through intact.
- The text says the compression allows for progressive downloading. This implies that the coding scheme does something like working upward in spatial frequency - encoding the basic stuff first then sending progressively finer deltas. For a given compression ratio just stop the downloading (or file saving) when you have enough.
- The compression seems to match eye processing so well that highly compressed (100:1) images actually look BETTER than the basic image. The features important to the eye (facial stuff, especially eyes) gets through or even enhanced, while unnecessary detail - including sampling artifacts - gets selectively blurred out. Something like the soft-focus filter in portrait photography. The only thing in the samples that got noticably worse at high-compression is hair, which just gets a bit blurry. (Meanwhile, JPEG looked like it had pixelated measles.)
Of course the images selected for the demo could have been optimized for the compression scheme. B-)
Re:JPEG 2000 looks like the right thing at last. (Score:2)
One of the images was the Lenna centerold, which has long been a de facto [lenna.org] test for image compression algorithms.
Patents, Patents and more Patents (Score:5, Insightful)
I remember a similar promise made about LZW compression in the GIF standard by Compuserve. What is to stop these companies from requiring license fees at some arbitrary point in the future once the technology is widely used?
Additionally, there doesn't seem to be very much due dilligence performed in regards to other patents over the techniques utilized in the standard. Even if all of the known patents are licensed royalty-free, there exists the very real possiblity that a submarine patent will be exposed, after the standard is widely utilized, of course.
Of course, this won't matter once all of our PCs are replaced with sealed, SSSCA-compliant, government issued "convergence appliances"... :-)
Re:Patents, Patents and more Patents (Score:3, Informative)
I don't recall Compuserve ever promising that, in fact at the time they made GIF nobody really thought software patents were workable...except the patent office.
Plus if CompuServ tells me I can use Unisys's patented crud, why should I believe them? I only trust what IBM says about IBM's patents. Likewise for JPEG2000, I'll believe I can get a royalty free license only if the patent holders sign for it, not 3rd parties.
If you look at RAMBUS you will see they made a similar promise when they were at the JDEC meetings that eventually produced SDRAM, and while they did sue, when someone finally decided not to settle RAMBUS got spanked. Hard. So while it ain't perfect, there is some reason to believe it will work out Ok.
And what's more... (Score:2, Interesting)
I say we just refine the
Wow. This couldn't have been timed better (Score:5, Interesting)
A) It's an excellent codec, though computationally heavy
B) The design of the codestream along with JP2/JPX file format has a lot of potential to create a "new" type of image that isn't just a picture. Yes, you've heard this before, but this time it's built in at a codec level. In stream ROI's, very flexible reconstruction and compression controllable through great numbers of options - and that's only the codec (at a *very* rudimentary level
C) It won't succeed without a decent opensource, "IPR free" (as much as is possible) implementation.
D) Read C again. It's important
To this end, I've started (with support from others in the JPEG 2000 community), a JPEG 2000 Group (See http://www.j2g.org [j2g.org] - It's very sparse at the moment, but if you're interested, bookmark it and come back in about a month). Tom Lane and IGJ have expressed no interested in JPEG2000, for various reasons (which I don't entirely disagree with, but I'd rather be proactive and try to correct flaws than walk away totally).
The aims of the JPEG 2000 Group are to create a public, open source (probably BSD license) implementation of "Part 1" (This is the codestream syntax, codec, and file format wrapper). We'll also provide a community JPEG 2000 resource. To facilitate this, we've already attained a Class C liaison with the committee. This grants all members the option of acquiring the standard free of charge. We also get a minimal channel back into the process to give opinions.
The point of this ever rambling post is this : We need members. The standard is large, and the support around it will be larger. We need volunteers who would be interested in assisting in the creation of the codec. Sadly, "Membership" is going to require some form of contribution and commitment to acquire copies of the texts you'll need - I hate this as much as you, but it was accept it, or don't get any copies at all (without $$$). If you're interested in contributing in any way (code, documents, testing, support), please drop by the at forum [j2g.org] - Even if its only a passing interest, I'd be happy to go into more detail regarding the project (or just JPEG 2000 itself). I'd do it here, but I'd loose all my (low
So, rather than bitch about the lack of a free implementation and how late it is, and how it'll never get used, come and help out! You know you (might possibly | maybe | someday) want to!
What's missing from the comparisons (Score:3, Interesting)
will it actually get off the ground.... (Score:2, Informative)
libjpeg (Score:2, Insightful)
or some of us that compile our own code and use dynamic and static libraries, the change would be as transparent as recompiling libjpeg.
just another reason I like open source.
Ah hahahah (Score:2)
What happened to DjVu? (Score:5, Interesting)
But there are other, more powerful formats.
For a non-descructive compression, the PNG format is fortunately getting more and more popular, although the late inclusion in Internet Explorer slows down its wide adoption.
But when it comes to a destructive compression, there's an excellent (and not new) format made by AT&T and called DjVu. It was one of the first wavelets-based format.
DjVu is really better than Jpeg. Images are better looking (more contrast, less pixels with odd colors), and files are way smaller. Plus you can smoothly zoom any DjVu image without getting big and ugly blocks.
DjVu has been available for a while as a plugin for common browsers.
There's a 100% free implementation of the format called DjVuLibre [sf.net] .
However, nobody uses it. I don't understand why. Some times ago, it may have been because compression was slow. But nowadays, it's no more a valid point.
People are enthusiast for Jpeg2000. But why would Jpeg2000 be adopted while DjVu has never been?
Re:What happened to DjVu? (Score:2)
There's a technical description here [sourceforge.net].
Re:What happened to DjVu? (Score:5, Interesting)
In the real world, companies don't want to either GPL their software (required if they use this GPL library), or reinvent all the code from scratch based on the spec, unless there's huge demand for it (which there won't be due to chicken & egg scenerio)... So, don't expect to see any support for DjVu anytime soon.
Good timing (Score:2)
Nice Ad (Score:2)
Could this story be submitted by an insider? Hmmm... I know, I know, Slashdot != "investigative journalism"
comparisons to other formats (Score:5, Informative)
the report compares 4 compression codecs, and found for a small sample found:
MEAN LOSSLESS COMPRESSION RATIOS (big is good)
------------------
JPEG 2000: 2.5
JPEG-LS: 2.98
L-JPEG: 2.09
PNG: 3.52
JPEG-LS is was usually the best, but PNG had a few really good sample that pushed its average up. Actually, these outliers appear important, because that is what really separates the codecs on this metric.
Lossless Decoding Times, relative to JPEG-LS (big is bad)
-----------------
JPEG 2000: 4.3
JPEG-LS: 1
L-JPEG:
PNG: 1.2
This doesn't make JPG2K appear too impressive. What it does offer, however, is features. Like Region Of Interest (ROI) coding, good lossy compression, random access, and other goodies that some people may really care about. The report claims that png doesn't do lossy encoding, which is news to me, but it does appear to be one of their major selling points for jpeg-2000 over png.
Re:comparisons to other formats (Score:3, Interesting)
This doesn't make JPG2K appear too impressive.
JPEG-2K is really intended for lossy coding, and that is where it shines. The lossless spec is included primarily because you can use the same algorithm for both lossy and lossless coding. The only real difference is in the choice of wavelet transform, which is irreversible (floating-point) in the lossy case but reversible (integer) in the lossless case.
A better comparison pits JPEG-2K against the original (lossy) JPEG. According to a figure given in this paper [jpeg.org], J2K provides roughly a 2dB PSNR gain over JPEG for a wide range of bitrates. At the low rate of 0.25 bits per pixel, this gain takes you from 25.5dB to 27.5dB; perceptually, that is a noticeable difference. At low rate, JPEG is also subject to blocking artifacts, so the perceptual problems can be even worse than the PSNR numbers would indicate.
In other words, JPEG-2K is a Good Thing.
B SD-licensed JPEG-2000 implementation (Score:5, Informative)
a BSD-style license.
It's been tested at the MIT biodmedical department already for compression of medical images.
It's available at http://j2000.org/.
It would be nice to see this work in my favourite browsers.
What's cool about JPEG2000? (Score:5, Informative)
JP2 uses wavelet compression such that an image is effectively compressed at various resolutions below the originally, independently. Not only does this allow a high level of redundancy removal (which is why wavelets are good in the first place) and thus high compression, but jp2 tags each of these sections (subbands) separately in the compressed file.
So what? Well, a file with all of these sections is effectively a losslessly compressed image. However, this file can be further compressed (loss-ily) by simply throwing out some of these tagged sections! That is, you can make a "lossless" thumbnail image by keeping all the lower resolution subbands. Or, you can get a lower-quality (but smaller) fullsize version by throwing out some subbands at each resolution.
Better still, this manipulation can be done without decompressing the original image. Simply using only certain tagged sections of the file.
Consider this possible application of all this: Digital Cameras. A camera could take images at full resolution and lossless quality until the memory card starts filling up. Then, gradually as more and more room is required, it could quickly reduce the size or quality of previous pictures to make room for new pictures. Thus, you always have "enough" room for more pictures, provided you don't mind the quality reduction.
Of course, there are numerous uses for web applications -- thumbnails and full-sized images could be the same file, provided the web server knows how to parse the image file. (Little or no computation necessary, just sending parts of the file)
Anyways, JPEG2000 is very very cool.
Coming Soon to a PC near you! - NOT! (Score:2, Interesting)
Or did
As far as I can tell with a quick google, nothing has been done with this standard since early 2000 (maybe that's why the standard name hasn't been updated, eh.) I wouldn't hold my breath waiting for widespread adoption any time soon...
file extensions (Score:2, Funny)
I wonder what the Pope thinks about the file extensions being callled
grapihcs-heavy? (Score:2)
This will not only make graphics-heavy web pages easier to download
Oh great! Even more websites designed with the idea that Photoshop is a webdesign tool and that the best way to make a webpage is lots of massive images instead of text and styling.
Mumble mutter grouse.
Good thing it looks like it'll take ages to catch on.
Better compression implies more bloat (Score:2)
Unfortunately, one effect of better compression will be more bloat -- web pages with more graphics and more advertising. This is because with better compression, there is more information transmitted per byte, thus giving more value, so the decision about whether or not to include pictures tips in favor of more and bigger images. Thus the average size of a web page and all its components will increase.
If you think the images are valuable, as many web designers seem to for incomprehensible reasons, that is a good thing. But if you do not value lots of images, that is a bad thing. So, better compression harms those with slower links, those who detest advertising clutter, and those who seek concise information rather than flashy presentations.
(I am not opposed to better compression, just pointing out an unintended consequence.)
To be redundant and sum up. (Score:4, Informative)
If there's any indication that this will actually be out in a few months, I missed it.
If there's anything indicating JPEG2000 support for Mozilla, The Gimp, Paint Shop Pro, or Photoshop in the near future, I missed it.
I've yet to see anything that indicates there are no more patent issues and that people can support this format without patent issues (Read "Can the Gimp ship with this?")
Regarding Exploer PNG support:
AlphaImageLoader Filter [microsoft.com]:
Displays an image within the boundaries of the object and between the object background and content, with options to clip or resize the image. When loading a Portable Network Graphics (PNG) image, tranparency--from zero to 100 percent is supported.
Just because I do miss it, I still see almost no support for the beloved fractal image format *.fif I think it's now part of LizardTech's [altamira-group.com] line of image compression/fractal tools. If you think jpeg200 offers compression, then you missed the fif format completely.
Backwards (Score:2)
Nah, it'll probably make easy to download web pages more graphics heavy, if I know today's web designers...
New IE Exploit (Score:2, Insightful)
Comparisons with PNG/GIF (Score:2, Informative)
What thrills me even more is the possible application of wavelet compression algorithms in 3D.
See this for a dramatic flash-based demonstration of advantages - notice that it says 4kb!:
http://www.luratech.com/index_e.html
Metadata Section (Score:4, Interesting)
I always thought it would be cool if your digital camera could include the settings (fstop, exposure time, ISO, etc, compression ratio) along with data, time and author directly in the image file.
Re:So its a trade off against computation? (Score:2)
Re:PNG? (Score:4, Informative)
Sorry, try again. An image compessed with PNG (even at the highest compression setting) will tend be considerably larger than the image compresed with JPEG. What PNG gives you is lossless compression and an alpha channel (that's not even properly supported in many browsers).
Re:Plugin for IE? (Score:2)
Re:Plugin for IE? (Score:2)
Yes but this change "needed" to happen because MS managed to become the big player, and didn't want people writing plugins that would work with MSIE and Netscape, they wanted them to write a MSIE only ActiveX control, and then decide the extra effort needed to support Netscape wasn't worth it.
It's not like oh, say, dropping a.out because it doesn't support all the debugging symbols you might need, or it is hard to support shared libs with a.out...in that case you are really buying something for your pain. In MSIE's case they are getting something for your pain, and what they are getting is more pain for you.
Not my idea of a good deal, but if you like it, go for it.
Re:Plugin for IE? (Score:2)
Re:Plugin for IE? (Score:2)
That may be, but that alone isn't a reason to drop support of the plugins.
Re:Plugin for IE? (Score:4, Informative)
Um, no. I don't want to upgrade to a browser by a company who wants to bend standards in their favor, leaving other browsers unable to cope. The advantage to Netscape Style Plug-ins over ActiveX controls is that they play in other browsers like Netscape (DUH!) and Opera. This isn't a case of an old standard no longer being followed, it's a case of MS changing the de-facto standard so that IE remains dominant. So no, I'm not willing to change browser/OS/etc over this.
Now that IE doesn't support non-standard controls, this means that anybody who makes an IE plug-in is stuck making an ActiveX interface.
My favorite browser is Opera. It doesn't support ActiveX. According to their site, it won't support ActiveX. Here's a quote:
"Opera does not support ActiveX, nor does it support VBScript. There are three reasons for this:
Opera Software AS is committed to supporting open Internet standards, recommended by the W3C, something neither ActiveX nor VBScript, being license issued Microsoft technologies, are.
The second reason is much more simple: There's just not enough market demand for these technologies to warrant the cost of implementing them.
In addition, some reports raise the question of how secure ActiveX is. It has been claimed that ActiveX has serious problems with security, and some even say that the problem is an almost complete lack of security. The same concerns have been raised about VBScript."
So besides making me stick with an insecure plug-in interface, what other reason is there for me to go to IE6 or newer?
"Changes sometimes need to happen, and given that by the time the change to 6.0 happened there was no plugin that I ever ran into that didn't have an ActiveX version, there's no reason for your ranting. "
Changes? Sure! But to disable a widely used technology? Uh uh. Sorry. I'm not rolling over and taking that. True narrowmindedness would be if I were to say "Okay Microsoft, thank you for making the choice for me. You know more than I do!"
As for not being able to get an ActiveX version of a plug-in, I can give you an example: The company I work for. (Who shall remain nameless.)
IE 6's betas supported our plug-in just fine. And then, once it was released, I had customers telling me it no longer worked. Somewhere between beta 2 and release they removed support for it. Did they tell us (a registerred MS Developer...)? No. They just did it. Their knowledge base called the removal of Netscape Style Plugins 'a security feature."
Interesting, I guess not being able to run as much stuff means less chance of security breach. Whatever. Maybe if MS had said "In 6 months when IE 6 is released, it won't support NSP's" Id have little room to gripe. But MS just did it. So my company (a startup company I might add) is forced to write an ActiveX control. We looked into it, and its not as easy as it may seem. For one thing, our product has a lot of web-based features that would all need to be rigourously tested. Since browser functionality is not our core focus right now, we don't have the engineering time to spend on it. Do our customers understand that? Only after I explain our priorities to them.
The worst part is that IE doesn't give any clue as to what is wrong. The behaviour of running a NSP on IE is the same as not having a plugin installed at all! What a wonderful way to prevent MS from getting customer service complaints!
In any case, thanks for calling me narrow-minded even though it's pretty obvious I know more about this topic than you do.
Getting back to the original topic, I hope the JPEG2000 group releases a Netscape Style Plugin so I can use it with Opera. I am geninuinely concerned that what they'll do is release an ActiveX version because IE is the dominant browser, and that's it. If they do that, they'll be further supporting MS's dominance. Unfortunately, I can see JPEG2000 causing that if the images are really as compressed as they say.
Re:Plugin for IE? (Score:2)
You'll give a flip when you decide to switch to a new browser (or a new OS that doesn't have IE on it) and half the internet doesn't work for you.
I can't believe people are actually responding with "It's okay that the internet only works with IE!", did I wander off of Slashdot and not realize it?
Re:Why plug-ins? (Score:2)
Re:extension? what do we need the extension for? (Score:2)
Heck, I don't see why there should be any more than one file type for still pictures (or audio, or video, or indeed any media in general), with an internal marker indicating what the file format and compression is. Having to worry about changing a reference to a file (say on a web page) because you changed the file type and therefore the name is a pain.
Re:extension? what do we need the extension for? (Score:2)