so far i found this guys (iam mostly interested in 24bit image compression, 24 + 8 is even better of course...):

JPEG-LS
http://www.hpl.hp.com/loco/
-----------------------------------------------------
PNG
http://www.fnordware.com/superpng/
or
gimp
-----------------------------------------------------
JPEG2000
http://www.kakadusoftware.com/
or
http://www.pegasusimaging.com/imagepressj2k.htm
or
http://www.leadtools.com/utilities/psplugi...hop_plug-in.htm


any other candidates for the test? (should have free implementations)

yes,huffyuv...but why?
lossles audio and lossless video are DIFFERENT!

ok, but what has that to do with horse races? iam talking about (single) IMAGE compression....

you'll have to use huffy in RGB32 mode, or you'll get a lossy image (yuy2 vs rgb)

and huffy wouldn't stand up to jpeg2000... it's main value is speed. you'd never use jpeg2000 with realtime lossless capture.

mugfunky,he just said SINGLE image compression....
this means it's time for me to leave(hehe)

but is loco or jpeg2000 really lossless?
my suggestion is bmp+rar3.....(hehe)
for example,i can tell you that bmp+rar will beat png for natural images...
i see jpeg2000 as wavelet(so same situation as with video may happen;ok for lo bitrates,worse than JPEG on high bitrates)
loco is probably wavelet too(isn't it?)....

let's see some images now...

yeah, jpeg-ls and jpeg2000 are lossless.

DCT (jpeg) and DWT (jp2) are lossless transforms if implemented properly. the compression gain come from quantization. if there's no quantization going on, then you end up with a lossless transform and some entropy coding.

in these cases jpeg-2000 will win because (a) wavelets tend to approach the original quicker and (b) jpeg-2000 has a much better lossless compression (not sure if it's huffman like jpeg, but it works better with the layered wavelet arrangement)

seeing as huffy doesn't use delta-frames, it would not be unfairly disadvantaged from having to compress just 1 image (although that's not the point)

there's nothing wrong with misusing things to see what else they can do, as i recently tried compressing 16 bit images with FLAC and got pretty good results (although jpeg-2000 was still better for lossless, at least in colour images)

what jpeg2000 implementation you toyed with?
don't care about lossless,but if it'll save some space(i do LOTS of video screenshots) it's ok....
i searched some time ago and it was all shareware or demo or....

kakadu samples all seem very hi-resolutions(ie stuff that jpeg will also do well)


how well said...

a quick test with just 7 samples (pretty much the 1st seven pics that i found on disk):



samples are here: (only if you want to redid the test to check some other encoders or to check if i didnt make any stupid errors)
http://somestuff.org/images/index.php?gall...ompression_test


--------------------------------

next test on bigger selection of samples might be categorized into: CG, CG wip (more 'white' space), photo and maybe screengrabs.

could you try this one
http://www.cintel.co.uk//datapics/lock%20h...ull%20image.jpg
or
http://www.cintel.co.uk//datapics/lock%20h...ull%20image.jpg
?
(convert to bmp,and then try lossless jpeg,jls,j2k and simple bmp+rar3)

there:

14.325.169 lock house 4K full image.jls
15.423.244 lock house 4K full image.j2k
18.219.698 lock house 4K full image.png
38.240.312 lock house 4K full image.bmp

rared bmp:
21.519.950 lock house 4K full image.rar

rared jls:
14.325.261 lock house 4K full image.jls.rar

(iam not aware of any 'lossless jpg' implementations, url please.)

ok,thanks....
you're right,no lossless jpeg for stills,i was thinking about video again..(picvideo)

Just one small comment, JPEG-LS is not based on DCT. It will probably beat out lossless JPEG2k in speed as well in compression if both implementations are of equal quality.

There actually was a lossless JPEG based on DCT, but it sucked so bad you wont find any implementations.

a bit away from this lossless concept,this stuff(jpeg alternatives) reminds me of h.264 video codec(talking about jpeg2000 here);
still not ready for prime time(wether because there are no freeware tools or tech. is just too young for people to use it)..the technology itself may be developed,but if there are no good and free implementations,technology won't live (and it may even die)

and also,that "lock house 4K full image" is 1,62MB on my disk.....and you won't really see a difference between such hires jpeg compressed image and the original....(this image takes cca 36MB of ram when decompressed.(as reported by irfanview)...the same number which you get if you convert it to bmp...)
higher you go with the res,better the jpeg looks...

correct me if i'm wrong, but i think the kakadu source is open for educational use (it was developed at ANU i think, hence using an australian national park as the codename)

so there are free jpeg2000 implementations if you look hard enough. AFAIK, most commercial implementations are based on kakadu anyway (though there are significant tweeks from the commercial demo codecs i've played with, such as lurawave)

fnordware make a pretty good jpeg2000. their png coder is already linked to here, and that's damn fine too - pngCrush could barely squeeze 10k off it's filesizes in it's slowest ever exhaustive mode, and that's for CCDRAW pictures, which are very large

leadtools jpeg2000 plug-in is the fastest implementation i tryed (considerably faster than fnordware), link in the 1st post.

mug;ok then,find me a free plugin for irfanview310 so i can use jpeg2000 at last....

hmm...ohh...seems like leadtools is an psp plugin too....will try that one...thanks smok3...
(ufff...what a procedure to start the dload...yaiks!)

you need to dl additional plugins from irfan's page:

http://www.irfanview.com/plugins.htm

hehe...yes,but jpeg2000 plugin was shareware last time i checked.(perhaps decompressor is free,and compressor shareware(?)..we'll see...)also,that new version of iview worked much slower than 310.....
(i guess i'll install one more version of irfanview if i want the jpeg2000 support,as psp is a lousy viewer...)

[edited out some nice words about jpeg2000;i swapped jpeg2000 and source images on initial inspection....sorry....jpeg2000 is crap... ]

not sure, but i think so.

i did a really breaf subjective test on the lossy side, jpeg seems better for higher bitrates when jpeg2k will win at lower bitrates (but those are pretty useless for my purpose), so i guess there are reasons j2k lossy never got into general use.

smoke3, i was wrong(guess i forgot that last time i toyed with iview and jpeg2000;bad trip repeated itself again... )

heh..i told you paintshoppro is a lousy viewing program.... .{initial inspection was done with psp,ie prior to getting the iview385 and plugin}...it seems as if i was comparing source to jpeg (instead of jpeg to jpeg2000),so i thought i was watching smashing-nice-jpeg2000 while in fact i was watching source bmp...( )
to correct that;
http://i4004i4004.bizhosting.com/jpeg2000/

(it's easy to recognize the two;j2k blurs and jpeg blocks)

jpeg2000 is a blurfest and i won't use this crap(so help me god... )

on higher bitrates jpeg is sharper,and on lower jpeg blocks and jpeg2000 blurs(actually..jpeg2000 BLURS ALWAYS!!!)..(i will prefer blocks to blur ie i disagree with you that jpeg2000 "will win at lower bitrates".......it'll never win.....i HATE blurring!...for that 16kb images(in my test) i would still pick jpeg over jpeg2000...ie when jpeg looks bad,you can be sure that 2000 will also look bad..for ultra low bitrates,they will both produce unusable junk...no winners there.... )

about that irfanview bad trip;iview 385 is so slow(compared to 310) that it's unuseable...jpeg2000 is lurawave plugin(to make j2k files you need to pay..so in that regard i was right and i remembered well what happened last time....it's a pitty i didn't remembered the jpeg2k's poor performance right away!)

in essence,it's same thing as with mpeg4 versus vp6(or such);wavelet just can't reach the sharpness of block-based DCT.....and that's it....

i uninstalled irfanview385,back to ol' favorite 310....i already forgot all about jpeg2000...


indeed...

must edit that previous post...