PIM 1.25 beta is here!

[encode]

What's new:
+ Added ZIP BZip2 decompression
+ Added ZIP PPMd decompression
+ Some GUI improvements and bugfixes

Enjoy!

Hello everyone,

Quote from your homepage: "Extract support for PIM, ZIP, JAR, PK3, PK4 and QUAKE PAK archives"
I just remember you have started spreading news about pimple in 7-zip forum.
Any chance of making PIM read and unpack 7z-archives?
Or have I missed something... ?

Best regards!

[encode]

What about 7z and RAR archives. I will have some problems with huge files support (sizes over 2 GB). So, support for these archives is just in future plans.

But now I have plans about increasing main PIM compression. And here are two possibilities:

1. First, add two compression modes: 'Normal' (Current) and 'Max'. With 'Max' mode PIM will use more memory. Some details:

Normal, current compression:
24 MB LZP portion
32 MB PPM portion

Max compression:
24 MB LZP portion
128 MB PPM portion

A larger PPM model in most cases can give some compression gain. So, I will evaluate what this improvement can give and will think about this adding such mode.

2. Secondly, additionally to current compression, I can add a PIMPLE-like compression. No comments about compression. Note I'm talking about improved PIMPLE engine with kickass compression. But this engine is slow...

Bug report:
PIM 1.25

Cancel action doesn't delete temp archive.

[encode]

It's not a bug. For example, if you compress a lots of files and you cancel compression operation somewhere in the middle, then all already added files will stay in archive. So, this 'temp' archive is a valid archive wich contains files just added.

[LovePimple]

What's new:
+ Added ZIP BZip2 decompression
+ Added ZIP PPMd decompression
+ Some GUI improvements and bugfixes

This is just awesome!

Thanks Ilia!


But now I have plans about increasing main PIM compression. And here are two possibilities:

1. First, add two compression modes: 'Normal' (Current) and 'Max'. With 'Max' mode PIM will use more memory. Some details:

Normal, current compression:
24 MB LZP portion
32 MB PPM portion

Max compression:
24 MB LZP portion
128 MB PPM portion

A larger PPM model in most cases can give some compression gain. So, I will evaluate what this improvement can give and will think about this adding such mode.

2. Secondly, additionally to current compression, I can add a PIMPLE-like compression. No comments about compression. Note I'm talking about improved PIMPLE engine with kickass compression. But this engine is slow...

I think it would be a good idea to add the powerful PIMPLE engine to this archiver.

It's not a bug. For example, if you compress a lots of files and you cancel compression operation somewhere in the middle, then all already added files will stay in archive. So, this 'temp' archive is a valid archive wich contains files just added.



I'm sorry. I din't know.
One question: Are you saying that I can continue an interruped operation after cancel If I could remember list files added?

[encode]

Actually, PIM opens an archive in read-only mode, so you cannot add/delete files inside an archive.

Anyway, check out the testing results:

Normal - 32 MB PPM model (Current)
Max - 128 MB PPM model (possibly future 'Max' mode of PIM)
Extreme - 512 MB PPM model (listed only for comparison)

Performance on SFC (Normal/Max/Extreme):

A10.jpg: 854,301 bytes/856,398 bytes/858,481 bytes
acrord32.exe: 1,537,708 bytes/1,533,222 bytes/1,533,951 bytes
english.dic: 921,302 bytes/908,972 bytes/908,961 bytes
FlashMX.pdf: 3,758,330 bytes/3,761,657 bytes/3,775,357 bytes
fp.log: 620,307 bytes/613,307 bytes/613,249 bytes
mso97.dll: 1,948,945 bytes/1,931,711 bytes/1,927,620 bytes
ohs.doc: 852,834 bytes/854,325 bytes/855,514 bytes
rafale.bmp: 949,467 bytes/935,335 bytes/935,343 bytes
vcfiu.hlp: 701,341 bytes/698,610 bytes/698,546 bytes
world95.txt: 580,012 bytes/573,347 bytes/573,214 bytes

Total: 12,724,547 bytes/12,666,884 bytes/12,680,236 bytes

Total, combined Normal and Max: 12,659,969 bytes

Speed in all modes is about the same.

[encode]

butterfly4.bmp:
Normal: 5,743,887 bytes
Max: 5,666,086 bytes

[encode]

ENWIK9:
Normal: 242,199,794 bytes
Max: 234,218,117 bytes

[LovePimple]

I think you should have normal, high and use PIMPLE engine as max compression mode.

Or just leave it as it is and add the PIMPLE engine.

[encode]

Well, I think I must make some little break in PIM development. And continue working on the brand new compression engine. I have some great ideas about ROLZ-like (fast decompression) or FPW-like (Like PIMPLE but more efficient - higher compression with higher speed) engines.

[LovePimple]

Well, I think I must make some little break in PIM development.


continue working on the brand new compression engine. I have some great ideas about ROLZ-like (fast decompression) or FPW-like (Like PIMPLE but more efficient - higher compression with higher speed) engines.

Will you add this new ROLZ-like or FPW-like engine to PIM?

PIM 1.25
Yet the About box.

Strange thing: at home i see a black empty space on the right and at the bottom. But not at work.

[imgs]dim1.25.jpg[/imgs]

[encode]

Will you add this new ROLZ-like or FPW-like engine to PIM?

Yes. Now I'm experimenting with the brand new ROLZ-like compression engine. Currently it's just simple compressor, but even at this stage I see its power on binary data - even such simple coder achieve same compression on binary data as current PIM engine. In addition, decompression speed is noticeable faster than compression. Also, I'll try to make decoder as simple as it possible. Note, now I'm working on compression power of this engine and when I achieve some compression level, I release a demo program.

Strange thing: at home i see a black empty space on the right and at the bottom. But not at work.

Send me this picture via email! Probably the contrast or brightness of the monitor is the key!

[encode]

Some results. Due to my experiments new engine already provides better compression on binary files than PIM, but poorer on text files. Compression speed is about the same as with PIM engine, but decompression speed is x4...x8 times faster, so decompression speed is about 8 MB/sec...16 MB/sec on my PC. It's awesome!

[LovePimple]

Some results. Due to my experiments new engine already provides better compression on binary files than PIM, but poorer on text files. Compression speed is about the same as with PIM engine, but decompression speed is x4...x8 times faster, so decompression speed is about 8 MB/sec...16 MB/sec on my PC. It's awesome!

Will this new engine be enough to put PIM in the top ten at maximumcompression.com?

[encode]

Well, the goal of this new engine is fast decompression. Compressors in the top ten at maximumcompression.com are monsters. They eat a lots of memory and are dead slow. Also, I think SFC not shows the real performance of compressors - since many compressors, including 7-Zip and WinRAR, just tuned for best switches combination and algorithms used. For example, here, 7-Zip, along with its own LZMA uses PPMd algorithm. Who author of PPMd? Igor Pavlov? Who will try for hundereds of switches to provide better compression for each file? Anyway, this new engine is another step in evolution of my compression programs, since this ROLZ like compression engine is stronger than my 'classic' LZP. For example, I can replace LZP portion in PIMPLE to this ROLZ engine to provide even better compression. But first of all, I release this lite-weight version of new engine. I'm expecting some compression and speed improvements at MFC, especially decompression speed.

Stephan here

a new Squeeze Chart is online at maximumcompression.com

I had no time to include newest TC, but I am working on it

Greetings, Ilia
btw: a picture of you is now included on the people page..

[encode]

Thank you! But usually I wrote my name as Ilia Muraviev - not Ilia Muraview, but since it's transliteration it's okay. Anyway, if you can, in next versions of Squeeze Chart please fix this. Thank you again!

P.S.
And please fix the GUI flag in PIM, since PIM have GUI.

[encode]

A few notes about performance of PIM on Squeeze Chart. Even with lots of filters PIM compresses poorer than TC. The solid mode is the key. PIM for each file restarts the LZP model, at the same time TC compresses one TAR file and LZP model is not restarted for each file inside this TAR. Also this explains the LZPXJ success on this Benchmark. The next generation of TC uses ROLZ like compression. This algorithm have potentially higher compression on TAR files with lots of different files compared to LZP engines. In upcoming version of TC I'll add the flexible parsing to improve compression. In later versions I add the in-tar exe filter and max compression mode. With this additions TC must perform very well on Squeeze Chart!

Hello everyone,

don't know if it's worthy, but have you seen this:
http://sourceforge.net/forum/forum.php?thread_id=1 583159&forum_id=45797 ?

Best regards!

[encode]

Well, PIM detects files by its headers - i.e. unknown filetype == default compression without any delta filters...