Tuesday, June 29, 2010

KrzYoptimizer v1.01.2 (formerly ZIPslimGUI)

For all this time I was coding this front-end application. Starting from spare time at work to 2h past midnight, sleeping 5h and so on... I think today I will give it a rest, at least a bit =P

So it now has a nice and simple GUI:



and some cool advanced optimization settings:



I have written a short guide on how to set it up and use on My Homepage. If you are interested, Please, read, download and use it. It's really worth it in my opinion.

Why I'm doing this? Simply for myself. First time when I compressed a file on a computer I was 11-13 years old, LOL, and I was like "OMG IT GIVES SMALLZ FILAZ?!", arj/zip times =D. Guess what? I'm still into it. I like tools that DO optimize things, especially if it's not just about: "wow WinRAR, Best compression... um? That's all?", you know what I'm saying, the ability to get better results after putting some mysterious 'pb=3' (um? what? yes, 7-zip, doesn't mean gasoline =P) or better one '/rn' (LOL random Huffman Tables! K-ZIP)... And of course I'm doint it for You as well, because it wouldn't be available for download if I didn't, and there is a big thing comming UP! PNG file optimization based on Andrew C.E. Dent script named PNGslim (as it was converted to VBS by Me, it will as well be in VB6 EXE :) using a set of tools like optipng, advdef, pngout, pngrewrite and others.

So check out my website!

4 comments:

rokko said...

Great tool, simplified optimization, but pngslim still have smallest PNG output files ;)
And there is one error, after closing settings window with cancel button I have message Run-time error 9, Subscript out of range.

Mr_KrzYch00 said...

Thank you for your error report, I will fix it. I will also test it again against PNGslim. I think it may be just lucky random try or You did use FAST method when only 10 of them are run.
Also PNGslim does 'Ensuring' test in which it tests 3 close blocks to the best block found and it does it by using random Huffman table inits so it also may randomly give a bit different results. The code inside my exe is exactly the same (well, almost, due to changed to GUI) as BATch script made by Andrew C.E. Dent (You can check my ZIPslim.vbs, I think there is no difference). Sure, I will recheck the code once again to make sure everything is in place.

Try to run it multiple times on same PNG (the thing that Andrew also advises in his BATch script)... On some PNG i got -120 bytes when running 2nd time with... 500 random huffman tables lol ;)

rokko said...

Sooner or later I'd like to do tests once again and make comparison to see, which tool is more effective (compression and time creation will be major factors). In the past, has already tested pngslim, pngmonster and scriptpng (you can find my article on Hotfix.pl). Among these three amazing tools the best was of course pngslim. We'll see who comes out victorious from this battle ;)

Mr_KrzYch00 said...

Well, don't think my program will be the winner, at most it will be tied with pngslim results, since it has PNGslim module coded the same way Andrew C.E. Dent did in his PNGslim.bat [let's call it a port to VB6] ;)

Also all those programs are just scripts that run external, real programs that do the work. It's all about running them in certain order or with specific parameters.

I may try to run deflopt at the end of each pngout pass when picking best number of blocks. I will do tests later to see if that's for the best. I noticed, sometimes, when you run deflopt right after pngout, You get different number of best blocks than from pngout alone (tested it long time ago on PNGslim itself). In the end it lost because random tries made it bigger by few bytes (without random it would be 'teh win' strategy).

According to some info on the internet Deflopt optimizes Huffman code so it basically should be always run after ZIP/PNG compressors and then compare sizes.