Jpeg2000

[oNyx]

Hehe... well Abscissa, those results were to be expected.

The image you used is high contrast and the color count is very low (137). In this case an indexed 8bit format would be perfect (eg png).

Compressing this kind of image with a lossy algorithm usually results in a bigger image, because the compression scheme doesnt work well with that kind of data.

And now... if you save that new image again as png it will be way bigger than the original one, because there are now way more colors (and blocky artefacts all over the place).

Its always important to pick the best suited format if you want the best results (there isnt a one size fits all thingy).

The original png - 101739 bytes
The same as 8bit png (pngout) - 55190 bytes (the visuals are 100% identically)

>things like anime/manga, cartoons, technical drawings

Yes, png is better there. But it depends... say an anime-ish image with a colorful background... then something lossy will be better. Or things like scanned line art... jpg will be better there unless you do some filtering before saving it as png (basically you need to make the color curve steeper, making the dark bits darker and the bright bits brighter).

So, be sure to pick the right format (at the very end)... for each file individually. That is... if you want to get the biggest bang for the buck. If you end up with lots of png files you can also try uncompressed tgas or bmps instead. If you use a good installer with an up to date compression scheme (lzma) you can end up with a smaller installer.

(Yea yea... I know I repeat myself... said that a million times etc yadda yadda)

@Phil Steinmeyer

The quality depends on the used encoder (the same is true with plain old jpg btw).

[princec]

Originally Posted by Alex Saveliev

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

Yeah, that's the issue... presumably your algorithmic tricks and tips are portable enough that you could produce a vastly faster and superior Java implementation?

Cas

[Alex Saveliev]

Originally Posted by 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

Nick, am I missing something or all three links point to the same PNG file?

[Alex Saveliev]

Originally Posted by princec

Yeah, that's the issue... presumably your algorithmic tricks and tips are portable enough that you could produce a vastly faster and superior Java implementation?

Well, I never thought this way… I guess, it’s feasible, but the amount of work will be insane. You know, it’s hard to port even to the different platform with the same language – imagine what it takes to port to another language

Anyway, no offence, but seems like Java is counting its days because of C#
I doubt that such tremendous amount of work to convert C++ code into Java will pay for itself…

[tolik]

Originally Posted by 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.)

This one is a very bad testing example. Please note that you are using very heavily dithered background in this game. JPEG algorithms are used mostly for gradients similar to the real-life, not the sharp-crisp 1-2 pixel stuff. Every image and compression type has it's proper use. Be wise.

[Abscissa]

Originally Posted by Alex Saveliev

Nick, am I missing something or all three links point to the same PNG file?

Ah ha ha ha! You're right! I copied-and-pasted the links and changed the text, but forgot to modify the filenames .

Originally Posted by oNyx

Its always important to pick the best suited format if you want the best results (there isnt a one size fits all thingy).

Originally Posted by emuLynx

Every image and compression type has it's proper use. Be wise.

Well yea. That's what my point was: That even as advanced as JPEG 2000 is, it's still no universal solution for images.

[soniCron]

Originally Posted by Abscissa

Well yea. That's what my point was: That even as advanced as JPEG 2000 is, it's still no universal solution for images.

Jesus. Of course not, it's f*cking JPEG!! Now, what is JPEG good for? Photographs. What did you use it for? Something that would obviously be best for PNG. Do your same test, but this time with a photograph and between PNG, JPG, and JPG2K. I know you're smarter than that, Nick!

@Alex: You seem to have a lot of folks on your hook as to why we should use your codec instead of Jasper. However, you haven't got any quantifiable data on your website, nor have you posted anything on here. You keep saying, "Mine's faster", and "Mine's better", but I'm not going to pay $99 to figure that out. How about some reproducable numbers?

[Alex Saveliev]

Originally Posted by soniCron

@Alex: You seem to have a lot of folks on your hook as to why we should use your codec instead of Jasper. However, you haven't got any quantifiable data on your website, nor have you posted anything on here. You keep saying, "Mine's faster", and "Mine's better", but I'm not going to pay $99 to figure that out. How about some reproducable numbers?

Yeah, you're right, I should post something on site... Untill then, I'll post some data here. By the way - you don't need to pay to figure anything out - J2K-Codec has fully functional demo-version. You can just download and try.

So, for Athlon 2000:

Original JPEG: 22 MegaClocks

JasPer
================================================
Decode: 412.266 MegaClocks

Get image via
jas_image_readcmptsample(): 2482.830 MegaClocks [No additional memory]

Get image via
jas_image_readcmpt(): 41.055 MegaClocks [Additional ImageWidth*ImageHeight*4 bytes memory]

=================================================

J2K-Codec: 136 MegaClocks.

So, 2894 vs 136 => ~ 20 times.

Plus, less memory, better support and much easier to use You can actually decode an image in 1 function call:

J2K_Image image; image.easyDecode("test.j2k");

After that, image.buffer holds the decoded image of image.width x image.height. Isn't that easy?

Plus some features for game developers, such as J2K_Frames class.
Plus Delphi and VB support.
Plus smaller size (DLL only takes 84 Kb, if compressed - 25 Kb)
Plus exe-resources support.
And a lot more

[Nikster]

Well, I make 453 vs 136 ~3.33 times quicker, and if anyone is that tight that they can't afford a 1.4meg buffer + whatever jasper uses internally for decompressing game images (which is for a 800x600x32bit image) then they have other issues to worry about, instead of me bashing jasper or J2K-Codec without using either I will try to spend the weekend bench testing both of them (unless someone does it beforehand ) in real world situ (and with an unbiased opinion), I'm guessing most people will just use the technology to make file sizes smaller for transfering across the net with little quality loss as possible, so I will use that as my bench test.. I guess how many scews each cover and how much they cost is a no brainer.

If anyone else suggests a real world situ for using jpeg2000 apart from basic installation, please suggest it and I'll try to add that to the tests.

[Abscissa]

Originally Posted by soniCron

Jesus. Of course not, it's f*cking JPEG!! Now, what is JPEG good for? Photographs. What did you use it for? Something that would obviously be best for PNG. Do your same test, but this time with a photograph and between PNG, JPG, and JPG2K. I know you're smarter than that, Nick!

Ok everyone, pardon me for assuming JPEG 2000 might be better than JPEG .

I clearly stated in my first post that my results were only relevent for that particular sort of image, so don't give me this "you should have used a photograph" garbage. Pardon me for not knowing those results "should have" been obvious to someone who has never touched or read up on the damn format before. Give it a fucking rest already, people.

[Alex Saveliev]

Originally Posted by Nikster

Well, I make 453 vs 136 ~3.33 times quicker, and if anyone is that tight that they can't afford a 1.4meg buffer + whatever jasper uses internally for decompressing game images (which is for a 800x600x32bit image)

Er… Small correction – for 800x600x32 image it will be additional 1.8 meg buffer.

Originally Posted by Nikster

...I will try to spend the weekend bench testing both of them (unless someone does it beforehand ) in real world situ (and with an unbiased opinion)

By the tone of your voice, I would say, you are biased against J2K-Codec

Anyway – such independent comparison (if done properly and honestly) would be a great thing!
I am sure you let us know, how you have performed it in details

I suggest comparing speed, features, program size increase, reliability, documentation, samples and ease of use. And I will be glad to answer any questions that may arise during the testing (alex@j2k-codec.com).

As for a real-word scenario – try using it for a bunch of sprites with animations and alpha-channel and a couple of large pictures, such as menu and background. I guess this will be pretty typical for a game.

Thank you!

[Alex Saveliev]

By the way, I want to offer a time-limited 20% discount for all readers of this forum!

So now you are able to evaluate J2K-Codec till the end of this month (for 2 weeks) and buy it for $79 instead of $99 by following this link:

http://secure.emetrix.com/order/prod...&DC=INDIEGAMER

Don't miss the chance!

Thank you!

[Kai Backman]

I just want to say a quick Thank You to Alex for dropping by and letting us know about the toolkit. I've been using wavelet compression for a while and his toolkit looks pretty decent. The only thing I'm currently missing is OSX support..

[Nikster]

Originally Posted by Alex Saveliev

Er… Small correction – for 800x600x32 image it will be additional 1.8 meg buffer.

My bad, I meant to put 24bits, as you wouldn't really use alpha.

Originally Posted by Alex Saveliev

By the tone of your voice, I would say, you are biased against J2K-Codec

At least let me do the tests and post my findings before you get all defensive, or maybe you are trying to discredit me incase I find any negatives ? afterall, this test should work in your favour.
I have nothing to gain if anyone uses either, you do however, but to be honest, by all your replies so far on the issue with regards to other peoples assertions I think if any negatives are produced you will think it's my attempt to form some sort of conspiracy.

But on a side note, having looked at the PDF's last night for Japser, I guess it would be kinda difficult to make documentation any worse.

So before you retort, the test will be conducted in utter fairness, I still think it would be good for a couple of others to do similar tests as well, as more than one opinion would be more beneficial.

[Alex Saveliev]

Originally Posted by Kai Backman

I just want to say a quick Thank You to Alex for dropping by and letting us know about the toolkit. I've been using wavelet compression for a while and his toolkit looks pretty decent.

Thank you for support! It's always hard to tell people about my product, because they always think I try to beat money out of them, deceive them, lie to them They see marketing in your every word...

To be honest - I didn't even create this codec for selling first. I've created it for myself, as JasPer replacement. And when I used it successfully, I thought "Hey, I guess there are other game developers out there that face the same problem, why not to make it a commercial product - to help others and to return the money I spent on development"

Originally Posted by Kai Backman

The only thing I'm currently missing is OSX support..

You mean OCX? Well, J2K-Codec has ActiveX component - J2K-Control.
Write to me (alex@j2k-codec.com) - maybe I could help you...

[Alex Saveliev]

Originally Posted by Nikster

At least let me do the tests and post my findings before you get all defensive, or maybe you are trying to discredit me incase I find any negatives ?

No! It was kinda joke

I'm not afraid of any objective testing. I'm, actually, really interested in it (thank you again!).

Originally Posted by Nikster

I think if any negatives are produced you will think it's my attempt to form some sort of conspiracy.

Nope. I will immediately run my IDE and start fixing them

Looking forward to your results!

[Nikster]

Originally Posted by Alex Saveliev

Thank you for support! It's always hard to tell people about my product, because they always think I try to beat money out of them, deceive them, lie to them They see marketing in your every word...

Heh, that's called paranoia but your previous posts do come across as marketing babble, if you re-read them you will see what other people see, which is probably why all the negatives appear, nice to see you've dropped your prices for the little community here, also, do you market your library to outside the gaming sector ? or is this your main target audience (gaming) ?

Additionally, the most important issue at hand I think is the price, when you know you can get free alternatives I'm sure you will have to push your marketing as hard as if you were just competing with other commercial applications, it's difficult in your case as you have a codec rather than an application that can be played/create things, if that makes sense, at least you seem to have an advantage over the other commercial offerings at least.

[Kai Backman]

Originally Posted by Alex Saveliev

You mean OCX?

My bad. Mac OS X. I'm putting my ducks in a row for supporting that an Linux in the future.

And I just want to say again that it's been great Alex stopped by and told us about his kit. I'd love for more tool authors to now and then stop by here and tell us about their products.

I think most people confuse Open Source with Free. Integration and learning time does also cost. Alex kit costs $99 (without discount), GIS (Geopgraphic Information Systems) level products can easily cost in the $1000-$5000 range. And the function set just to decode something might run in the range of 10-15 calls plus a few structures thrown in. Yes, that's neccessary if you are doing GIS, but not that neccessary for games. A small clean library specially targeted at games is a great product idea.

And naturally Alex wants our money, that's how he finances the development.. And we should be happy for that.

[Alex Saveliev]

Originally Posted by Nikster

Heh, that's called paranoia

No, it's not
I once (honestly) told in one comunity, that I do care to help game developers - they laughed at me They thought it was a marketing trick... Sad...

Originally Posted by Nikster

do you market your library to outside the gaming sector ? or is this your main target audience (gaming) ?

Well, I am trying... Even successfully to some extent.

But since I am a game developer and this product was created especially for games, I would like to see game-dev community as my main audience.

[Nikster]

OK ok, I didn't want to come across I was on some sort of attacking rampage, Alex, you really need to get some proper marketing guy for your product, I've decided not to do a comparison on the grounds it will be like comparing oranges against apples, sure, they're both fruit, and yeah, they both come out in your poopie, but they do different stuff inside

The main thing with Alex's codec is that it has features only really intended for games, mainly the frame component, the class system is wrapped up nicely for ease of use, and obviously the documentation is good due to there being hardly any calls, you only need to use the two provided classes to cover most aspects.

You can tell this was mainly designed with windows in mind, due to the resource loading feature and I guess is one of the reasons it's a PITA to be as portable as it could be, that and it being dll based.

One of the features I do like is the options being passed as strings, some may see this as bloat, but it's hardly going to bankrupt you and it's the best way of allowing the dll's to be updated without having to recompile your main application, so bug fixes in the codec would be as simple as replacing the dll.

I think the only things missing is to have a statically linked library option, a supplied encoder (sure you can get those anywhere but it's nice to beable to have an all in one solution), and, this is more of a nitpick, but would be nice to have dynamic sizes for the frames, this would only be needed to optimise item graphically in vram avoiding wasted space, but like I say, this is nothing of real importance.

The only problem this has is it's portability, it maybe worth getting in touch with some of the guys on here who have actually done porting to macs, coupled with a linux solution you pretty much have most of the market covered cornered and most people will be even happier having the same code base for three scews without having to mish mash libraries between platforms.

Oh, I forgot about the custom reading callbacks, which is also great and has numerous uses.


Right, there you have it. my biased opinion against your codec

But do look at getting proper marketing done as it can be pushed a lot more than it currently is.

Regards,

N!k

[Alex Saveliev]

Originally Posted by Nikster

OK ok, I didn't want to come across I was on some sort of attacking rampage, Alex, you really need to get some proper marketing guy for your product

I guess you're right. I am a geek and most geeks are bad at that marketing stuff

Originally Posted by Nikster

I think the only things missing is to have a statically linked library option, a supplied encoder (sure you can get those anywhere but it's nice to beable to have an all in one solution)

I offer static linking on request. I think, should have done it "officially" and mention on the site... As to encoder - I thought about it, but still not ready to do it for 2 reasons - amount of work and redundancy for games. Games do not usually use encoding, so this would only add some extra "weight" - space, more complex API and documentation, etc. Though I'm still thinking about it.

Originally Posted by Nikster

would be nice to have dynamic sizes for the frames, this would only be needed to optimise item graphically in vram avoiding wasted space

Would love to do it, but I am not sure, I clearly understood what you mean.

Originally Posted by Nikster

Right, there you have it. my biased opinion against your codec

Big thanks, Nikster, for such detailed review!

By the way, I am preparing a press-release now, so would you mind if I use some quotes in it? If you don't mind, I would also like to know, how to sign them

And I would also like to use Kai Backman's quote about GIS systems. Is it possible?

Thanks!

[Nikster]

Sure, you can use any of the quotes, and regards to the encoder, I mainly meant this as a sperate entity encoder (not part of the actual codec library), even some console app that would allow you to just wildcard convert your original textures, this is because mainly people will have all source graphics as bmp/tga/png format.