Results 1 to 8 of 8

Thread: Unoptimizing? a JPEG file

  1. #1
    Member
    Join Date
    Jun 2013
    Location
    USA
    Posts
    98
    Thanks
    4
    Thanked 14 Times in 12 Posts

    Unoptimizing? a JPEG file

    I did some experiments with packJPG and jpegtran. It turns out that if you process the JPEG file prior to compressing it with packJPG, you can get a smaller file size.

    jpegtran stock: 6579826 bytes
    jpegtran -optimize: 6405337 bytes
    jpegtran -progressive: 6072106 bytes
    jpegrescan: 6010238 bytes

    packJPG results:

    jpegtran stock: 4864661 bytes
    jpegtran -optimize: 4864828 bytes
    jpegtran -progressive: 4865008 bytes
    jpegrescan: 4865027 bytes

    In other words, the larger the input JPEG file, the smaller packJPG will compress it. Which begs the question. Is there a way to do JPEG compression in a way which is worse than jpegtran?

  2. #2
    Member
    Join Date
    Jun 2009
    Location
    Kraków, Poland
    Posts
    1,471
    Thanks
    26
    Thanked 120 Times in 94 Posts
    Those are very small differences. Have you tested on more files to confirm the trend?

  3. #3
    Member
    Join Date
    Mar 2010
    Location
    Germany
    Posts
    116
    Thanks
    18
    Thanked 32 Times in 11 Posts
    Im not 100% sure, but i think you can do it with jpegtrans also. Just don't use the "-optimize" switch, just jpegtrans.exe in.jpg out.jpg.
    Edit: ah, just overlooked you do this already with "jpgtrans stock".
    Last edited by Biozynotiker; 7th September 2013 at 02:01.

  4. #4
    Member
    Join Date
    Jun 2013
    Location
    USA
    Posts
    98
    Thanks
    4
    Thanked 14 Times in 12 Posts
    Quote Originally Posted by Piotr Tarsa View Post
    Those are very small differences. Have you tested on more files to confirm the trend?
    The differences are not that small. And yes, I have tested multiple files and all show the same pattern. I would also try arithmetic coding but that is not supported by packJPG.

    I mean I understand why progressive images compress worse but not stock vs. -optimize.

    edit: I should mention that compressors like TANGELO show a smaller size with -optimize than without.

  5. #5
    Expert
    Matt Mahoney's Avatar
    Join Date
    May 2008
    Location
    Melbourne, Florida, USA
    Posts
    3,255
    Thanks
    306
    Thanked 778 Times in 485 Posts
    I don't think tangelo has a JPEG model. Have you tried paq8pxd_v7?

  6. #6
    Member
    Join Date
    Jun 2013
    Location
    USA
    Posts
    98
    Thanks
    4
    Thanked 14 Times in 12 Posts
    TANGELO 2.4 has a JPEG model according to the changelog. It produces files marginally larger than packJPG. I've tried paq8px version 6.9 which produced smaller files but was slow. Otherwise, it behaves identically to TANGELO in that -optimize produces smaller files when compressed than stock.

    A few numbers with TANGELO:

    stock: 5017858 bytes
    -optimize: 5009029 bytes

    PAQ8PX_v69:

    stock: 4782509 bytes
    -optimize: 4774838 bytes

    progressive testing was omitted as the JPEG model in PAQ does not seem to support progressive images.

  7. #7
    Member caveman's Avatar
    Join Date
    Jul 2009
    Location
    Strasbourg, France
    Posts
    190
    Thanks
    8
    Thanked 62 Times in 33 Posts
    Quote Originally Posted by Mangix View Post
    The differences are not that small. And yes, I have tested multiple files and all show the same pattern. I would also try arithmetic coding but that is not supported by packJPG.

    I mean I understand why progressive images compress worse but not stock vs. -optimize.

    edit: I should mention that compressors like TANGELO show a smaller size with -optimize than without.
    I have a possible explanation, to my knowledge "stock" uses the universal Huffman tables that are described in the annex K.3 "Typical Huffman tables for 8-bit precision luminance and chrominance" of the specs, since these are wellknown packJPG has probably a very effective way to signal that these specific tables are used. In the other hand "optimize" builds Huffman tables that fits to the current image needs hense better compression but in this case packJPG has to record the tables in question in the file it produces.

    Have you tried to build different sequential scans using the -scans option?
    For instance if you put:
    0;
    1;
    2;
    in a file called "scn012"
    and call jpegtran this way:
    jpegtran -scan scn012
    It will put each component (Y, Cb, Cr) in a separate scan (there will be 3 SOS markers in the file) whereas they are all in the same scan (1 SOS, MCUs are used) by default.

    There are 13 different ways to produce sequential JPEGs this way (but only 5 will produce different file size, since individual scan orders has actually no impact on the file size), I've added the 13 scans files you could try in the scans.zip archive.
    Attached Files Attached Files
    Last edited by caveman; 7th September 2013 at 10:32.

  8. #8
    Member
    Join Date
    Jun 2013
    Location
    USA
    Posts
    98
    Thanks
    4
    Thanked 14 Times in 12 Posts
    I tried all of your scans. Results are below. Basically, stock(or scan0) remains the smallest.


    Original Sizes:


    6579826 0.jpg
    6579649 1.jpg
    6579643 2.jpg
    6579752 3.jpg
    6579649 4.jpg
    6579643 5.jpg
    6579752 6.jpg
    6579748 7.jpg
    6579748 8.jpg
    6579748 9.jpg
    6579748 10.jpg
    6579748 11.jpg
    6579748 12.jpg


    After packJPG:


    4864661 0.pjg
    4864666 1.pjg
    4864667 2.pjg
    4864667 3.pjg
    4864666 4.pjg
    4864667 5.pjg
    4864668 6.pjg
    4864669 7.pjg
    4864669 8.pjg
    4864669 9.pjg
    4864669 10.pjg
    4864668 11.pjg
    4864668 12.pjg

Similar Threads

  1. JPEG Huffman Coding
    By lorents17 in forum Data Compression
    Replies: 26
    Last Post: 16th December 2013, 00:51
  2. Test JPEG Standards Online
    By thorfdbg in forum Data Compression
    Replies: 0
    Last Post: 27th November 2012, 22:14
  3. Detector for ex-JPEG images
    By Alexander Rhatushnyak in forum Data Compression
    Replies: 22
    Last Post: 13th September 2012, 03:18
  4. Quo Vadis JPEG - Another update
    By thorfdbg in forum Data Compression
    Replies: 7
    Last Post: 11th September 2012, 20:09
  5. Replies: 5
    Last Post: 9th July 2012, 10:57

Posting Permissions

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