Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

State of the JPEG2000 Standard?

Cliff posted more than 10 years ago | from the image-revolutions dept.

Data Storage 97

ehb asks: "With all the (r)evolutions going on in networking (IPv6), video (MPEG4/H.264) and audio (MPEG4 AAC), I was wondering what happened to that big image compression promise of some years ago: JPEG2000. According to the official JPEG2000 page, although the entire standard not is completed, the important parts are, which would allow JPEG2000 to function as a still-image replacement for the old JPEG! I have seen lists of software programs that implement (parts?) of the JPEG2000 specification, but missed the important ones (web browsers, etc). There even exists an Open source implementation of the codec, so what is holding everything back? The benefits over normal JPEGs are huge, so can someone shed some light on the hold-up?" Back in April of 2002, JPEG2000 was "coming soon", and it was touted as being the "the future of imaging", but after that the hype seems to have dried up. What happened to this promising specification? Did another format surpass it (PNG, perhaps)?

cancel ×

97 comments

Sorry! There are no comments related to the filter you selected.

Inertia (2, Insightful)

Blackknight (25168) | more than 10 years ago | (#8048954)

For most people JPEG is "good enough", so it's not worth the effort to swtich everything to use jpeg2000.

Re:Inertia (3, Insightful)

Directrix1 (157787) | more than 10 years ago | (#8049036)

Well, for one JPEG2000 takes forever to encode/decode. There are some really complex computations going on in the background, and regular JPEG is much faster (although the quality isn't nearly as good). As far as PNG goes, the best compression it can get is JPEG'd data. Another interesting where is it is the MNG. The supposed replacement for the animated GIF is barely supported anywhere, and for some reason Mozilla just recently REMOVED support of it.

Quality and speed (1)

fm6 (162816) | more than 10 years ago | (#8049369)

regular JPEG is much faster (although the quality isn't nearly as good)
I guess I've never seen any graphics that actually showed up this difference in quality. (Links anyone?) Perhaps I'm mistaken, but I wouldn't think that any improvement on JPEGs would be noticable on a typical monitor, where the pixel density is almost always less than 100 dpi.

Commercial printers could use that extra image quality, but that's not the kind of software most of us would have contact with.

Re:Quality and speed (2, Informative)

escher (3402) | more than 10 years ago | (#8049492)

I think the main improvement would be smaller files at the same image quality.

Re:Quality and speed (1)

Directrix1 (157787) | more than 10 years ago | (#8051854)

Actually, the main improvement is the fact that JPEG2000 is capable of lossless encoding. Even at lossless, it still knocks the file size considerably down (depending on image complexity).

Re:Quality and speed (1)

spectral (158121) | more than 10 years ago | (#8049942)

There's plenty of issues with it. JPEG a screen full of text, and tell me it looks good. JPEG has the same issues as MPEG does: mostly solid color areas are blocky (if there's a slow gradient it'll be most noticeable), and edges are crap. It's made for pictures and photos, where such issues aren't as noticeable. JPEG2000 prolly won't do good on text screens either (again, it's not what it's designed for), but the file size is much smaller. JPEGS are already small, but I once saw a picture of a starburst effect behind a wineglass. The JPEG2000 version was like a tenth the size of the JPEG version, if I recall correctly.

There's also issues with the JPEG chroma subsampling, but that's usually encoder dependent.

Re:Quality and speed (1)

Directrix1 (157787) | more than 10 years ago | (#8051870)

Well, since JPEG2000 can do lossless encoding it should be able to perfectly reproduce text. Whether it does it efficiently or not, I'd have to run a test down at work to see for sure.

Re:Quality and speed (1)

fm6 (162816) | more than 10 years ago | (#8052011)

JPEG a screen full of text, and tell me it looks good.... JPEG2000 prolly won't do good on text screens either (again, it's not what it's designed for)...
Since we're talking JPEG versus JPEG2000, why are we even talking about text?

Re:Quality and speed (1)

Drantin (569921) | more than 10 years ago | (#8052170)

He's talking about an image of text... not a text file...

Re:Quality and speed (1)

fm6 (162816) | more than 10 years ago | (#8052211)

Well duh.

Images of text (1)

tepples (727027) | more than 10 years ago | (#8064165)

I can think of a few good reasons for compressing an image of text, including without limitation the following:

Re:Images of text (1)

fm6 (162816) | more than 10 years ago | (#8072395)

The lamest post on a very lame thread. Where did I say, "images of text don't need to be compressed"??

Re:Images of text (1)

tepples (727027) | more than 10 years ago | (#8072733)

I apologize for allegedly misinterpreting your "why are we even talking about text?" question. What exactly did you intend those words to mean?

Re:Images of text (1)

fm6 (162816) | more than 10 years ago | (#8073404)

Read the thread.

Re:Quality and speed (2, Informative)

damiam (409504) | more than 10 years ago | (#8051262)

JPEG has adjustable compression. It's possible to create a near-lossless JPEG image (at enormous file sizes), and it's possible to compress a 25 megapixel photo down to 2 kilobytes (at horrendous quality). Most people, when compressing JPEGs for the web, attempt to get the smallest possible file size while retaining reasonable quality. JPEG2000's better compression allows for the same good-enough quality at much lower filesizes. That's why it's useful.

Re:Quality and speed (1)

jovlinger (55075) | more than 10 years ago | (#8069435)

Well, there are limits to how well jpg can do, even at the highest setting. The setting only controls how the DCT co-efficients are quantized. Out of your control is 1) the Chroma subsampling (color is a half the rez, both h and v, of intensity) 2) the DCT coefficients are rounded to integer values, 3) (I think, long time ago) there are hardcoded quantization tables as a first pass.

So even if you turn it all the way up, there will be significant loss. Of course, for some images, that is ok: a flat color will be losslessly compressed even at high compression.

Re:Inertia (0)

Anonymous Coward | more than 10 years ago | (#8050117)

MNG was removed from Mozilla due to a lack of a maintainer, low usage, and excessive size.

No. (2, Insightful)

Inoshiro (71693) | more than 10 years ago | (#8051151)

The best compression PNG can get is not JPEGed, since PNG is not a lossy encoding!

Re:No. (1)

Directrix1 (157787) | more than 10 years ago | (#8051839)

PNG is a tagged image format. It can be a lot of things, including lossy encoded. There are provisions that allow for inclusion of custom tags. I will refer you to the JNG Image Format [libpng.org] , which is just a couple of tags added to the reference PNG spec.

Removed (1)

tepples (727027) | more than 10 years ago | (#8064148)

Mozilla dropped JNG (essentially JPEG with a PNG alpha channel) along with the rest of MNG because 1. Mozilla's libmng had gone unmaintained for too long, and 2. when a new maintainer stepped up to rescue MNG, pavlov (the maintainer of libpr0n, the Mozilla image handling library) continued to complain about libmng's footprint.

Mozilla rejected Jasper (0)

Anonymous Coward | more than 10 years ago | (#8055712)

See Mozilla's Bugzilla bug 36351.

Jasper doesn't support incremental image decoding, it requires that the whole image is loaded before it's decoded - that's the main reason Mozilla didn't use Jasper.

Re:Inertia (2, Interesting)

dtfinch (661405) | more than 10 years ago | (#8049460)

JPEG2000 is better for images containing smooth gradients, while JPEG is better for textured surfaces. JPEG noticeably damages gradients at typical compression levels.

To me the problem with the JPEG2000 standard has been that it's become bloated. All many of us wanted was a replacement for JPEG that supported an alpha channel and optional wavelet compression.

My own thoughts (1)

dacarr (562277) | more than 10 years ago | (#8048966)

Perhaps it's because people have it set in their minds that a JPG is a JPG, and this is being touted as Yet Another Image Format. Same reason (I think) that PNG, though it is enjoying wide popularity against GIF, hasn't totally caught on yet.

Re:My own thoughts (3, Insightful)

idiotfromia (657688) | more than 10 years ago | (#8049174)

PNG hasn't caught on because Internet Explorer has yet to properly support it.

You can sign the petition for Internet Explorer PNG support [petitiononline.com] .

Re:My own thoughts (1)

Brandybuck (704397) | more than 10 years ago | (#8049296)

Well, they used to support at least flat images. Now IExploder won't show any PNGs at all! It's decreased in functionality. Microsoft certainly knows how to display PNGs, because you right-click on the blank spots, and the Image Viewer shows them fine.

At least issue a plugin!

What version of IE are you using? (1)

ttfkam (37064) | more than 10 years ago | (#8049520)

I'm using 6.0 and I can see PNGs just fine. Well...as well as IE ever did.

Re:What version of IE are you using? (1)

Curtman (556920) | more than 10 years ago | (#8052501)

Try looking at these [tephras.com] in IE, then in a browser without broken PNG support. Funny thing is, PNG support is much better in IE on the Mac than it is in Windows. I wonder what that's about.

Re:What version of IE are you using? (1)

ttfkam (37064) | more than 10 years ago | (#8052883)

I can see the images. The background transparency is busted (a bluish gray slate), but I see the images.

Sure they look much better in Firebird (and basically every other browser), but this is a far cry from not showing PNGs at all.

Re:What version of IE are you using? (1)

Curtman (556920) | more than 10 years ago | (#8055313)

Who said they wouldn't display? They are broken though.

Re:What version of IE are you using? (1)

Brandybuck (704397) | more than 10 years ago | (#8057570)

I'm not seeing them at all. This is under the IE that comes with WindowsXP (home or pro). Seen the lack of PNGs on at least five systems. No special fiddling with any settings that I am aware of.

I used to be able to see PNGs under Win98 and 2K with whatever the IE they had was. But something's changed under either WinXP, or the IE that comes with it. The area where the PNG is shows empty. No "broken image" icon, no frame, no funny colors. Just blank.

Or am I just using the wrong "kind" of PNG's on my site? I converted these from GIF to PNG with either Gimp or gif2png. I don't have any alpha transparency at all. See me site for example, home page has one PNG in upper right corner.

Re:What version of IE are you using? (1)

Com2Kid (142006) | more than 10 years ago | (#8064224)

It can depend on if Quicktime has been installed / associated with PNG images or not, I have had Quicktime take over display of PNG images in the past, and break PNG images imbedded into webpages in creative ways.

Re:My own thoughts (1)

spectral (158121) | more than 10 years ago | (#8049995)

sounds like a personal issue. I use PNGs on my website wherever I would normally use a GIF. Works in IE4+ and mozilla, as long as I don't want alpha transparency. Which I do, so I'm prolly going to write in the DXFilter thing to automatically add it to each img tag that uses a png, so that it shows the alpha ones.. *shrug* Maybe some javascript to do it if possible. I've been too lazy to really look in to it, since I don't use IE. If my site validates and even vaguely resembles what it does in Mozilla, then I declare it a success. It's just a personal site, so it doesn't really matter that much.

Re:My own thoughts (1)

BobNET (119675) | more than 10 years ago | (#8050616)

It's already been done for you; check PNG in Windows IE [ntlworld.com] . It uses Javascript to rewrite any IMG elements containing PNG images as SPAN elements using DXImageTransform to enable the alpha channel. Obviously Javascript has to be enabled for it to work, though...

Re:My own thoughts (4, Informative)

JimDabell (42870) | more than 10 years ago | (#8049342)

PNG hasn't caught on because Internet Explorer has yet to properly support it.

PNG is as functional as non-animated GIF in Internet Explorer 5+, the problems are with a non-binary alpha value (totally opaque works, totally transparent works, nothing else does).

The gamma support is the only area where it fails against the GIF format for static images. Gamma correction is built into the PNG format, whereas GIF took the approach of "don't worry about it". Differing gamma correction means that you often get mismatched colours between PNGs and neighbouring coloured areas. In practice, you can solve this for everything but older versions of Safari and Opera by configuring your graphics editor to remove all gamma information.

For more information, read The Sad Story of PNG Gamma "Correction" [www.hut.fi] .

Re: gamma correction (2, Interesting)

spitzak (4019) | more than 10 years ago | (#8050397)

Thanks for that link on Gamma correction. It does seem that some people are finally getting it, I have been trying to get this idea across for years.

Numbers in the file should represent *specific* colors. Not some color in a "colorspace" that the file also gives. This is just like tagging text files with the "character set", it should be obvious now that making a single specification like UTF-8 is far more reliable and "just works".

I very much recommend using the sRGB standard to represent color levels in any file format storing an integer. Programs should *ALWAYS* copy these numbers unchanged to the screen framebuffer. Any attempt at any other solution means that colors will not match between programs.

That means all those colorimiters and printer matching profiles and other garbage you have been scammed into buying is useless. Too bad. You were taken. Even the authors of png were taken. And people who keep saying Gimp is no good because it lacks printer profiles are wrong (there are probably other problems with Gimp, but printer matching is a scam). I have worked in computer processed imagery (for special effects) for over 10 years and I damn well know what I am talking about, so don't go calling this a troll.

Re: gamma correction (1)

dave_f1m (602921) | more than 10 years ago | (#8050877)

Yeah, just adjust those pictures on your laptop screen, hmmm... that looks good, take them in to print, and wonder why it's so dark (if the lab didn't correct anything), or so low contrast (if they did). Don't worry about gamma, or matching your monitor or anything. Now, I happen to love sRGB, since that's pretty much what the Fuji Frontier I use uses, but I have a some people trying to adjust things on laptops (I'm thinking of someone in particular with a Sony), and it leads to many headaches till you get them in, show them the histogram in Photoshop (everything it the darkest fifth), and show them the print next to some cheap monitor with the color temp adjusted and the brightness/contrast roughed in, and explain, they need to take action.

Re: gamma correction (1)

captaineo (87164) | more than 10 years ago | (#8059570)

Color profiles and gamma serve different purposes... Gamma is about mapping pixel values to luminance, color profiles are mainly about dealing with devices that use different primaries.

In the video/film world we worry about gamma but don't care very much about differing primaries (we just "color correct" stuff until it "looks right" on the display). Whereas print graphics people obsess about primaries while pretty much ignoring gamma (they manually "gamma correct" stuff until it "looks right").

It's probably because video/film graphics only has to deal with a few sets of primaries (NTSC, Rec. 709, film stocks) whereas print people have to worry about a zillion different devices (every scanner, printer, etc). Gamma is vital in video to avoiding quantization artifacts and making dark areas look right. But in print the worry is "if I print a color image and then scan it back in, will the scanned colors visually match those on the paper?"

Perhaps one motivation for "embedded" color profiles is avoiding the need to transform 8-bit pixel values and thus introduce quantization artifacts.

Re: gamma correction (1)

mr3038 (121693) | more than 10 years ago | (#8061586)

Perhaps one motivation for "embedded" color profiles is avoiding the need to transform 8-bit pixel values and thus introduce quantization artifacts.

My thoughts exactly. Color profiles are only a cheap hack while we're waiting for 16 bit (or more) color channels. Once we have enough precision it doesn't matter if we have to transform between color spaces instead of tagging what different numbers are supposed to mean. And no, using 16 bit per channel doesn't take significantly more than 8 bit per channel when done right because we can use the magic of compression.

Re: gamma correction (1)

captaineo (87164) | more than 10 years ago | (#8064471)

I'm actually unsure about my earlier statement... Profiles would only save you part of the 8-bit computation - you still have to multiply the numbers *somewhere* - and you can always dither to minimize artifacts. (although it's surprising how few image-manipulation programs bother to dither... it can be done in about 4 lines of code for crying out loud...)

There is no perfect solution for dealing with matching primaries, because in the end three numbers aren't enough information to reconstruct the full spectrum of light. As soon as we get greater than 8 bits of depth, we'll have to start asking for more than 3 color components :)

Re: gamma correction (1)

mr3038 (121693) | more than 10 years ago | (#8064539)

There is no perfect solution for dealing with matching primaries, because in the end three numbers aren't enough information to reconstruct the full spectrum of light. As soon as we get greater than 8 bits of depth, we'll have to start asking for more than 3 color components :)

As human eye only has sensors for three wave lengths, three numbers should be enough to represent full spectrum of light, as much as we can perceive it. We just have two problems: 1) the currently used RGB model doesn't model the correct wave lengths - it's close but not perfect. 2) Every human eye has a little bit different construction. No human eye is perfect - so selecting three perfect wave lengths is impossible.

After saying that, I feel that RGB is still better color model than HSV, Lab, CMYK or all the other models available because RGB is closest match to human eye behavior. All we need is much more precision than 8 bit per color. 8 bit is barely enough to store final image, but if any computations are required (like alpha blending with another image) then more precision is needed.

Re: gamma correction (1)

Carnildo (712617) | more than 10 years ago | (#8068275)

As human eye only has sensors for three wave lengths, three numbers should be enough to represent full spectrum of light, as much as we can perceive it. We just have two problems: 1) the currently used RGB model doesn't model the correct wave lengths - it's close but not perfect. 2) Every human eye has a little bit different construction. No human eye is perfect - so selecting three perfect wave lengths is impossible.

Not quite true. The human eye is sensitive to three regions of the spectrum, centered around red, green, and blue. The overlap between the regions is what allows color mixing (such as the RGB model) to work.

After saying that, I feel that RGB is still better color model than HSV, Lab, CMYK or all the other models available because RGB is closest match to human eye behavior. All we need is much more precision than 8 bit per color. 8 bit is barely enough to store final image, but if any computations are required (like alpha blending with another image) then more precision is needed.

There's one model that's better than RGB for representing color: the CIE model. RGB has good coverage of shades of white, and of the saturated colors from red to green. It's lacking in the blue-greens, and can't handle a large section of the purples. The CIE model can handle every color the human eye can see. However, since it isn't based on a combination of three colors, it's much harder to work with hardware-wise.

Re: gamma correction (1)

ChaosDiscord (4913) | more than 10 years ago | (#8060653)

That means all those colorimiters and printer matching profiles and other garbage you have been scammed into buying is useless.

That's just silly. If you want really accurate color reproduction you want color correction profiles and the like. This, of course, is only a small subset of users, but some (people doing high-end photography come to mind) it's really critical.

Now, in theory 255,0,0 should always be pure red, but in practice you run into problems. Your screen has certain fundamental limitations on what it can reproduce. Those limitations are increased by the ambient light in the room you're working in; the brightness of your image appears different when viewed in differing levels of light. If you're switching light sources (from sunlight during the day to an incadenscent light in the event), hues can appear different. Of course, the quality of color off your monitor varies from model to model and from manufacturing batch to manufacturing batch. And over time you can expect the quality to slowly degrade. On top of all of this your printer has its own limitations and exact results will vary from printer to printer.

If you want damn near exact color matching between your monitor and your printer, you're going to have to do some work to calibrate things. Simply assuming 255,0,0 is a particular shade red everywhere isn't going to work.

Things also get wonky when moving from system to system. This is most striking when looking at a web site whose graphics have been created by a graphic designer working on a well calibrated Mac; Windows users will tend to see much darker images.

You might not see this in your area of expertise because you primarily work with people with well adjusted, non-crap equipment.

All that said, you're probably right that gamma correction in file formats is a bad idea. The only people who can possibly benefit from it (random users) never bother configuring things correctly anyway. And for people grumbling that the GIMP lacks this level of color adjustment, while's true that some people care, I know that at least some newspapers manage to print color photographs day-in and day-out without having ever calibrated their colors. It turns out most people can't tell.

Re:My own thoughts (1)

neur0maniak (322791) | more than 10 years ago | (#8050239)

I don't particularly create websites, as I do Intranet systems. I just recommend Firebird anytime someone complains about graphics.

Re:My own thoughts (3, Insightful)

nkodengar (622810) | more than 10 years ago | (#8049218)

Perhaps it's because people have it set in their minds that a JPG is a JPG, and this is being touted as Yet Another Image Format. Same reason (I think) that PNG, though it is enjoying wide popularity against GIF, hasn't totally caught on yet.

PNG images are fantastic if quality is an issue and bandwidth is not, the alpha transparency is also fantastic for web designers, and many fantastic effects can be done with it. Unfortunately only users with good web browsers will see the benefits of png transparency. Internet Explorer users just get an ugly grey background on thanks to M$ breaking proper png support a version or so ago... :(

Re:My own thoughts (1)

Phexro (9814) | more than 10 years ago | (#8049308)

It's a hack, but there is a fix [ntlworld.com] .

It works reasonably well for most cases.

Re: Quality vs. Size (1)

ttfkam (37064) | more than 10 years ago | (#8049556)

PNG compresses line art better than GIF. As for continuous tone images (JPEG's bread and butter), PNG falls behind. But then again, with line art, JPEG falls behind.

Right tool for right job and all of that...

transparency in PNG (2, Informative)

Tumbleweed (3706) | more than 10 years ago | (#8049572)

You're thinking of two different things. Transparency as in an 'indexed' transparent 'colour' works just fine in PNGs in IE. Alpha channel transparency, however, does not. The upshot is that PNG works just fine as a direct replacement for GIFs, including GIFs with transparency.

Re:transparency in PNG (1)

Kris_J (10111) | more than 10 years ago | (#8052599)

Except that all my experience has shown that PNGs are larger than GIFs for the same image (same colour depth, dithering, etc), especially for small iamges. I would have switched to PNG by now if it wasn't consistantly a bigger file.

Re:transparency in PNG (1)

Tumbleweed (3706) | more than 10 years ago | (#8052832)

What are you using to create your PNGs, and have you tried compressing them with pngout or pngcrush? (pngout is better, FYI)

But yes, the smaller the file (& fewer the colours), the less likely PNG will be to be smaller than GIF. Depends on the file.

Re:transparency in PNG (1)

Kris_J (10111) | more than 10 years ago | (#8053227)

I use Ulead Smartsaver Pro 3.0.

Re:transparency in PNG (1)

Tumbleweed (3706) | more than 10 years ago | (#8053525)

Mmm, no idea how well that compresses PNGs. Give pngout a try and see what happens.

Re:transparency in PNG (1)

Kris_J (10111) | more than 10 years ago | (#8054209)

Thanks, will do.

PNG and JPEG2000 aren't really competitors (0)

Anonymous Coward | more than 10 years ago | (#8049248)

PNG is lossless, JPEG2000 is lossy. A full color photographic image PNG can be quite huge. The reason JPEG2000 hasn't taken off is the licensing. PNG hasn't taken off because of Microsoft's lack of support and because programs like Photoshop produce extra large PNG files.

Re:PNG and JPEG2000 aren't really competitors (1)

rlwhite (219604) | more than 10 years ago | (#8051283)

To be more accurate, JPEG2000 can be used losslessly, but unless you're using the progressive streaming capability there's little point in choosing it for lossless applications.

Great (0)

Anonymous Coward | more than 10 years ago | (#8049268)

I belive that if photoshop, gimp and all the other big imageprograms is the key of everything, once they start having support for this, the people will follow, thus, the people is often only out for two things, the size of the picture and the quality, if those to is better than .jpg or .png, I truthfully belive that
'a distant future' would rather be 'next week or so'.

I'm waay more advanced than JPEG2000 (3, Funny)

L. VeGas (580015) | more than 10 years ago | (#8049294)

I use JPEG XP.

JPEG XP (1)

Geccie (730389) | more than 10 years ago | (#8054261)

Service Pack 1 or 2?

Lack of Microsoft support (0)

Anonymous Coward | more than 10 years ago | (#8049304)

JPEG2000 hasn't been tested, validated and proven to work by leading technology companies such as Microsoft [microsoft.com] , The SCO Group [sco.com] , IBM [ibm.com] and Ulteritec [ulteritec.net] .

As a result, there's little compliance between several specifications and public is not buying anything that doesn't have the Microsoft seal of approval on it. As soon as the standard is supported by leading Internet Explorer and best-selling PhotoDraw imaging software package, you can expect JPEG2000 usage to boom.

The SCO Group (1)

ttfkam (37064) | more than 10 years ago | (#8049669)

Did you really include The SCO Group in the list of leading tech companies?

Or more precisely, did you really include them with a straight face?

Re:The SCO Group (1)

sinergy (88242) | more than 10 years ago | (#8049760)

That post is obviously a joke. Great karma whoring.

Re:The SCO Group (1)

ttfkam (37064) | more than 10 years ago | (#8052892)

Not karma whoring. Just humor impaired.

HAND.

Re:The SCO Group (0)

Anonymous Coward | more than 10 years ago | (#8049904)

Stock tip: SCO Group is expecting a large cash payout ($3 billion) from IBM Corp. in the near future. SCO also owns the intellectual property for Linux operating system, which has millions of installations worldwide. A license fee of $699 will allow SCO to generate revenues of $699 million per year, making it one of the leading software companies worldwide.

Don't take Cliff literally.. (3, Informative)

molo (94384) | more than 10 years ago | (#8049305)

When he says PNG, I think he means JNG, which is basicly a standard JPEG plus transparency. JNG is from the MNG suite (same people who gave us PNG).

More info here:
http://www.libpng.org/pub/mng/spec/jng.html [libpng.org]

Abstract:
JNG is a lossy single-image member of the PNG (Portable Network Graphics) format family. It encapsulates a JPEG datastream in PNG-style chunks, along with an optional alpha channel and ancillary chunks that carry color-space information and comments. While JNG is primarily intended as a subformat of the MNG (Multiple-image Network Graphics) format, standalone JNG files are also possible.

-molo

hmm (2, Interesting)

mix_master_mike (540678) | more than 10 years ago | (#8049332)

no one knows about it? i'm a freelance artist at times and this is the first time i've heard of it. gif 4 life

Re:hmm (1)

pyrotic (169450) | more than 10 years ago | (#8067040)

O'Reilly ran an article on it.
[oreillynet.com]
http://www.oreillynet.com/lpt/a/4370

JPEG2000 can compress lossless bitmap images more than zip/lzw tiffs, by a factor of 2 or more. It's great for archiving, but slow to create files. Quicktime has decent support for both lossless and lossy compression. I'm running out of disk space fast, and am looking into any archiving solution I can.

No good free libraries (4, Interesting)

Carnildo (712617) | more than 10 years ago | (#8049358)

The big problem with JPEG2000, as I see it, is a lack of a free, open-source implementation that is compatible with closed-source, proprietary software. I was recently looking into implementing JPEG and JPEG2000 support for my company's main product. Since this is a relatively minor feature for our product, we didn't want to pay the licensing fees for a commercial implementation. The libJPEG codec for JPEG compression has a very nice license, only requiring the addition of two lines to the software documentation. The only open-source JPEG2000 implementation (JasPer) requires adding over a page of disclaimers, copyright notifications, and license terms.

Re:No good free libraries (2, Insightful)

NanoGator (522640) | more than 10 years ago | (#8049528)

"The big problem with JPEG2000, as I see it, is a lack of a free, open-source implementation that is compatible with closed-source, proprietary software."

As a content developer/artist, I'm finding the big problem with JPG2k to be lack of solid Photoshop and IE support. Bummer, too, because I want to use it.

(Note: It's been almost a year since I looked into it, so clarification would be much appreeciated.)

Re:No good free libraries -- PS CS (2, Informative)

Nom du Keyboard (633989) | more than 10 years ago | (#8050392)

Photoshop CS (PS 8) supports JPEG2K natively. It is also available as a $99 plug-in, which also includes a digital camera raw plug-in, for Photoshop 7.

Re:No good free libraries -- PS CS (1)

meta-monkey (321000) | more than 10 years ago | (#8050486)

Well, in CS it's not exactly "native." There's an optional plug-in you have to manually install later. You can find it on the Photoshop CS CD in the "extra options and goodies" or whatever it's called folder.

PS support for JPEG2000 is great and all, but something's missing. I'm a professional photographer, and while some aspects of JPEG2000 intrigue me, there's the problem that my cameras all capture JPEG (or RAW, of course), and the pro labs where I print only accept files in JPEG or TIFF. Give me a capture device and printer that use JPEG2000, and maybe I'll use it.

Re:No good free libraries (1)

BrookHarty (9119) | more than 10 years ago | (#8050477)

Second Life's case, images as large as 2048x2048 are delivered interactively to the client viewer, with a single packet providing enough detail for distant textures. As the user approaches textures, additional packets are delivered to the client, providing a progressive increase in detail with very low latency, thanks to Jpeg2000's ability to deliver fine-grained increases

So if I understand. Jpeg2000 format is layered, with each additional layer delivering higher detail, when you downloaded all the layers you have the full high resolution image.

Doesn't Ogg Vorbis do something like this, your bandwidth determines how many layers you can stream at once, the more layers you can download at once, and the higher quality the stream.

Not to familiar with PNG, does it also use wavelet compression?


-
BTW, wheres the linux SL client. ;)

Re:No good free libraries (1)

damiam (409504) | more than 10 years ago | (#8051393)

So if I understand. Jpeg2000 format is layered, with each additional layer delivering higher detail, when you downloaded all the layers you have the full high resolution image.

The same is true of current JPEG, PNG, and GIF. It's called a progressive [netadvies.nl] or interlaced [libpng.org] image - as it loads, it starts as a blocky blur and sharpens into the image. The effect is much more noticable when browsing the web with a 56k modem.

Doesn't Ogg Vorbis do something like this, your bandwidth determines how many layers you can stream at once, the more layers you can download at once, and the higher quality the stream.

Not really. Theoretically, the Ogg format supports bitrate peeling - taking a high quality original and "peeling" it down to a lower compression level without reencoding. In practice, the code to do this hasn't yet been written - apparently it's not a big priority.

Re:No good free libraries (0)

Anonymous Coward | more than 10 years ago | (#8056562)

It must be hard. So far, more then one person has tried and failed.

Re:No good free libraries (1)

CmdrTHAC0 (229186) | more than 10 years ago | (#8060067)

"Not to familiar with PNG, does it also use wavelet compression?"

Nope. PNG uses lossless LZ77 encoding, also used by gzip.

Standards are often late (0, Offtopic)

booch (4157) | more than 10 years ago | (#8049420)

I'm wondering when the CSS 3 standard will be completed. It started in 1999, I think. Four years is pretty long, considering how quickly the first 2 versions came out.

I seem to recall Fortran 90 finally coming out in maybe 1993 or so. I think they were originally going to call it Fortran 88.

I guess there are several problems: 1) standards are designed by committee; 2) unlike the first revision of a standard, more people are involved, each having their own agenda; 3) they want to test out the features in actual implementations before ratifying the standard; 4) if the features of the standard are overly difficult to implement (see #2) it'll take longer to work out the kinks.

My fellow graphics enthiasts (0)

Anonymous Coward | more than 10 years ago | (#8049457)

The state of the JPEG2000 Standard is STRONG!

Example pictures (4, Informative)

FattMattP (86246) | more than 10 years ago | (#8049471)

If anyone is interested I found an article here [dpreview.com] that shows the difference between JPEG and JPEG2000 pictures. I found the original reference to this article in this slashdot comment [slashdot.org] .

Re:Example pictures (0, Troll)

sinergy (88242) | more than 10 years ago | (#8049805)

Thank you for your extremely informative google search.

We know we're all too stupid to operate Google.

Re:Example pictures (1)

Nom du Keyboard (633989) | more than 10 years ago | (#8050423)

that shows the difference between JPEG and JPEG2000

It probably shows all the examples in ordinary JPEG, or else most people can't view it.

Rather like a television commercial showing you how good high-definition television is -- while showing you the results on your plain ordinary every-day television. Like how are you ever supposed to see the difference?

Yet it manages to compare through the magic of... (1)

blorg (726186) | more than 10 years ago | (#8053743)

"magnification".

Re:Example pictures (1)

TobascoKid (82629) | more than 10 years ago | (#8053393)

The link (http://www.dpreview.com/news/0108/01080401lurajpe g2000.asp) 404'd on me. When I went to http://www.dpreview.com/ I got:

Dear Visitor,

During a simple piece of routine maintenance a fault developed in the RAID subsystem of our primary server. Despite our hosting provider's best efforts they were not able to recover any data. We are now rebuilding to a completely new machine from backup but the process may take some time. Please accept my apologies for this unannounced downtime and have our assurance that we are doing all we can to be back up and running again very soon.

Phil Askey


whoops

Tk

Second Life and Jpeg2000 (5, Interesting)

Critter92 (522977) | more than 10 years ago | (#8049668)

I can't speak to the standard, but I can cover our experiences using Jpeg2000. In early 2001, the Second Life [secondlife.com] team did an evaluation of available still image compression schemes in order to determine whether an off-the-shelf solution would meet our requirements of providing flawless visual reproduction at 10:1 compression while preserving chroma at compressions of 100:1 or more, allowing progressive streaming in order to handle level of detail and mipmapping, and be high performance enough to allow for multiple packet decodes per game frame. We went into the search assuming that we would end up having to write out own compression scheme and were pleasantly surprised by the performance of Jpeg2000. We selected the Kakadu [kakadusoftware.com] libraries for Jpeg2000 compression and decompression and have been happily using them for 3 years on Linux, Mac, and Windows.

It is a shame that Jpeg2000 hasn't seen wider adoption, as it is visually far superior to Jpeg at similar compression levels, especially in reduced "ringing" around high-frequency edges, and its ability to handle progressive streaming is incredibly useful in interactive environments. In Second Life's case, images as large as 2048x2048 are delivered interactively to the client viewer, with a single packet providing enough detail for distant textures. As the user approaches textures, additional packets are delivered to the client, providing a progressive increase in detail with very low latency, thanks to Jpeg2000's ability to deliver fine-grained increases. Kakadu's high performance has also been critical, since many scenes in Second Life have thousands of different textures in view because of user created and uploaded textures.

Re:Second Life and Jpeg2000 (1)

michael_cain (66650) | more than 10 years ago | (#8058523)

It is a shame that Jpeg2000 hasn't seen wider adoption, as it is visually far superior to Jpeg at similar compression levels, especially in reduced "ringing" around high-frequency edges, and its ability to handle progressive streaming is incredibly useful in interactive environments. In Second Life's case, images as large as 2048x2048 are delivered interactively to the client viewer...

I think you have inadvertently identified why JPEG2000 hasn't seen wider adoption. It has nice features like progressive refinement, which are important for very large images. For images that are 800x600 and down, the user gets the full resolution on one screen and has little use for the new capability. At high compression ratios, say 80:1, JPEG2000 provides better quality than the old standard. Again, such high compression ratios are important for very large images, less so for small ones. JPEG2000 usage will increase at the same rate that very large images replace small ones.

Re:Second Life and Jpeg2000 (1)

mr3038 (121693) | more than 10 years ago | (#8061291)

I think you have inadvertently identified why JPEG2000 hasn't seen wider adoption. It has nice features like progressive refinement, which are important for very large images. For images that are 800x600 and down, the user gets the full resolution on one screen and has little use for the new capability.

I'd would love to design web sites where I could use large JPEG2000 images for pretty much all pixel based graphics. Need and image that works as an image? Put an 1024x1024 pixel image there and let the browser fetch the part it needs. Use CSS to request the display size you want and if the user wants to take a closer look to the icon, he can do that without the icon looking bad. If the browser is correctly done, the image quality doesn't suffer a little bit compared to PNG, the browser doesn't need to load anything extra (downloading only the start of the file is enough) and I can finally size things relative to viewport or user's font size, not relative to pixels.

If you think that SVG is great because it allows you to display scalable vector graphics, think what you can do with JPEG2000 which does the same thing for photos...

JPEG2000's killer app is digital cameras (4, Interesting)

SiMac (409541) | more than 10 years ago | (#8049784)

JPEG2000 will not become incredibly popular on the web, I think. It's not really necessary anymore, as broadband is catching on and 200K image downloads aren't such a big deal. On a digital camera, however, file size still makes a difference. The more pictures you can store on a small piece of flash memory, the better.

Photoshop and several other image applications either support JPEG2000 or have plug-ins available, but it doesn't seem to have caught on anywhere yet. Here's hoping for a firmware upgrade for my current camera.

Re:JPEG2000's killer app is digital cameras (1)

meta-monkey (321000) | more than 10 years ago | (#8050557)

You're forgeting one little thing. Printers. My pro lab don't truck with no JPEG2000. JPEG or TIFF only. I don't know if a Fuji Frontier or Noritsu or whatever can accept a JPEG2000, but even if they can, I've never seen a pro lab advertise it. If you have to convert every image you want to print to a JPEG or TIFF, then it kinda defeats the point on quality (JPEG) or file size (TIFF).

Re:JPEG2000's killer app is digital cameras (1)

Kris_J (10111) | more than 10 years ago | (#8052617)

Except for the case where you use JPEG2000 to store on your camera either more images of the same visual quality or the same number of images of images of a higher quality than JPEG can manage, then deliver them to your print shop as TIFFs.

Re:JPEG2000's killer app is digital cameras (2, Informative)

rlwhite (219604) | more than 10 years ago | (#8051248)

When I researched JPEG2000 for a defense contractor in 2001, the word was that ASICs would need at least another generation of improvement before cameras could handle JPEG2000.

Network transfers were viewed as the immediate application for the codec. Modern desktop processors can display JPEG2000 with little if any noticeable latency, and the compression is great for non-broadband networking.

I think the spread of broadband has been fast enough to limit JPEG2000's usefulness on the consumer market until cameras can handle the codec as well. Even then adoption may be slow. I think memory card capacity may be more cost efficient than new ASICs for a good while.

Porn (0)

Anonymous Coward | more than 10 years ago | (#8050319)

All the porn on the internet is over compressed anyway. It's clear people care about quantity and not quality.

What about DjVu? (2, Informative)

Myself (57572) | more than 10 years ago | (#8050523)

I came across this format years ago and had to do some digging to find it again, it seems revolutionary but obscure:
One of the main technologies behind
DjVu [djvuzone.org] is the ability to separate an image into a background layer (i.e., paper texture and pictures) and foreground layer (text and line drawings). Traditional image compression techniques are fine for simple photographs, but they drastically degrade sharp color transitions between adjacent highly contrasted areas - which is why they render type so poorly. By separating the text from the backgrounds, DjVu can keep the text at high resolution (thereby preserving the sharp edges and maximizing legibility), while at the same time compressing the backgrounds and pictures at lower resolution with a wavelet-based compression technique.

Re:What about DjVu? (0)

Anonymous Coward | more than 10 years ago | (#8050930)

Unlike JPEG2000, I actually run into the occassional DjVu or MrSid image -- usually a high-resolution map scan. There's a free viewer/plugin.

Re:What about DjVu? (1)

GoRK (10018) | more than 10 years ago | (#8051581)

DjVu is awesome. We use it extensively where I work. We have hundreds of thousands of pages of data archived in the DjVu format.

There are good opensource decoders and compressors out there and an opensource browser plugin; however, the main problem with encoding a DjVu image is that you have to split the (losslessly compressed SjBz) foreground out from the (highly compressed IW44) background when you begin the compression, and there are no good open algorithms for doing that. Commercial software, unfortunately is the only current resort for performing this task, so while there are open source compressors, they are all but worthless for doing much other than recompresing layers already extracted from existing DjVu documents.

At any rate, the compression ratios are phenominal. Full page color 300dpi scans of documents compress down to like 15-50Kbytes or less at acceptible quality for document reproduction or archival. Unfortunately, it's slow as hell to compress the things. We offload compression onto a cluster of machines to be able to keep up with the scanners.

Yahoo's use of JPEG2000 (1)

Morgon (27979) | more than 10 years ago | (#8051428)

It's worth noting that Yahoo! Messenger [yahoo.com] uses Kakadu's implementation of JPEG2000 in its webcam controls.

For proof, view someone's webcam - then check your %TEMP% directory. You'll see image-[username].jpg files. View them in a JPEG2000 viewer or convert them using Kakadu's tools, and you'll see a frame of the cam you were watching.

coming soon, really! (4, Informative)

andrewleung (48567) | more than 10 years ago | (#8052218)

JPEG2000 is a huge standard. i know, i am actively following it now and was part of the standards process. new parts are still emerging but the core codec work is done.

still, the greatest issue is the patent question... the JPEG patent issue that came up 2 years ago really caused everyone to rethink their JPEG2000 deployment scheme. there is a new project in the ISO group to ensure a baseline license-fee free JPEG2000 codec to ensure the same patent problem won't happen again.

other notes:
JPEG2000 won't kill JPEG... ever. digital cameras just made sure of that. all the digital cameras out there record directly to JPEG... no way to upgrade them to JPEG2000.

camera makers still waiting for JPEG2000 chips to be a drop-in replacement for JPEG chips... the biggest hurdle now is power consumption.

initial JPEG2000 cameras will probably also record to JPEG... i.e. backwards compatibility.

JPEG2000 is designed to fix all the problems of JPEG and bring improved functionality. this is more than just a 1-trick pony (i.e. H.264...) with JPEG2000, it has improved on all aspects of JPEG and also:
-scalability: read x% of the file, get x% of the image, no need to pull file format tricks or extra redundancies.
-error resilience: as the compression level increases, the compressed codestream becomes more fragile. lose 1% of the compressed codestream, expect 10% loss... especially compared with MPEG codecs. JPEG2000 error resiliency is 10x better than MPEG-4 (part1) and probably much better than H.264...
-multi-resolution and position based decoding: only want to see 1 part of the image? no problems. only decode that part of the image.
-"visually lossless": a single codestream can act as: lossless archive, visually lossless print-ready format, lossy distribution, and thumbnail. no redundancies. no transcoding.

the kakadu library at: http://www.kakadusoftware.com is VERY good. it has a lot of tools you can use right away. check out the KDU_server app.

more things to expect from JPEG2000:
-more metadata
-better workflow solutions (i.e. capture->process->print->archive)
-unified still & motion cameras (i.e. 1codec, 2 applications: stills and movies. thanks to standardized file formats)
-true network imaging (i.e. JPIP)
-secure images (i.e. JPSEC) and from that, a better imaging business model.

browser plugins: trivial. really. especially if you use the available libraries.

things holding back the standard now: hardware support. there is a lot of software out there but until we get that killer JPEG2000 app, that software will not be touched.

JPEG does a great job, JPEG2000 will do a greater one.

Re:coming soon, really! (1)

Kris_J (10111) | more than 10 years ago | (#8052636)

all the digital cameras out there record directly to JPEG... no way to upgrade them to JPEG2000.
If a Kodak DC265 can have MAME installed, I'm sure that many of the cameras out there now can be upgraded to JPEG2000 with a BIOS upgrade or a 3rd-party plug-in.

JPEG2000 will become standard the moment IE will properly display one via the standard img tag, rather than that embed or object crap.

Mozilla rejected Jasper (1)

the_olo (160789) | more than 10 years ago | (#8055727)

See Mozilla's Bugzilla bug 36351.

Jasper doesn't support incremental image decoding, it requires that the whole image is loaded before it's decoded - that's the main reason Mozilla didn't use Jasper.

JPEG 2000 Demo (1)

DSP_Geek (532090) | more than 10 years ago | (#8057542)

http://public.migrator2000.org/J2Kdemonstrator/ind ex.xalter

As usual, mung the space.

No decent reference implementation nor specs (1)

CmdrTHAC0 (229186) | more than 10 years ago | (#8060314)

I looked into writing a JPEG2000 pixbuf loader for GTK2 once. The only open-source-ish implementation I could find was JasPer, which had too many licensing requirements to be useful. I tried to find the specifications, but not even the baseline specs are free. So I said "Screw this" and abandoned the idea of ever supporting JPEG2000 in anything, and I suspect I'm not alone.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>