Jpeg2000

[oNyx]

Yesterday I took a first look at jp2. It's truely awesome. It's smaller than jpeg and it also looks much better (I mean the lossy mode). For example hard contrast edges don't end up in a mess of jpeg artefacts. 80% jp2s look pretty much perfect and it's about 20-25% of the size of a png.

However, the patent stuff seems to be still pretty much unclear. I guess it's not used much for that reason.

[princec]

Is there any OGG stuff in progress for image compression?

Cas

[Karukef]

While many are under the belief that JPEG2000 is under strict licenses and such, that is not actually the case. The group and major comapnies behind JPEG2000 have all granted use of the relevant patents without restrictions, so it IS a free format and you can even find a free encoder\decoder for it called Jasper. The only reservation is that there MAY be hidden patents that some obscure company has taken long ago just to fling it in people's faces at a later time. Worrying about this however is probably being a bit paranoid.

Try JPEG2000 out. My experience with works wonders for textures and other "solid" images. Sprites - that is images that have large transparent parts and precise pixellated graphics - are much more suited to be losslessly compressed by LZMA (7-zip).

Original License information, taken from http://en.wikipedia.org/wiki/JPEG2000

JPEG2000 is not widely supported in present software due to the perceived danger of software patents on the mathematics of the compression method, this area of mathematics being heavily patented in general. JPEG2000 is by itself not licence-free, but the contributing companies and organizations agreed that licences for its first part - the core coding system - can be obtained free of charge from all contributors.

The JPEG committee has stated:
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 ... The up and coming JPEG 2000 standard has been prepared along these lines, and agreement reached with over 20 large organisations holding many patents in this area to allow use of their intellectual property in connection with the standard without payment of license fees or royalties.

However, the JPEG committee has also noted that undeclared and obscure submarine patents may still present a hazard:
It is of course still possible that other organisations or individuals may claim intellectual property rights that affect implementation of the standard, and any implementors are urged to carry out their own searches and investigations in this area.

[Alex Saveliev]

You can also try our decoding component - J2K-Codec at
http://j2k-codec.com

It is very easy to use

[soniCron]

Originally Posted by Alex Saveliev

You can also try our decoding component - J2K-Codec at
http://j2k-codec.com
It is very easy to use

Or, we could use the open sourced Jasper for free, and easy to use.

[Martoon]

In one of their dev diaries (I'm too lazy to dig up the link), Moonpod talked about converting Starscape to use JP2000. They were very impressed by the quality to filesize ratio (it really is leaps beyond jpeg), but found that it decompressed too slowly for loading images in-game. So they have the decompression (to some other format) all done at install time.

[Phil Steinmeyer]

Can you get Jpeg 2000 plugins for Photoshop? How 'bout for ImageMagick? Without support in one (preferably both) of those two, it would be rather hard for me to work with JPeg 2000.

[soniCron]

Originally Posted by Phil Steinmeyer

Can you get Jpeg 2000 plugins for Photoshop? How 'bout for ImageMagick? Without support in one (preferably both) of those two, it would be rather hard for me to work with JPeg 2000.

ImageMagick supports read/write of JPEG-2000 natively, and there are several Photoshop plugins for JP2K as well.

[Spaceman Spiff]

Originally Posted by Phil Steinmeyer

Can you get Jpeg 2000 plugins for Photoshop? How 'bout for ImageMagick? Without support in one (preferably both) of those two, it would be rather hard for me to work with JPeg 2000.

One thing to rember when adding a new format to the mix - if you go to a lossy format, do it only once. So your toolchain / build process really needs to be able to support the end format. (i.e. don't save to JPEG then convert to JPEG 2000).

[soniCron]

Originally Posted by Spaceman Spiff

...don't save to JPEG then convert to JPEG 2000.

And don't forget to check your code for typos!

[Alex Saveliev]

Originally Posted by soniCron

Or, we could use the open sourced Jasper for free, and easy to use.

Or you could figure out that J2K-Codec is up to 20 times faster, takes less memory and still more easy-to-use

Jasper sucks. Believe me, I wouldn't write this codec if JasPer were any good...

[princec]

<surfaces from hibernation>...is there a pure Java implementation of your decoder anywhere?

Cas

[Alex Saveliev]

Originally Posted by Martoon

...but found that it decompressed too slowly for loading images in-game.

I've created my codec especially for games and I'm actually using it; and the speed is fine...

P.S. The platform is PC.

[Alex Saveliev]

Originally Posted by princec

...is there a pure Java implementation of your decoder anywhere?

For Java you can try JJ2000 (http://jj2000.epfl.ch)
But JPEG2000 on Java will be veeeery slooooow

[princec]

Why's that then?

Cas

[Phil Steinmeyer]

Is there an easy way to use Jpeg 2000 with SDL?

Will JPeg 2000 cause noticeably slower load/decompress times than regular old Jpeg?

[Alex Saveliev]

Originally Posted by princec

Why's that then?

First of all - because it's JAVA

[princec]

:S Won't get baited... tell that to my Java code.

Cas

[Alex Saveliev]

Originally Posted by Phil Steinmeyer

Is there an easy way to use Jpeg 2000 with SDL?

I didn't used SDL, but I'll try to help you to adapt our codec for it, if you are interested...

Originally Posted by Phil Steinmeyer

Will JPeg 2000 cause noticeably slower load/decompress times than regular old Jpeg?

JPEG2000 is slower than old JPEG - it is a fact. Though the difference for a player may be neglible, depending on your situation. You can simply download and try J2K-Codec - just to estimate the decoding slowdown. I am using it and perfectly happy with the speed

[Alex Saveliev]

Originally Posted by princec

:S Won't get baited... tell that to my Java code.

There is code and there is Code

Moving packman around and performing full-scale wavelet and codeblock decoding is a bit different calculation tasks

[Musenik]

I am also interested in JPEG2000 for SDL, specifically if it supported PyGame across Mac, Windoze, and Linux.

[Abscissa]

Originally Posted by Alex Saveliev

Moving packman around and performing full-scale wavelet and codeblock decoding is a bit different calculation tasks

Cas: Jpeg 2000's "full-scale wavelet and codeblock decoding" is likely to involve the sort of computation-heavy processing that can still be done much faster by using direct memory access (ie: pointers) and possibly hand-tuned assembly as well.

What I mean is: Modern hardware and modern optimizing compilers (including JIT-compilers) have undeniably gotten good enough to make both direct memory access (pointers) and hand-tuned assembly 100% useless for anything a game does. (Except for highly complex 3D scenery, and highly complex shader-style pixel manipulations, but those are never done when there isn't hardware acceleration). But, there are things (such as Jpeg 2000) that are far more computationally intensive than what games ever do on the CPU. These things require such an absurdly high amount of computation, that those optimization techniques disallowed by Java - while totally useless for normal game purposes - can still yield noticable performance gains for super-computationally-intensive algorithms.

So like Alex said, blitting a bunch of sprites, even with alpha maps, rotation, and scaling, is still nothing compared to what must be calculated for every pixel in a Jpeg 2000 image.

[princec]

That would be a very informative and useful post... if it were true.

Cas

[Abscissa]

Originally Posted by princec

That would be a very informative and useful post... if it were true.

Heh, I guess I should have known not to direct such a post at Cas

[princec]

FWIW Sun's Java Media Framework is available in pure Java and it decodes mpegs in realtime at a rate about 5-10% slower than a C version. I'm pretty happy losing 10% of my performance if I get all that Java peace-of-mind. So I'm wondering why Alex isn't interested in doing a port of his decoder to Java for us Java types to purchase. I'm definitely interested.

Cas

[Alex Saveliev]

Originally Posted by Musenik

I am also interested in JPEG2000 for SDL, specifically if it supported PyGame across Mac, Windoze, and Linux.

I am thinking about making a Linux port. As to Mac - it's a big question - I don't have Mac and have absolutely no experience with this platform, not to mention any market estimations...

[Alex Saveliev]

Originally Posted by princec

I'm wondering why Alex isn't interested in doing a port of his decoder to Java for us Java types to purchase. I'm definitely interested.

Guys, there is no need to make Java port of J2K-Codec

There is already a free Java implementation - JJ2000 - I've mentioned it somewhere above. I haven't compared performances - I had no time to go into troubles of making all this stuff run under Java-VM. I looked into the source code and I would bet that the performance drop will be significantly worse than 5-10% that princec mentioned...

[Phil Steinmeyer]

I tried JPeg 2K [edit - fixed typo] on some images I have - the results were far from a slam dunk.

At equivalent file size reductions (reducing to roughly the size I need for my game), the J2K image looked better on high contrast edges, but in lower contrast areas, the basic Jpeg image looked noticeably better (the JPeg2000 image got very muddy in areas of subtle contrast).

I'll take a look again when I have all my art done for my game, but at the moment, I'd say it's roughly a tossup on quality, and given secondary issues (easier toolchain support, legal questions with Jpeg2K, etc), I'm inclined to stay with Jpeg.

Note my images are of a sort of water-colory/fantasy look. There are certainly hard edges to be found, but lots of subtle color gradients and the like too. Your mileage may vary.

[Alex Saveliev]

Originally Posted by Phil Steinmeyer

I'll take a look again when I have all my art done for my game, but at the moment, I'd say it's roughly a tossup on quality, and given secondary issues (easier toolchain support, legal questions with Jpeg2K, etc), I'm inclined to stay with Jpeg.

Well, the "legal questions" is typical FUD, but quality should be definitely better. Maybe the point is Java 2K or your special graphics, I don't know.

When you will try JPEG2000 again - feel free to contact me, maybe I will be able to help you with compression settings and other stuff...

[Abscissa]

I used this Photoshop plugin to encode an old screen shot and got pretty bad results:

Original PNG (99k)

Lossy JPEG 2000 set at same size as Original PNG (99k)
Same as above, but converted back to PNG for those unable to view JP2's

On the JP2 version, note the smears and blurriness on a) the dithering artifacts on the gamefield background and b) the scoreboard. Also interesting is the fact that saving the JP2-version as a PNG resulted in a file more than five times the size of the original PNG and JP2. So, from my (incredibly ad-hoc and non-scientific) test, it seems that *either* the codec I'm using or JPEG 2000 is really crappy on images with very high-frequency changes (which would probably include things like anime/manga, cartoons, technical drawings, etc.)

EDIT: Fixed the links