Page 17 of 62 FirstFirst ... 7151617181927 ... LastLast
Results 481 to 510 of 1857

Thread: paq8px

  1. #481
    Member
    Join Date
    May 2008
    Location
    Antwerp , country:Belgium , W.Europe
    Posts
    487
    Thanks
    1
    Thanked 3 Times in 3 Posts
    Quote Originally Posted by LovePimple View Post
    Thanks Wary! Because of this I won't need to release any more fastpaq or turbo builds.
    Thanks, but not sure about this...
    I did a quick test by compressing a wav-test file using different compiles from px61 : times are process times from Igor's Timer.
    Code:
    paq8px.exe	               27.346				
    paq8px61_s11.exe              23.805
    paq8px61_s22.exe              23.478
    PAQ8PX_msvc_opt.exe           28.641
    paq8px_speed_optimised.exe    28.548
    paq8px_sse2_intel.exe         26.301
    As you can see, the MSVC optimized compile isn't faster than Shelwien's s11 or s22.
    Could you try to compile a Turbo version using the IC so we can compare it ?

  2. #482
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts
    How does paq8px v60 turbo compare using the same wav-test file?

  3. #483
    Member
    Join Date
    May 2009
    Location
    Europe
    Posts
    67
    Thanks
    0
    Thanked 1 Time in 1 Post
    Quote Originally Posted by Skymmer View Post
    Anfortunately some bad news for M4ST3R's compiles. Not only they produce different files comparing to LP's compiles but paq8px_v60_MMX compile is also differ to other two compiles from M4ST3R. I think its the consequence of changes in WAV model maded in v60.
    I made some v61 compiles
    I managed to produce identical files with the mmx and sse2 compiles.
    However there are still not compatible with LovePimple's compiles, at least on some sound files.
    There's a long (and too complex for me) discussion at gcc bugzilla about whether it's a bug of the FPU or of GCC.
    I patched the source to make gcc compiles compatible with msvc/intelc compiles when using the wave model.
    You can get the patched source and some gcc mxx and sse2 compiles there. Compile with -DGCCFPFIX to enable the hack
    Last edited by M4ST3R; 3rd August 2009 at 12:33.

  4. #484
    Member
    Join Date
    May 2008
    Location
    Antwerp , country:Belgium , W.Europe
    Posts
    487
    Thanks
    1
    Thanked 3 Times in 3 Posts
    Quote Originally Posted by LovePimple View Post
    How does paq8px v60 turbo compare using the same wav-test file?
    Code:
    PAQ8PX60 compile		 E62	   WAV
    paq8px.exe             		54.116	  30.560
    paq8px_fast_wav.exe             54.288    29.562
    paq8px_speed_optimised.exe      53.243    31.746
    paq8px_spopt_fast_wav.exe       53.243    29.655
    paq8px_sse2_amd.exe             50.169    31.403
    paq8px_sse2_intel.exe           50.185    29.967
    paq8px_v60_AMD.exe              45.427    23.400
    paq8px_v60_Intel_SSE2.exe       45.957    23.602
    paq8px_v60_MMX.exe              49.530    25.677

  5. #485
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts
    Thanks for testing, but you only needed to have tested the turbo version. BTW which one of the above is actually paq8px_v60_turbo.exe? Have you renamed it for the test?

  6. #486
    Member
    Join Date
    May 2008
    Location
    Antwerp , country:Belgium , W.Europe
    Posts
    487
    Thanks
    1
    Thanked 3 Times in 3 Posts
    Quote Originally Posted by LovePimple View Post
    Thanks for testing, but you only needed to have tested the turbo version. BTW which one of the above is actually paq8px_v60_turbo.exe? Have you renamed it for the test?
    I did this test some time ago, not specific to your question.
    I just realisizd turbo was not yet included in this test (yeah, silly me)

    Anyway, I retested Turbo on this wav-file :
    Code:
    paq8px_turbo            26.520

  7. #487
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts
    Thanks Pat!

  8. #488
    Member
    Join Date
    Aug 2009
    Location
    Bari
    Posts
    74
    Thanks
    1
    Thanked 1 Time in 1 Post

    WOW

    I have tested this version, and it's powerful and light, in fact it takes only 232 mb of RAM for a excellent compression, INCREDIBLE!

  9. #489
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,257
    Thanks
    307
    Thanked 795 Times in 488 Posts
    I compressed rafale.bmp to 518,699 bytes with paq8px_v60 -6 and the following transform:
    Code:
          g^=(g&4)?3:0;
          r^=(r&8)?7:0;
          b^=(b&8)?7:0;
    followed by (b,g,r) -> (g, g-r, g-b) as in paq8px_v61. The previous best result was 534K. maximumcompression.com has 539003.

    The transform works because rafale.bmp is really a 16 bit image with the low bits extended by copying. It uses 6 bits for green and 5 each for red and blue. This means that the green pixels always end with 000 or 111, and red and blue end with 0000 or 1111.

  10. #490
    Administrator Shelwien's Avatar
    Join Date
    May 2008
    Location
    Kharkov, Ukraine
    Posts
    3,827
    Thanks
    287
    Thanked 1,238 Times in 694 Posts
    1. I wonder if its unique, or maybe there're lots of such images?

    2. Did you consider using the pixel's position in 8x8 block as a context?

    3. Actually a considerable redundancy is added
    when a raw image from camera is converted to RGB.
    http://en.wikipedia.org/wiki/Demosaicing#Illustration
    http://cybercom.net/~dcoffin/dcraw/

  11. #491
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,257
    Thanks
    307
    Thanked 795 Times in 488 Posts
    Quote Originally Posted by Shelwien View Post
    1. I wonder if its unique, or maybe there're lots of such images?
    I haven't seen any others like it. IMHO it is a design error to extend the low order bits. Setting the low bits to 0 like my transform also improves the image quality.

    Quote Originally Posted by Shelwien View Post
    2. Did you consider using the pixel's position in 8x8 block as a context?
    Haven't tried it. Since it was originally a JPEG it could be converted back if you could guess the quantization coefficients. When I converted the ACT data set to BMP and compressed them with paq8px, they were still 2-3 times larger than the original JPEG. But the 16 bit truncation might make that not worthwhile. If you look closely at the image you can see the truncation artifacts like banding in the sky, but you can't see any JPEG artifacts like blocks, ringing around edges. Well, I can't anyway.

  12. #492
    Member
    Join Date
    Aug 2009
    Location
    Austria
    Posts
    2
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Anyone likes to try out the Intel C++ executables?

    edit:
    Changed a few compile options, please redownload if you want to benchmark it.
    Now it is 4sec faster than msvc version with a 2,5MB pdf and -8

    Also i published my source to http://repo.or.cz/w/paq8px.win.git
    Anyone can push in the mob branch!
    Attached Files Attached Files
    Last edited by Wary; 14th August 2009 at 17:32.

  13. #493
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    688
    Thanks
    41
    Thanked 173 Times in 88 Posts
    Don't worry Wary Your work will be precisely measured as same as other things when I'll reach one of my favorite threads here

  14. #494
    Programmer Jan Ondrus's Avatar
    Join Date
    Sep 2008
    Location
    Rychnov nad Kněžnou, Czech Republic
    Posts
    279
    Thanks
    33
    Thanked 138 Times in 50 Posts
    paq8px_v62

    more info here: http://encode.su/forum/showthread.php?t=431

    Quick test (level -5):
    facompress.dll - 361984
    facompress.dll.paq8px_v37 - 100809
    facompress.dll.paq8px_v38 - 100809
    facompress.dll.paq8px_v39 - 100862
    ...
    facompress.dll.paq8px_v49 - 100862
    facompress.dll.paq8px_v50 - 100574
    ...
    facompress.dll.paq8px_v61 - 100355
    facompress.dll.paq8px_v62 - 100224

    EDIT: replaced with paq8px_v63 (paq8px_v63 is just paq8px_v62 with some parentheses added.)
    Last edited by Jan Ondrus; 17th August 2009 at 11:47.

  15. #495
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts

    Thumbs up

    Thanks Jan!

    Compiled...

    EDIT: Attachments removed.

  16. #496
    Programmer Bulat Ziganshin's Avatar
    Join Date
    Mar 2007
    Location
    Uzbekistan
    Posts
    4,549
    Thanks
    767
    Thanked 684 Times in 370 Posts
    Quote Originally Posted by Jan Ondrus View Post
    facompress.dll - 361984
    facompress.dll.paq8px_v37 - 100809
    looks like i have finally made some contribution to compression theory

  17. #497
    Programmer Jan Ondrus's Avatar
    Join Date
    Sep 2008
    Location
    Rychnov nad Kněžnou, Czech Republic
    Posts
    279
    Thanks
    33
    Thanked 138 Times in 50 Posts
    paq8px_v64
    - warnings produced by -DNOASM and -O2 switches in GCC 4.4.0 removed
    Attached Files Attached Files

  18. #498
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts

    Thumbs up

    Thanks Jan!

    Compiled...

    EDIT: Attachments removed.

  19. #499
    Member
    Join Date
    Aug 2009
    Location
    Reunion
    Posts
    1
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Thumbs up

    Hello everyone i'm new in this forum , i want to know if paq8px is a very good
    compressor for .iso file . Sorry for my bad English and thanks in advance .
    But by the way ,
    1/1 Filename: Windows Seven 7.bmp (5184054 bytes)
    Block segmentation:
    0 | default | 5184054 bytes [0 - 5184053]
    Compressed from 5184054 to 685231 bytes.

    Total 5184054 bytes compressed to 685273 bytes.
    Time 253.50 sec, used 37496075 bytes of memory . Very Good
    Last edited by skyhate; 18th August 2009 at 14:48.

  20. #500
    Member
    Join Date
    Aug 2009
    Location
    Bari
    Posts
    74
    Thanks
    1
    Thanked 1 Time in 1 Post
    Why you don't speed up paq8px with multi core support??? If you have a quadcore, speed increase a lot! Now, all the people have a multi core PC. Me too !
    Last edited by PiPPoNe92; 21st August 2009 at 15:19.

  21. #501
    Moderator

    Join Date
    May 2008
    Location
    Tristan da Cunha
    Posts
    2,034
    Thanks
    0
    Thanked 4 Times in 4 Posts
    Quote Originally Posted by PiPPoNe92 View Post
    Now, all the people have a multi core PC.
    That's not true. Where I live, very few people own multi-core PC's.

  22. #502
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,257
    Thanks
    307
    Thanked 795 Times in 488 Posts
    How? If you divide the input into 4 parts and compress each one on a different core, then you lose compression because you can't use redundancy between the different parts, and each thread can only use 1/4 of the available memory. You can try it if you want. Split a file into 4 parts and run 4 copies with -6 instead of -8.

    Another approach would be to run the different models in parallel, but then the threads need to syncronize every input bit before the predictions could be mixed. The mixers, APMs, and arithmetic coder have to run in series, so it would be far from a 4x speedup. Anyone want to program it? You have the code.

  23. #503
    Member
    Join Date
    Aug 2009
    Location
    Bari
    Posts
    74
    Thanks
    1
    Thanked 1 Time in 1 Post
    I know, but if I want compress a file of 100 mb size with paq8px takes 3 hours and 10 minutes!!!!! Instead, if I use Nanozip takes a few time, but worst compression ratio than paq8px...I'd use paq8px for my rip.

  24. #504
    Member Fu Siyuan's Avatar
    Join Date
    Apr 2009
    Location
    Mountain View, CA, US
    Posts
    176
    Thanks
    10
    Thanked 17 Times in 2 Posts
    I guess maybe LovePimple is still using PIII 750


    btw. I think the speed on memory access can also be an bottleneck.

  25. #505
    Member
    Join Date
    May 2008
    Location
    Earth
    Posts
    115
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Sorry for a dumb question, but why it's needed to synchronize after every bit? Almost all data is byte-aligned, so model update for 2nd bit cannot affect model for the 1st bit (in a byte).

  26. #506
    Programmer osmanturan's Avatar
    Join Date
    May 2008
    Location
    Mersin, Turkiye
    Posts
    651
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Quote Originally Posted by IsName View Post
    Sorry for a dumb question, but why it's needed to synchronize after every bit? Almost all data is byte-aligned, so model update for 2nd bit cannot affect model for the 1st bit (in a byte).
    It's adaptive in bit-wise and needs previous bits as the context. Just think order-0 model alone. This even can help what I meant.
    BIT Archiver homepage: www.osmanturan.com

  27. #507
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,257
    Thanks
    307
    Thanked 795 Times in 488 Posts
    Consider how each model works in the decompressor. You model one bit at a time, calculate its probability, decode it, then use the decoded bit to update the models. You could postpone the update by pipelining, probably without hurting compression very much. But the problem is that the context for each model is a hash of some context bytes plus the already decoded bits of the current byte. You can't calculate the context for the next bit until you have completely modeled and decoded the bit before it.

    I suppose you could pipeline the context model predictions by using speculative modeling. You don't know the last couple of bits of context, so you make a guess. If you guess wrong, then you have to flush the pipeline and start over.

    This also would defeat the speedup you get from dictionary encoding. A dictionary makes the input smaller so it compresses faster. But it also makes each bit harder to guess because the input still has the same amount of information.

    You could use speculative prediction in the compressor easily because you already have the context bits so there is no need to guess. Also, for decompression you have the compressed data so you could use a fast but approximate model to make a good guess at the next few bits.

  28. #508
    Member
    Join Date
    Aug 2009
    Location
    Bari
    Posts
    74
    Thanks
    1
    Thanked 1 Time in 1 Post
    why you don't increase dictionary size, like 7z (128mb in windows 32 bit)?

    P.S. For LovePimple: In my City (Italy) you can buy PC with 8 gb RAM 4core 2,50 Ghz!! Your city is "old"!!
    Last edited by PiPPoNe92; 21st August 2009 at 20:40.

  29. #509
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,257
    Thanks
    307
    Thanked 795 Times in 488 Posts
    Quote Originally Posted by PiPPoNe92 View Post
    why you don't increase dictionary size, like 7z (128mb in windows 32 bit)?
    It already uses over 1.5 GB.

  30. #510
    Member
    Join Date
    Aug 2009
    Location
    Bari
    Posts
    74
    Thanks
    1
    Thanked 1 Time in 1 Post
    ok matt, but why paq8hp is faster than paq8px? In some cases the speed of paq8hp is 2x than paq8px and compression ratio is better (In my tests).
    Last edited by PiPPoNe92; 21st August 2009 at 20:47.

Page 17 of 62 FirstFirst ... 7151617181927 ... LastLast

Similar Threads

  1. FrontPAQ - GUI frontend for PAQ8PF and PAQ8PX
    By LovePimple in forum Download Area
    Replies: 26
    Last Post: 17th January 2019, 13:36
  2. Alternative paq8px builds
    By M4ST3R in forum Download Area
    Replies: 20
    Last Post: 25th June 2010, 16:19
  3. Optimized paq7asm.asm code not compatible with paq8px?
    By M4ST3R in forum Data Compression
    Replies: 7
    Last Post: 3rd June 2009, 15:34

Tags for this Thread

Posting Permissions

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