Ubuntu's Firefox May Gain JPEG 2000 Support

[agd5f]

I'm sure all distros would consider shipping a patch if one existed.

[deanjo]

I'm sure all distros would consider shipping a patch if one existed.

I wouldn't be so sure of that. Some distro's like openSUSE/SLED and RH/Fed err on the side of caution when it comes to items that may cause potential legal issues.

[laststop]

Does other OS software like GIMP and co support JPEG 2000 too? Who needs JPEG 2000?

NASA likes to release big images from Mars in JPEG2000.

http://hiroc.lpl.arizona.edu/images/jp2.html

[makomk]

Regarding JPEG 2000, it has some advantages over JPEG, eg. alpha transparency. The Wikipeda article has all details.

The trouble is, very little actually supports the alpha transparency feature. In fact, ImageMagick actually aborts with an assertion failure if you try loading a transparent JPEG2000 image, and I don't think it's the only program with this issue.

Tell me.. Why bother having a Jpeg 2000 format if no one uses it? This should have been done AGES ago...

Well, JPEG 2000 isn't really any better quality-wise than JPEG, it's much slower (especially the open source implementations), and it's patent-encumbered. Why would it see widespread adoption?

[energyman]

because you are wrong. Jpeg2000 is A LOT better than jpeg.

[nanonyme]

http://en.wikipedia.org/wiki/JPEG_2000#Features *shrug* Seems to be better than JPEG mostly on limited-bandwidth scenarios. If you're free to use as much space as you want for the images, difference is negligible.

[energyman]

>Compared to the previous JPEG standard, JPEG 2000 delivers a typical compression gain in the range of 20%, depending on the image characteristics. Higher-resolution images tend to benefit more, where JPEG-2000's spatial-redundancy prediction can contribute more to the compression process. In very low-bitrate applications, studies have shown JPEG2000 to be outperformed[2] by the intra-frame coding mode of H.264. Good applications for JPEG 2000 are large images, images with low-contrast edges — e.g., medical images.

[makomk]

>Compared to the previous JPEG standard, JPEG 2000 delivers a typical compression gain in the range of 20%, depending on the image characteristics. Higher-resolution images tend to benefit more, where JPEG-2000's spatial-redundancy prediction can contribute more to the compression process. In very low-bitrate applications, studies have shown JPEG2000 to be outperformed[2] by the intra-frame coding mode of H.264. Good applications for JPEG 2000 are large images, images with low-contrast edges — e.g., medical images.

It also takes ten times longer to decompress than normal JPEG, at least with the open-source implementations. I'm not exaggerating - I actually tested this:

[aidan@yarrow 4 tmp] 0$ identify test-in.jpg
test-in.jpg JPEG 1920x1200 1920x1200+0+0 8-bit DirectClass 863kb

[aidan@yarrow 4 tmp] 0$ time convert test-in.jpg test-out.pnm
real 0m0.276s
user 0m0.171s
sys 0m0.045s

[aidan@yarrow 4 tmp] 0$ time convert test-in.jp2 test-out.pnm
real 0m2.138s
user 0m1.725s
sys 0m0.161s

(This is Jasper, since that's what ImageMagick uses. Unfortunately, it looks like the other library OpenJpeg is just as slow. OpenJpeg 2.0 may be faster, but it's still in the alpha stage.)

Unless you're downloading a very big image to a very fast PC on a very slow connection, I'm not convinced it's worth it.

[nanonyme]

Why would image conversion rate have any significance as to whether it should be adopted or not? Surely the only important part is how fast it's rendered.

[makomk]

Why would image conversion rate have any significance as to whether it should be adopted or not? Surely the only important part is how fast it's rendered.

Unless graphics cards have gained hardware JPEG 2000 support without me noticing, rendering the image requires converting it to an uncompressed format - which is what those commands are testing.