Results 1 to 19 of 19

Thread: JPEG Compression Test [April 2010]

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Member Skymmer's Avatar
    Join Date
    Mar 2009
    Thanked 173 Times in 88 Posts

    Lightbulb JPEG Compression Test [April 2010]

    Here is the 2nd round of JPEG Compression Test. Basically, its made due the fact that new PackJPG have been released. But there are also new versions for every competitor and we have a new competitor, called JPACK from Infima. And afterall, I always felt that previous test was a little bit "unclean". Now I hope that everything have been done properly. Let's go...

    Testbed, system, tools
    As same as before I used one photo session made with SONY DSC-W50 camera. It consists of 295 JPEG files. All files have 2816x2112 or 2112x2816 resolution depending on orientation. The only difference is that all files passed through
    jpegtran.exe -copy none
    It was done to avoid compatibility problems appeared in previous test. Original overall size is 599 548 561 bytes.
    All files are not Progressive, but not sure if Huffman tables are optimised or not. I provided a couple of files used below, so feel free to take a look and give a comment.
    Test conducted on Win XP Pro SP3, AMD64 4000+ (Single Core). Performed in clean enviroment, i.e. most of services are turned off and no background tasks are running. ConsMeter tool used for time and memory consumption measurement. More exactly speaking the Total time and Peak working set size values. Buzzer tool from LovePimple have been also used.

    Competitors, versions, settings.
    JPACK                                              -x
    PackJPG v2.3c                                      default
    PackJPG v2.4                                       default
    PackJPX v2.4                                       default
    WinZIP console v3.2 (Engine: 25.0.9069.0)          -ez
    PreComp v0.4.0 (PackJPG v2.4 WIP4)                 default
    StuffiT v14.0.0.16 (Engine: 14.0.2383.921)         --jpeg-no-thumbnails
    PAQ8px_68 (SSE2_wildcard from M4ST3R)              -8
    Now its time to tell something about JPACK. Please read here. Pay attention at:
    JPACK SDK is based on Infima?s new and innovative neural networks compression method.
    Now lets look at the resulting archive. See the following screenshot. Don't you think that we seen similar structure somewhere ? More interesting is that they didn't mentioned the PAQ anywhere. So, for me they look like shameless thiefs.

    Resulting table
                        size       comp.    comp.mem.    deco.    deco.mem.       %
                    -----------    -----    ---------    -----    ---------    ------
    Original        599 548 561      ***          ***      ***          ***     100 %
    JPACK           500 331 199     1589      9.8 MiB     1518      9.8 MiB    83.5 %
    PackJPG 2.3c    479 209 871      946     31.3 MiB      948     34.0 MiB    80.0 %
    WinZIP          476 073 338      551     16.9 MiB      525     16.1 MiB    79.4 %
    PackJPG 2.4     473 000 941      836     29.7 MiB      847     32.7 MiB    78.9 %
    PreComp 0.4.0   472 267 302     1100     27.9 MiB     1060     30.7 MiB    78.8 %
    PackJPX 2.4     467 048 758      804     33.8 MiB      802     35.2 MiB    77.9 %
    StuffIt         456 661 409      975     20.9 MiB      874     13.0 MiB    76.2 %
    PAQ8px_68       455 557 509    14900    899.2 MiB    14900    899.2 MiB    76.0 %
    Progressive JPEG support table
    Let's see what competitors support Proressive JPEGs.
    JPACK         No
    PackJPG       Yes
    WinZIP        No
    PreComp       Yes
    StuffiT       Yes
    PAQ8px        No
    Random thoughts
    First of all, now PAQ beats StuffIt. Sure, too slow and memory hungry but anyway... Viva PAQ family
    Also its nice to see that PackJPG beats WinZIP. And now the strange things. For some reasons PreComp (PackJPG 2.4 WIP4) still packs better than final PackJPG 2.4. I suppose that its result of speed optimization with compression ratio sacrifice. But the most interesting thing is the PackJPX results. The question is:
    Why the same model have not been included into PackJPG ?
    I saw that Raymond said something about "solid" behaviour. But "solid" term is inapplicable here. If you'll look into the resulting SFX file you'll quickly notice the following structure:
    SFX stub -> hex: 07 00 00 00 -> filename -> hex: 00 -> compressed data
    You can even easily cut one of the block and SFX will continue to work. Furthermore, here is an another test, conducted on one big 50 533 219 byte JPEG file.
    big_building.jpg    50 533 219
    big_building.pjg    43 170 370
    big_building.exe    42 923 450
    So, obviously, there is an improved model built into PackJPX. And I don't understand what is the reason of including improved model into PackJPX only.

    Anyway... I hope the test is usefull and thanks for reading !

    EDIT: Almost forgot. Example files can be found here.
    Last edited by Skymmer; 28th April 2010 at 18:02.

Similar Threads

  1. Slow Visual 2010
    By Cyan in forum The Off-Topic Lounge
    Replies: 23
    Last Post: 24th May 2010, 02:03
  2. video compression (test)
    By Lone_Wolf in forum Data Compression
    Replies: 42
    Last Post: 14th January 2010, 22:50
  3. JPEG Compression Test [December 2009]
    By Skymmer in forum Data Compression
    Replies: 9
    Last Post: 23rd December 2009, 20:06
  4. 12th April - The Day of Astronautics
    By encode in forum Forum Archive
    Replies: 37
    Last Post: 13th April 2007, 10:26
  5. Squeeze Chart 2006 - 02 April/13 May
    By encode in forum Forum Archive
    Replies: 9
    Last Post: 17th July 2006, 04:39

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