pouët.net

'cos you won't be able to compete with your fpu plasma then.

Bwhahahaha :)

winnerdemo is slow because of the wavelet loader: TRUE.. but generally the haar-wavelet transformation is a lot faster than JPEG's DCT..
just blame it on my lameness that ainc-demos load awfully slow.. :)

Ok, actually your wavelet compresses approx on par with jpg. Have you considered leaving the RLE totally out? This won't do anything to performance, but might improve compression ratio. Demos are packed up either in ZIPs or have a RAR datafile, which may work better than RLE.

Besides, have you tried profiling your code? I wonder what takes most of the time.

eye: no need to profile the code, cause i can tell you one thing: every line of the inner loop totally sucks! :)
it was made as a demo-prog to show the possibilities of the simple haar wavelet base function (for a university-course).. then endless fine-tunings were hacked into the inner loops to fake better quality..
all in all the code as it is now (last real changes made 2-3 years ago) is plain horrible.. :)
The RLE btw. is pretty useful.. As the HWL-encoder
always tries to "generate" as many zero's in the transformed stream as possible, the RLEncoder is optimized to very(!) efficiently encode single zeros along with long streams of zeros.. The rest of the stream-data is more or less unchanged, so a packer like ZIP/RAR still is recommended to deliver smaller files..

WARNING!!! WARNING!!! IMPORTANT!

Please don't touch this "openjpeg" codec that hitchhiker suggested! It is so slow, it's unusable. Besides, the "pervert example" files cannot be read at all.

I worked with a file of 1200x1600 resolution. Machine is a Celeron-ULV with 650 MHz. Last CVS edition. I wasn't able to compile last stable - don't ask me why. In the CVS edition (0.9), i had to fix a few casts which GCC forced on me, and one pre-ANSI C-ism in the option parser! Compiled with -02, then with -03 and -march=pentium3, with unnoticable performance difference.

And now to the numbers. Compression took a little less than one minute, decompression a little more than 1,5 minutes. I tried to specify 2 different compression rates: once a 20-10-5 (three-level compression) and once 20, yuilding files of 1 meg and 60 kilobytes respectively. Compression and decompression times did not vary significatly, quality is better than normal JPEG, but i'm not intending to check into detail here.

And now a surprise: a commercial JPEG2000 viewer plug-in distrributed in IrfanView's extra pack takes only 2 seconds to decode a 60-kilobyte file and ablut 4 seconds for a 1-megabyte file. So something's definately wrong. Perhaps someone can tell me some better way to encode J2Ks, but i'd say the decoder is broken.

so, @hitchhiker: SHUT THE FUCK UP.

Ah, addition: my computer apparently has enough memory so that there was no swapping during decompression, only some disk access during compression.

... and since you proved your technical excellence and competence so many times before ...

Gargaj: Well, if you don't believe me try yourself. It's easy, and i don't see what i could have done wrong. I'd be very interested to know if i made any mistake.

you did:

so, @hitchhiker: SHUT THE FUCK UP.

I'm not nice. Neither is hitchhiker.

Argh, "hitchhikr" if you mean that.

please pull your big head out of your arse eye/midiclub.

Let people use the fuckin' lib if they want to. And please, mr moron of the week (yes, that'd be you eye, winner once again), shut your fuckin' piehole.

I finally found the time to work a little bit on a version, here it is:

http://perso.wanadoo.fr/franck.charlet/j2k.zip

Two tools (with sourcecode) are provided for targa files (24 and 32 bits).

Make your own mind.

h.

Note: it looks like a compression rate of 30000 or 40000 is an acceptable compromise.

Note 2: i haven't really optimized the decompression part yet.

I'm not nice. Neither is hitchhiker.

Maybe. But he coded and you didn't. Now open your eyes.

I'm surprised more people don't use BMP files. The problem with JPEG and PNG is they hardly compress at all when stored in ZIP files. On the other hand, BMPs get reduced quite substantially and are completely lossless.

Because BMP's don't support alpha channels? :D
Seriously, BMP's stop packing well if there's a little (probably invisible, think 5 color steps from 255) noise level in the bitmap. On the other hand, JPG's remove that without you really noticing.
And if you want lossless unpacked, use TGA. 18 byte header should be enough for everyone :D

I've uploaded a new version with that reports elapsed time for both converters. Tell me what you got.

A 1024*768 (24 bits) pic took ~33 seconds to encode and ~14 seconds to decode on my old p133.

h.

Because JPG and PNG compression algos are specificially designed to compress graphical datas and thus are more efficient than general algo of the ZIP or RAR formats.

PNG compression algo is the same as zip.. Tho ofcourse the format is designed to make the algo work better on bitmaps, but usually there arent much difference, but enough to make a difference in lets say a max 10MB democompo..

I weep for sarcasm lost...

thom: I told you. BMP is 24bit at most, TGA can do 32. :D