FreeArc 0.40 released

[Intrinsic]

Dunno if this info will be of any use to you but thought i'd post it anyways, regardless it's useful to me :)

Legend:
O. = Original Image
1. = Processed image, no Huffman table optimisation, non-Progressive JPEG
2. = Processed image, Huffman table optimisation, non-Progressive JPEG
3. = Processed image, Huffman table optimisation, Progressive JPEG

[filename]-max = -max switch for Freearc
[filename]-mx = -mx switch for Freearc

The ProcessJPEG.log files are just the scripts i've setup log files and can be ignored.

433,530 O.HolPic07.jpg

516,901 1.HolPic07.jpg
313,334 1.HolPic07-max.arc
480,125 1.HolPic07-mx.arc
91 1.ProcessJPEG.log

433,314 2.HolPic07.jpg
313,488 2.HolPic07-max.arc
431,330 2.HolPic07-mx.arc
81 2.OptProcessJPEG.log

437,921 3.HolPic07.jpg
438,197 3.HolPic07-max.arc
431,260 3.HolPic07-mx.arc
91 3.OptProgProcessJPEG.log


842,468 O.A10.jpg

856,024 1.A10.jpg
697,667 1.A10-max.arc
860,519 1.A10-mx.arc
111 1.ProcessJPEG.log

824,441 2.A10.jpg
697,850 2.A10-max.arc
829,961 2.A10-mx.arc
101 2.OptProcessJPEG.log

780,872 3.A10.jpg
698,064 3.A10-max.arc
786,816 3.A10-mx.arc
101 3.OptProgProcessJPEG.log

So what we have here is two example files, one personal one and the often used A10.jpg. They are just to highlight something that i've found.
On images that don't respond well(file size increases) to being made into a Progressive JPEG it seems that using the -max switch yields worse compression that using -mx as can be seen with HolPic07.jpg.
On A10.jpg the opposite is true, this file responds very well to being made progressive(as do the vast majority of files) with Huffman table optimisation and PackJPG does a great job of reducing it further.
StuffIt 9 on the other hand handles HolPic07 very well as Progressive JPEG, giving a file size of 299,639.

One thing that both sets show is that the less processing a JPEG gets the better it can be compressed with Freearc -max(The opposite is true for StuffIT 9) So while it will have a much bigger size on disk, it'll compress better so that info at least may be useful to some.

This of course highlights the importance of having multiple test cases, hence the reason why even though some sites have SFC tests, they really should include more files in each section, esp for JPEG as results vary greatly from compressor to compressor on different files.
For example if HolPic07(as a progressive JPEG) was being used as the sole test case for JPEG SFC on maximumcompresion, then PackJPG would appear to be totally rubbish. And even PAQ8o10 only gives a filesize of 415,840 at -6! Meaning that StuffIT would wipe the floor with them by a huge margin.

Anyways i'm tired now, need some sleep.

[donkey7]

try new packjpg. it should have progressive jpeg support.

[Bulat Ziganshin]

as http://www.maximumcompression.com/data/summary_mf2.php#data shows, new fa filetype detector is almost as good on this test as detection by hard-coded extensions. great!

[LovePimple]

Awesome!

[JangoFat]

cool, congratulations :)

Did you release a new version Bulat? Last version I saw was from 2008-02-08...

[Bulat Ziganshin]

he was tested version i announced *here* for tests. i don't even expected this :) i still need to fix one problem before making even alpha release - current internal version is unable to compress >1gb of data :)

[JangoFat]

OK, I understand

I thought I missed the newest release

greeZ