Results 1 to 10 of 10

Thread: JPEG Compression Test [December 2009]

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Location
    Russia
    Posts
    688
    Thanks
    41
    Thanked 174 Times in 88 Posts

    Lightbulb JPEG Compression Test [December 2009]

    JPEG Compression Test
    December 2009

    OK, here is the JPEG compression test I've finally made. The idea is kinda simple - to see how different currently existing JPEG compressors behave comparing to each other and to measure some other aspects. I must say that I've met some problems during it, but let's go by the numbers.

    Testbed and system.
    I just took one photo session maded with SONY DSC-W50 camera. It consists of 295 JPEG files. All files have 2816x2112 or 2112x2816 resolution depending on orientation. Original overall size is 602 112 057 bytes.
    All files are not Progressive, Huffman tables are not optimised.
    I've started the test on these original files but then the problem with PreComp has appeared. I've reported it here. Then I just stripped all non-image data from JPEG files with PureJPEG tool and final TestBed size became 596 454 271 bytes. Fine, but then another problem has appeared. Now with PAQ8px_67. For some reasons it doesn't recognize such cleared files as JPEGs and uses default model instead. Re-running the test for the 3rd time was too much so PAQ8px have been tested on original (non-stripped) data and listed separately.

    Test conducted on Win XP Pro SP2, AMD64 4000+ (Single Core).

    Competitors and settings.
    Code:
    PackJPG v2.3c                           default \ -dev -s17 -c14 (showed as custom)
    WinZIP v14.0 #8646 (console)            -ez
    PreComp v0.4.0 (PackJPG v2.4 WIP4)      default
    StuffiT v13.0.0.29                      --jpeg-no-thumbnails
    StuffiT v14.0.0.15                      --jpeg-no-thumbnails
    PAQ8px_67 (speed_optimised)             -6
    The things that you're probably looking for.
    Well, sorry for long introduction and let's go to the tasty part
    Code:
                             size        comp.   decomp.     mem.       %
                         -----------     -----   -------   -------   -------
    Original             596 454 271      ***      ***      *****    100.0 %
    PackJPG              479 216 216      955      957      31 MB    80.34 %
    PackJPG (custom)     478 209 609     1015     1014      31 MB    80.18 %
    WinZIP               476 061 457      579      517      18 MB    79.82 %
    PreComp              472 273 653     1107     1079      28 MB    79.18 %
    StuffiT 13           456 667 561      887      906      14 MB    76.56 %
    StuffiT 14           456 645 014      970      882      22 MB    76.56 %
    
    Original             602 112 057      ***      ***      *****    100.0 %
    PAQ8px               461 483 178    15877    15877     470 MB    76.64 %
    The final mini-battle
    Since its not very clear who is the winner I've conducted additional mini-test between StuffiT and PAQ8px_67 on 10 JPEG files.
    Code:
    PAQ8px_67       34 273 729
    StuffiT 13      34 013 770
    How progressive you are ?
    Let's see what competitors support Proressive JPEGs.
    Code:
    PackJPG       Yes
    WinZIP        No
    PreComp       Yes
    StuffiT       Yes
    PAQ8px        No
    Blah Blah Blya Blah
    First of all it's a little bit sad to see the performance of PackJPG v2.3c but results of PreComp v0.4.0 (PackJPG v2.4 WIP4) are very promising. Though, there is noticeable speed sacrifice.
    WinZIP surprised me a lot. Not very bad compression and relatively blazing speed. Further more WinZIP is partially asymmetric which is good but lack of support for Progressive JPEGs is bad. Considering that the WZ developers are little bit care about compatibility I think that situation will not change in near future. Can be wrong though.
    StuffiT results are very good but it was expected. Surely they did a good job but overall company politics and style just killing me.
    PAQ8px is very close to StuffiT but gee... too slow and too high memory requirements and don't forget about lack of support for Progressive JPEGs.
    Also, problems I've met during testing bring some questions. Is it JPEG format so badly developed so its hard to include its full support into product or its just a lazy developers or maybe it was just a bad choice of test material from my side?
    Also, I have suspicion that Power Archiver will have its JPEG compressor sooner or later so let's wait...
    Anyway, I hope the test was usefull and thanks for reading!

    EDIT: added notice that all tested files are not Progressive JPEGs and Huffman tables are not optimized.
    EDIT2: new result for PackJPG added.
    Last edited by Skymmer; 23rd December 2009 at 15:50.

Similar Threads

  1. JPEG Compression Test [April 2010]
    By Skymmer in forum Data Compression
    Replies: 18
    Last Post: 7th February 2011, 23:30
  2. video compression (test)
    By Lone_Wolf in forum Data Compression
    Replies: 42
    Last Post: 14th January 2010, 23:50
  3. Runet Awards 2009
    By encode in forum The Off-Topic Lounge
    Replies: 0
    Last Post: 26th November 2009, 13:47
  4. BMF 2.0 (Apr 29, 2009)
    By inikep in forum Data Compression
    Replies: 1
    Last Post: 4th May 2009, 23:05
  5. New fast open-source paq-based jpeg compressor
    By Bulat Ziganshin in forum Forum Archive
    Replies: 14
    Last Post: 13th September 2007, 14:57

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
  •