Results 1 to 23 of 23

Thread: PIM 1.25 beta is here!

  1. #1
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    What's new:
    + Added ZIP BZip2 decompression
    + Added ZIP PPMd decompression
    + Some GUI improvements and bugfixes

    Enjoy!


  2. #2
    Guest
    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!

  3. #3
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    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...


  4. #4
    Guest
    Bug report:
    PIM 1.25

    Cancel action doesn't delete temp archive.

  5. #5
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    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.


  6. #6
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts
    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.

  7. #7
    Guest
    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?

  8. #8
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    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.


  9. #9
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    butterfly4.bmp:
    Normal: 5,743,887 bytes
    Max: 5,666,086 bytes


  10. #10
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    ENWIK9:
    Normal: 242,199,794 bytes
    Max: 234,218,117 bytes


  11. #11
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts
    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.

  12. #12
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    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.

  13. #13
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts
    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?

  14. #14
    Guest
    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]

  15. #15
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    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!


  16. #16
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    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!


  17. #17
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts
    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?

  18. #18
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    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.


  19. #19
    Guest
    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..

  20. #20
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    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.


  21. #21
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    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!


  22. #22
    Guest
    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!

  23. #23
    The Founder encode's Avatar
    Join Date
    May 2006
    Location
    Moscow, Russia
    Posts
    3,954
    Thanks
    359
    Thanked 332 Times in 131 Posts
    Well, PIM detects files by its headers - i.e. unknown filetype == default compression without any delta filters...


Similar Threads

  1. PIM 2.40 BETA is here!
    By encode in forum Data Compression
    Replies: 19
    Last Post: 26th February 2009, 18:39
  2. PIM v2.41 BETA is here!
    By encode in forum Data Compression
    Replies: 33
    Last Post: 19th July 2008, 22:11
  3. PIM 2.01 (beta) is here!
    By encode in forum Forum Archive
    Replies: 76
    Last Post: 26th June 2007, 16:55
  4. PIM 1.20 beta is here!
    By encode in forum Forum Archive
    Replies: 20
    Last Post: 25th September 2006, 12:37
  5. PIM 1.05 beta is here!
    By encode in forum Forum Archive
    Replies: 11
    Last Post: 14th August 2006, 16:24

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •