Open jpeg for jpeg2000
category: general [glöplog]
i didn't know jpeg2000 was so polemic and flammable :p
Gargaj: I wasn't quite refering to you. Or maybe I was. But then again...
Quote:
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.
PNG is completely lossless too and will compress far better than if you just ZIP them(see below)
Quote:
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..
We have a winnar! Yes PNG uses zip(zlib) based compression, and in all but a few circumstances(and only then it's a few %) PNG will compresses signifficantly better, upto 40-50 % in some cases than using a normal ZIP program. And, some people have written their own deflate compatible png writer which gains another 20-30 % over PNG(9 - max compression) like Ken Silvermans PNGOut. Their is even an implementation of 7-Zips deflate but i've had very mixed results with that. PNGOut works superb with 8-bit and under images, while pngcrush works best with 24-bit images(5-10 %) over pngout.
But, using RAR on the same BMPs instead of PNG can reduce it by another 10 - 20 %.
hitchhikr: wow, good job! It really brings it to usable speeds.
Machine as above (650 MHz Celeron ULV), the same 1200x1600 source file. Compressing into 60 kilobytes.
Compression takes about 9 seconds, decompressing the resulting j2k takes about 5 seconds. This j2k crashes IrfanView when trying to open with it, while the one from OpenJPEG doesn't.
Decompressing of a 60-kilobyte file made by OpenJPEG from the same source takes somewhat longer - about 6.7 seconds. However, this file does not crash IrfanView. I didn't measure how long does IrfanView take to open this file, but it seems in the same order of magnitude. Compression quality seems to be approximately the same to the extent to which i can judge by my naked eye.
I'm sorry for being too harsh towards you groundlessly.
I'll see what i can do as an excercise to break out of my coder's block, ongoing since quite a while thanks to "friendly" pressure from the group i was in a while ago under a different nick. But well, perhaps i had a good rest for a while.
Machine as above (650 MHz Celeron ULV), the same 1200x1600 source file. Compressing into 60 kilobytes.
Compression takes about 9 seconds, decompressing the resulting j2k takes about 5 seconds. This j2k crashes IrfanView when trying to open with it, while the one from OpenJPEG doesn't.
Decompressing of a 60-kilobyte file made by OpenJPEG from the same source takes somewhat longer - about 6.7 seconds. However, this file does not crash IrfanView. I didn't measure how long does IrfanView take to open this file, but it seems in the same order of magnitude. Compression quality seems to be approximately the same to the extent to which i can judge by my naked eye.
I'm sorry for being too harsh towards you groundlessly.
I'll see what i can do as an excercise to break out of my coder's block, ongoing since quite a while thanks to "friendly" pressure from the group i was in a while ago under a different nick. But well, perhaps i had a good rest for a while.
MWAAAAAAAAAAHAHAHAHAA! Wipe my ass. I can do the same as you just better. Try my uncompressor here:
http://home.cs.tum.edu/~minkov/unj2k_demo.zip
It should work somewhat faster than that of hitchhikr. It is based off OpenJPEG and will be open-sourced in a while.
http://home.cs.tum.edu/~minkov/unj2k_demo.zip
It should work somewhat faster than that of hitchhikr. It is based off OpenJPEG and will be open-sourced in a while.
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.
E:\lcc\j2k>demo
E:\lcc\j2k>unj2k pic.j2k pic.bmp
Fast J2K UNCOMPRESSOR by [>PaC<]::eye!
tile decoding time 1/1: total: 137.247 s
E:\lcc\j2k>pause
Press any key to continue . . .
E:\lcc\j2k>j2ktotga.exe pic.j2k pic.tga
Time elapsed: 99.402 seconds
E:\lcc\j2k>
(C) Copyright 1985-2000 Microsoft Corp.
E:\lcc\j2k>demo
E:\lcc\j2k>unj2k pic.j2k pic.bmp
Fast J2K UNCOMPRESSOR by [>PaC<]::eye!
tile decoding time 1/1: total: 137.247 s
E:\lcc\j2k>pause
Press any key to continue . . .
E:\lcc\j2k>j2ktotga.exe pic.j2k pic.tga
Time elapsed: 99.402 seconds
E:\lcc\j2k>
as you can see i started to optimize mine only yesterday and it's still experimental.
i noticed that your converter reported it's timing a long time before exiting (mine does it at the very end).
also if you could stop being aggressive that would be fine.
i noticed that your converter reported it's timing a long time before exiting (mine does it at the very end).
also if you could stop being aggressive that would be fine.
Ah, my binary is optimized for Pentium Pro/II/III CPUs, that's what makes it slow on Pentium. Doesn't make any real difference on fast machines though. I'll compile the next one for Pentium then. On my machine, it was actually about 20% faster than yours, but no great wonder.
The time is output just before writing out the uncompressed file. The time to write out the file is not a part of the algorithm anyway and is highly dependant on the compiler's respective standard library.
OK, to be frank this deconder is somewhat of a show-off fake. :> I bet it would break on any real-world j2k or make output of unbearable quality. But then again i was more or less sure yours was the same. :> It being broken is the reason i'm not releasing the source at the moment, but i'll come up with a "real" version as soon as have some time. In fact, the library has more to fix than performance issues. It is also non-reentrant, which is evil. :/
The time is output just before writing out the uncompressed file. The time to write out the file is not a part of the algorithm anyway and is highly dependant on the compiler's respective standard library.
OK, to be frank this deconder is somewhat of a show-off fake. :> I bet it would break on any real-world j2k or make output of unbearable quality. But then again i was more or less sure yours was the same. :> It being broken is the reason i'm not releasing the source at the moment, but i'll come up with a "real" version as soon as have some time. In fact, the library has more to fix than performance issues. It is also non-reentrant, which is evil. :/