Slashdot Mirror

Yes, but H.265 is a video compression format. I dont't think they are going to take videos with the OSIRIS camera (or any of the other instruments) nor transmit video data back to earth.

Anyway, after some googling one finds that the most advanced image compression formats are based on some form of wavelet transform.
Examples would be JPEG 2000, JPEG LS and ICER. All of them predate 2004 but have seen some improvement over the last years. ICER was used on the mars exploration rovers, so it could be they use something similar on the rosetta probe.
Their compression rates are all very similar and differ only in their compational efficiency. Some comparisons can be found in this paper and here (homepage of the MRP Format (Minimum-Rate Predictors), which marginally outperforms JPEG formats but only on 8bit grayscale images).
The latter also compares against JPEG XR or HD Photo from Microsoft which was released in 2009 but seems to perform worse than JPEG-LS.

I don't see any advances in still image compression since 2004 that I would describe as huge, but that view is just based on a quick internet research. I'd be happy to change my mind on this.
Maybe NASA or ESA have been working on something much better and I just missed it (I didn't check patent databases).

You can generally pay some amount and get an ISO document - for the JBIG2 standard document I think it was something like 180 CHF.

According to JPEG (the standards group, not the file format)

There is a difference between the (patented) arithmetic coders used in JBIG and the later JBIG2 standards. JBIG uses the QM-Coder and JBIG2 uses MQ-Coder. They are not technically the same. It is believed that patents for the QM-Coder are owned by three organaizations (IBM, Mitsubishi, and Lucent) and patents for the MQ-Coder are owned by two organizations (IBM and Mitsubishi) .

Free licenses should be available for MQ-Coder (used in JBIG2 and JPEG2000) although a license should still be requested, but one-time payments to three organizations are necessary for QM-Coder (used in JBIG and JPEG-Arithmetic). At one stage these were of the order of a single one time license fee of 5000 US$, but the relevant companies should be contacted for their current pricing. If these have changed substantially, we would appreciate it if you could inform the webmaster so that the site can be updated accordingly.

Our understanding is that the license conditions of these coders are limited to the case where products are fully compatible to the standards. However, if it looks like you are within the academic sector and if you implement the coder for purely academic purposes (not for commercial use), you may be able to get free licenses.

No they aren't - JPEG is covered by lots of patents.

Here's what JPEG has to say:

It has always been a strong goal of the JPEG committee that its standards should be implementable in their baseline form without payment of royalty and license fees, and the committee would like to record their disappointment that some organisations appear to be working in conflict with this goal. Considerable time has been spent in committee in attempting to either arrange licensing on these terms, or in avoiding existing intellectual property, and many hundreds of organisations and academic communities have supported us in our work.

"Microsoft *has* been commissioned by the JPEG working group to develop JPEG XR .. as the next-gen photo image standard"

"One important aspect regarding the standardization of HD Photo is Microsoft's commitment to make its patents that are required to implement the specification available without charge"

I do believe I see where this INNOVA~1 is going, total control of the TUBES .. ;)

I would not consider myself an expert, but this is my field, so let me give everyone a REALLY quick lesson in 1) JPEG2000 and 2) "lossy" video compression.

JPEG2000 is an advanced set of tools for video compression. It is used at the highest levels of distribution, and has been proposed for consumer use as is the case here. For more on JPEG2000 a decent primer is here.

If you are watching content at home, it already has gone through a "lossy" compression scheme. Whether it is DTH satellite MPEG2 or MPEG4), cable (MPEG2/NTSC - yes NTSC is a lossy compression scheme), or terrestrial (MPEG2 ATSC or NTSC), DVD (MPEG2), or even LaserDisc (NTSC), your content has gone through a lossy scheme.

Remember, Google is your friend, and although not perfect, wikipedia can answer many questions. For more on video compression here is a nice little presentation.

The short story is everyone shouldn't get real upset about JPEG2000 and it being lossy. Cheers.

"Just completely skip the quantization step (or, equivalently, use a quantization matrix of ones) and you've got lossless."

Not exactly. It's close, but it's not lossless. The reason for this is that the DCT is not fully reversible, and even if it were, the JPEG standard does not have a precision standard for the DCT/IDCT in encoders/decoders (not even IEEE-1180 like MPEG1/MPEG2), which means that there can be quite large differences between different encoders/decoders.

And JPEG-LS doesn't even use the DCT...

http://www.jpeg.org/jpeg/jpegls.html

Well, there is JPEG 2000 and its your loss if you don't use it http://www.jpeg.org/jpeg2000/

The amazing, unbelievable thing made me "shrug" is they have the face to use "professional" word. I shouldn't RTFM really.

Professionals use RAW. RAW you hear me Microsoft? Also they use TIFF for transport. That is the established non lossy standard with some weird extensions, file variations. That is also why professional photographers will be the first Blu Ray recorder customers.

Nobody, nobody can dare to lose a PIXEL, single PIXEL. That is how you work in professional World.

Dear BillG if you are reading this: FIRE whoever came with that idea. Even Microsoft does not deserve to be robbed like that.

And people here (at geek sites) joked when Allume managed to come up with a lossless jpeg compressor. The camera manufacturer and memory manufacturer CARTEL insists on using JPEG , that is how you sell people 1 gigabyte memory cards but it is up to customer asking for jpeg 2000 format on equipment they buy.

So, there is still JPEG, one company (one of their interns I heard) managed to compress it by 30% levels and people joked about them. http://hardware.slashdot.org/article.pl?sid=05/01/ 12/0725217

Here is World's billions of dollars company coming up with a lossy format for PROFESSIONALS. I can only *shrug* sorry.

Please Microsoft, introduce your "format" to professionals who has nothing to do with your businesses and watch them laugh at you.

Even end users know RAW format.

I think you're confusing JPEG with JPEG-LS. Yes, they are both "JPEG"s but I don't think many applications natively support JPEG-LS. In fact, I wanted to use it in Photoshop and had to go get a plug-in. Whether or not JPEG-LS is as efficient as the new proposed MS format, I do not know. I think that JPEG-LS was slow to catch on because people just didn't care about upgrading their software to use it. I would wager that Microsoft will force third party software to support their new filetype.

I'm not even sure if my browser supports JPEG-LS and I know that programming with JPEG-LS can be a pain if you're looking for libraries to read/write lossless compression image files.

Whatever happened to jpeg 2000? I remember hearing about this when 2000 would have been an appropriate suffix for its name... http://www.jpeg.org/jpeg2000/index.html

I'm still waiting for the one who uses the JPEG 2000 format.
Digital photography would really be an appropriate use of this technology.

JPEG 2000 is a perfect example of why such patents need to be fought. Nobody will ever adopt it, or formats like it, while there are such legal swords of Damocles threatening them. Look here, where apparently the JPEG group seems to have given up on the idea of certifying that JPEG is patent-safe.

This first came out in 2002.

http://www.jpeg.org/newsrel1.html

Does anyone have a link to their archive of prior art, or any other listing of prior art for this patent? A cursory googling didn't turn up the results I was looking for.

I guess it took a few years before they built up a sufficiently strong case, as well as a sufficiently strong war chest to take on a corporate bully. Good luck to Pub Pat.

Lossless JPEG2000 would be an excellent choice for this.

Then you will be looking forward to more widespread use of JPEG-2000 and its associated JPIP protocol which provides progressive quality and interactive (multi-resolution and spatial random access) streaming delivery of (up to, depending on how long you wait) loss-less quality images over something like a 9600 bps GSM link.
Multi-GigaPixel images are not a problem, assuming you don't need to see every pixel in full loss-less quality. Typical loss-less compression is about 2 or 3 to 1. Lossy is pretty good down to about 1 to 0.5 bits per pixel.
Encoding on one of these machines might be a bit of a chore, but viewing with a JPIP client would be quite plausible, if one is ported.
Check out http://www.kakadusoftware.com/ for some JPEG-2000 command line tools (non-Windows users will probably be disappointed with the lack of a JPIP viewer) and http://jpeg.org/jpeg2000/.

I think Forgent is playing a SCO tactic here; I have looked at the original patent and conclude that it is not patenting JPEG. In more detail, anything that JPEG uses which is detailed in this patent was discovered by somone besides the "inventor" of this patent.

Forgent doesn't have a leg to stand on; as soon as this case hits the court room, this bogus patent will be declared invalid. The JPEG's group response to this nonsense patent.

JPEG2000 also supports a lossless wavelet compression mode. But yes, the 'lossy' version of JPEG2000 is supposedly better quality than traditional JPEG.

http://www.jpeg.org/faq.phtml

http://www.jpeg.org/jpeg2000/j2kpart1.html

It has already been done. I use it all the time on OS X instead of TIFF.

http://www.jpeg.org/jpeg2000/

I really don't understand why the camera etc companies doesn't adopt it.

Documented where? And don't say "do a Google search". The government needs to know that information will still be around in 50 years. And they need to store it themselves.

Documented in an ISO standard back in 1986. All any government needs to do is store a hard copy of the JFIF format and source code along with their backups and re-implementation won't be a big concern even 50 years from now.

For that matter, why aren't we seeing J2k everywhere? It looks like a great format.

I can think of two successors to JPEG...

JPEG 2000

JPEG 2000 is "the" successor to JPEG (designed by the same team), and was noticeably better than JPEG when I checked out quality vs size, but it's patent encumbered. It is however intended to be royalty and license-fee free.

Elysium Ltd has developed a freeware Netscape plugin to make IE, Opera and Netscape browsers able to view JPEG 2000 pictures. This plugin is for Windows, and I don't really know if there are others for other platforms.

DjVu

DjVu was designed for the web to replace common formats like JPEG, GIF and TIFF. Although designed primarly for compressing text, it's very efficient at regular photos as well, and should compress similarly as JPEG 2000 (about half the size of JPEG with similar quality).

DjVuLibre is a GPL licensed open source implementation that includes plugins, viewers, and encoders for this format.

Check the site yourself, and try to find any pledge from them that the specifications for JPEG or JPEG2000 are safe to use.

...even though the Joint Photographic Experts Group tried to create a format that wasn't encumbered by patents. Where will the madness end?

I would suspect that camera developers chose JPG because it was a specification from the Joint Photographers Group (hence it's name).

If you are going to sell something to photographers, you want to tie it to a standard that photographers are expected to approve of.

Interesting, but I bet most digital photographers don't really know much about the JPEG or why they matter. JPEG was effectively a standard for lossy true-color images long before digital cameras were common. When digital cameras became common, it was only natural to pick the most widely accepted lossy true-color format.

(For most users, it's not practical to store a lossless image. However, as storage gets cheaper and cheaper, it's becoming more common. However, high end cameras generally have their own custom "raw" format designed to preserve as much data as the camera can generate.)

1. Support for JPEG2000. This would allow better quality images with less bandwidth than the older JPEG standard.
2. Support for SVG (Scalable Vector Graphics). This would allow web applications to draw high quality graphics without consuming as many resources as Java applets.
3. Showing animated GIFs at the frame rate specified. IE6 still slows down GIF frames that should be shown for less than 1/20 of a second, limiting the quality of animation.

I am not a professional photographer (I know few though) but rather take photos as a hobby (and as the unofficial photographer for family events). I haven't moved to the digital side yet, but I am looking (I'm looking at a Minolta that is still in the $1000 range). For all the research that I have done, the megapixels is not the most important point, but rather the features of the camera, namely the ability to use the various lenses I already have for my SLR.

Depending on what a person is planning to do with the picture, the higher MP may create an extra step. If you take a full resolution picture, your not going to be sending a bunch of these around as email attachments. If you are posting to the web though, you could look at creating thumbnails or working with various image compression and/or "pyramid" files (check out Lizard Tech's MrSID image format, although this is more for often seen in GIS or document management environments or consider JPEG 2000).

Whle most of the market will be happy with the 2 - 3 MP camera, as long as prices continue to drop you'll find more buying the higher end cameras (which is a good situation to drive prices down even more).

Ok, use JPEG 2000. Has virtually nothing in common with JPEG other than being a lossy image compression format. Unfortunately, there are patent issues there too, but at least they're different patents.

And wavelets beat the pants off of DCT.

The sooner we get JPEG 2000, the better. What's taking them so long, anyway? They're already four years late (going by the name).

Number one: Noone seems to think this patent is applicable, we've been over this already. The JPEG group says (in diplomatic terms) that they have prior art.

Number two: What is to be gained by going after the Gimp? Want to becoming the next SCO? Only there is even less money in the Gimp than in Linux.

AFAICT it compresses better than JPEG, is patent-free, also compresses selected areas of the image [big PDF, see part 6] differently for better effect, and (hooraw!) believes in an Alpha channel and other "sideband" information.

JPEG 2000 requires all JPEG members to agree on RAND licensing for any essential patents they own that apply to the JPEG 2000 standard and royalty-free licensing for any such patents that apply to the "baseline" subset of the standard.

"WG 1 requires all participants within all National Bodies to disclose and identify any and all patent rights and the specific technologies within the Verification Model to which they apply. Further, WG 1 requires this disclosure and identification at the time of submission of technology for VM consideration if submitted by the patent holder or no later than one meeting after submission of technology if the technology is not submitted by the patent holder. Further, WG 1 requires that the form contained in WG 1 N1267 be completed as part of this disclosure. This request is in accordance with ISO/IEC directives Part II, Annex A, Section A.2. ...
"SC 29 affirms and supports ISO policy that requires disclosure of the existence of Intellectual Property (IP) rights or pending rights (such as patents or pending patent applications), hereafter referred to as "IP rights", associated with any technology submitted to SC 29/WGs for consideration for inclusion in any ISO/IEC standard. Specifically, SC 29 affirms the ISO policy of only considering technology that is free of "IP rights" or which is available on a royalty and license fee free basis or which is available under reasonable terms and conditions on a non-discriminatory basis. " ...
In 2002, it became widely publicised that one or more companies were making claims in some countries that they had patents which they believed read on the original JPEG standard IS10918-1. The JPEG Committee produces standards, which have a global basis, and are unable to comment on the validity of such claims, or potential infringement by particular implementations within specific jurisdictions. No such claims have (at January 2004) been registered formally through the appropriate channels at ISO and ITU-T, so far as the Webmaster is aware. In an attempt to provide as much technical background as possible to assist companies approached concerning such patent claims, JPEG have assembled a Historical Archive of as much material as possible, which helps show how decisions were taken, what the technical inputs were behind those decisions, and some of the background information concerning the involvement of companies and individuals in the standardisation process. These are currently provided without further commentary as a service to members of the JPEG committee only, primarily for copyright reasons.

There so many things wrong with this post it's hard to decide where to bite. And at AC too...I feel foolish even typing this, but...

In the context of an image file, the datum(*) is the image. The metadata is information that is describing that datum. Whether it is stored in the file or outside the file is irrelevant, conceptually. I could have a text file, then I could write some metadata describing the text across various defined categories (Dublin core fields, perhaps). I could store this in another file. Then I could concat the two files into one. What do I have? One file, two files, doesn't matter essentially. Conceptually I have a datum, and metadata. Regardless. To me, storing metadata in the same file as the datum itself is MUCH MUCH more sensible as it keeps everything together. You can't lose or unlink to associated files / databases etc. Unfortunately, the format du jour, the JFIF (JPEG basically) is not very rich in this regard. SPIFF is way better, as is GIF and PNG The concept itself is very, very good and has not yet come of age. The file formats are improving their capability in this regard.

A great search capability can be made with internal metadata just as easily. More so, perhaps. There are only a few image formats to worry about, so it isn't that hard to support them all.

And, files can be objects, dumbass. At least, they absolutely can be static representations of objects, dumberass.

On a personal note, you are a ignorant jerk. Go away. Irritant.

(* or data, as you prefer)

--

Slashdot sucks

(No, I didn't forget PNG. It has some technical and ideological advantages, but browser support is still, well, incomplete.)

So what's wrong with SVG plugins? They don't exploit the full power of SVG. It's not just a graphics format, it's an XML application. In other words, it's a markup language, just like HTML. A good XML-aware browser (something both IE and Mozilla pretend to be) shouldn't isolate SVG from the rest of the document.

Consider the gif-filled Slashdot page you're looking at right now. They have gotten rid of a lot of bitmaps (though the left hand clickbar looks slightly less cool as a result). But they still use some weird little bitmaps, plus a lot of weird tables and font kludges that are hard to maintain and tend to be browser dependent.

There's a simple fix: put SVG support in the browser (it is a W3C invention after all) and allow indiscriminate embedding of XHTML and SVG in each other. (Not to mention any other XML applications the browser happens to support.) The Mozilla people know this, but still consider SVG support experimental and non-standard. This has been the status quo for quite some time, and given AOL's abandonment of Gecko, is not likely to change.

Maybe if Mozilla had concentrated on basic technological improvements like this and less on eye-candy and silly features... well, AOL, would probably still have screwed them over. But I might feel bad about it.

KHTML looks to be the new leader in open-source web browsers. And their does seem to be a lot of interest in using the engine to render SVG. Alas, the KDE people still think of SVG as something you embed in something else.

1. Oppose the expansion of software patents to your country, if such patents are not available there now.
2. Insist that standards bodies in which you participate make an an "innovation compatible" (IC) license a requirement for any patents needed to implement a standard.
3. Develop and support software that works with non-patented file formats and network protocols, instead of patent-encumbered ones.

Am I the only one who thinks the ISO should stand up and fight the good fight?

It isn't in any way ISO's job to fight patents.

The JPEG people (remember, JPEG is the Joint Photograpphic Experts Group, not just a compression standard) are the ones who will fight the good fight--them and their members. JPEG itself can only do inexpensive things, and probably couldn't force a lawsuit even if they had the money. What they can do is organize their members (who do have money) into working together in the pursuit of evidence that the patent claims are invalid. which is what they are doing .

What about patents not applying if the implementation is open source and not-for-profit?

There is a relatively new area of law, equitable estopple (spelling? eh, IANAL, so don't need to write it), which covers this. In this situation it more or less says that given that the owners of the patent knew (or should have known) that their tech was being incorporated into a free standard, they should have spoken up then, and can't now. Letting someone incorporate your IP into a standard, and letting them believe that they hadn't, is a no-no. Refusing to let them use it is OK, but you have to speak up quickly.

Additionally, there is the defense of laches, which more generally covers not enforcing a patent for a long time. If, given you had been reasonably diligent, you would have been aware of infringement (or you actually were aware), and you do nothing for a long time (6 years is the standard, more or less by situation), then you forfeit your enforcement rights for past infringement. A quote I saw on it went like "Those who sleep on their rights can't expect to exercise them."

The logo on the JPEG homepage is actually a gif.

The full text of the Patent (US4689672) can be found here. It was filed in 1986.

The Joint Photographic Experts Group Committee published the JPEG standard in 1994. While JPEG files were used prior to the publishing of the standard, it's pretty clear that JPEG images themselves don't count as prior art regarding this patent.

This patent appears to me to cover RLE files (claim 1). This strikes me as likely to have prior art.

This patent appears to me to cover a simlple scheme one step removed from Huffman encoding (claim 6). This also seems likely to have prior art.

If someone can find prior art for claims 1, 6, 13, 25, 30, 36, 38, 39 and 42, the entire patent seems likely to fall apart, since every claim is dependant on those few.

"A basic version of the many features of this standard, in association with a file format placed into the public domain by C-Cube Microsystems (JFIF) is what most people think of as JPEG!"

Doesn't JPEG stand for Joint Photographic Experts Group ? Isn't this the group that came up with the JPEG format in the first place?

According to JPEG what most of us believe to be JPEG files are actually JFIF which are royalty free thanks to C-Cube Microsystems. So Forgent Might not be due that much in royalties after all.

This might be a good thing after all. The restrictions on GIFs spawned a much better file format (PNG). This could do the same for Lossy Images.

It is rediculious to think that Forgent Corp owns the JPEG data compression technology. Many movements and groups have contributed to improve JPEG compression. For example, the Independent JPEG Group is an independent group that writes and distributes a widely used free library for JPEG image compression. Their website features the source code and some documentation.
More information can be found on the ISO JPEG standards committee webpage.
-Tom

Okay, can someone clear this up for me... according to the JPEG FAQ: "JPEG (pronounced "jay-peg") is a standardized image compression mechanism. JPEG stands for Joint Photographic Experts Group, the original name of the committee that wrote the standard."

The JPE group is a sub-committee of the ISO organization, see here. They claim that: "... a basic version of the many features of this standard, in association with a file format placed into the public domain by C-Cube Microsystems (JFIF) is what most people think of as JPEG."

So if the ISO experts group wrote the standard, how come it could be patented by this company? Is C-Cube somehow a part of or associated with Forgent? Surely placing the algorithm in the public domain is at least prior art that will invalidate this patent?

What am I missing here?

The image TechFitsYou.jpg (the bottom of the article) should be saved as a PNG, instead of JPEG (just a 4 or 8 color PNG would look great and would be small, while the highly compressed JPEG looks terrible). The same with the header logo (Header_wireless_everywear.jpg) and the photos (charmit.jpg, CharmITTwiddler146.jpg). If someone knows the webmaster, please tell her/him about it, because it looks very unprofessional. And while I believe that they know the technology and I can believe them about this product, if I hadn't read the Slashdot comments I wouldn't be so sure. Thanks.

This article was not intended to be read by experienced webmasters with knowledge in the area of JPG compression, but webmasters who don't know how to tweak images by compressing them...

/. is for experienced webmasters (and maybe even web developers, too). This article, on the other hand, is for newbies hacking their first pages in Front Page, complete with flaming titles, blinking text, and loud backgrounds. These people are not web developers (let alone web masters, god forbid), no more than my mother's a computer scientist cuz she programmed her VCR to record Murder She Wrote reruns. These people sure as hell don't read /. This article does not belong anywhere on /., especially not the front page. It's insulting to the readership.

Additionally, basic JPEG sucks and I don't condone singing its praises. It introduces artifacts and destroys the image. It might be fine for pretty graphics that GIF won't do justice to, or thumbnails in a photo gallery. But, to deliver high quality images (photos, wallpapers, or scientific imagery) it's a lousy choice, but the only one if you want your users to view the data in their browsers.

As for JPEG 2000, wavelet technology is already in use (such as LizardTech's MrSid software, which is not unimpressive). Certainly a fun and interesting idea, but it takes longer to decode and doesn't compress near as well as PNG (90k PDF). Considering how long it's taken PNG to gain acceptance (I'm still not convinced there's enough browser support to use pure PNG on my sites), I'm not holding my breath for JPEG 2000 as a web medium, and looking at the numbers, I'll take PNG over JPEG in a heartbeat.

Your argument fails just like the video manufacter that tried to give an open source version of their driver by running the code through the pre-processor first. People took one look at that and said it was rubbish.

Or how about the other guy who said his company wanted to release their code after running it through an obfusucator. Changing every variable and word with some random characters?

And what the hell is the deal with luratech? If you go to jpeg.org you'll see that there are 3 other companies supplying code. There is jasper which seems to be pretty good.

And obviously you have not worked with jp2k otherwise you would know that it is more complicated than saying give me an 80% quality image.

And no I don't work for anyone.

t.

Your argument fails just like the video manufacter that tried to give an open source version of their driver by running the code through the pre-processor first. People took one look at that and said it was rubbish.

Or how about the other guy who said his company wanted to release their code after running it through an obfusucator. Changing every variable and word with some random characters?

And what the hell is the deal with luratech? If you go to jpeg.org you'll see that there are 3 other companies supplying code. There is jasper which seems to be pretty good.

And obviously you have not worked with jp2k otherwise you would know that it is more complicated than saying give me an 80% quality image.

And no I don't work for anyone.

t.

The Joint Picture Experts Group has a very nice applet available to demonstrate this, but they put it in a ZIP file for some reason, so you can't directly execute it in the browser. I have posted the applet here, with a slight modification to use an image borrowed from CmdrTaco's really crappy movie.

Enjoy!,
Jouster

Actually, they use a lossy wavelet compression multiple times, until they've produced a perfect image.

The JPEG has a very nice applet which explains everything, but it is unfortunately stuck inside a ZIP file (why do you make an applet, then put it in a ZIP?). At any rate, I've posted a working copy here.

Enjoy!,
Jouster

The jpeg2000 page that both links in the story refer to has not been updated in a while, as can be seen by going to the wayback machine page and typing in the url to get the revision history. The current page seems to have been last updated in October 2001. And this last edit seems little more than a book ad and background color change:) How is the statement "These free plug-in's are expected to be available later this year." backed up?

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