Results 1 to 10 of 10

Thread: GIF optimization

  1. #1
    Member
    Join Date
    Apr 2011
    Location
    Russia
    Posts
    168
    Thanks
    163
    Thanked 9 Times in 8 Posts

    GIF optimization

    Good afternoon!
    I found the animated picture of gif with very high extent of compression. There are ideas through what program is made?

    original gif - 3 044 271
    ImageMagic - 3 590 299
    gifsicle - 4 023 688

  2. #2
    Programmer schnaader's Avatar
    Join Date
    May 2008
    Location
    Hessen, Germany
    Posts
    539
    Thanks
    192
    Thanked 174 Times in 81 Posts
    I don't know which program was used to create the original GIF, but here are the results of some tests and conclusions:

    Code:
    1_original.pcf           8.501.861
    2_imagemagic.pcf         8.502.353
    3_gifsicle.pcf           8.502.771
    
    1_original.pcf.srep      8.501.933
    12.pcf.dat               17.004.214 (concatenation of 1_original.pcf and 2_imagemagic.pcf)
    12.pcf.dat.srep          8.505.164
    
    1_original.pcf.7z        3.379.092
    1_original.pcf.ccm2      2.990.794
    1_original.pcf.zpaq_5    2.901.642
    1_original.pcf.paq8p_3   2.879.986
    1_original.pcf.paq8p_4   2.771.220
    - We can see from the PCF sizes and by looking at their content that all 3 GIF files contain the same content, so it seems there is no loss involved.
    - When concatenating the first two PCF files and processing the result with SREP, there is no big difference to processing only one of the files with SREP, so most of the content is identical
    - Concatenation+SREP won't work for any other combination of two PCF files, but I think this is only because the gifsicle file has the same content, but a changed palette order.
    - The compression of the original GIF file is indeed very good - it surprises me that it beats 7-Zip.

    I first thought the original GIF file would be the result of some usual optimization like palette reordering, using the transparent color or optimizing the size of the boxes in each frame where the image changed, but this doesn't seem to be the case, it seems like this is just the result of a very good LZW strategy.
    http://schnaader.info
    Damn kids. They're all alike.

  3. #3
    Member chornobyl's Avatar
    Join Date
    May 2008
    Location
    ua/kiev
    Posts
    153
    Thanks
    0
    Thanked 0 Times in 0 Posts
    Original.gif contains plenty of dithering, and still so compact. Maybe we finally observe image quantized from compression perspective, something like lossy LZW.

  4. #4
    Programmer schnaader's Avatar
    Join Date
    May 2008
    Location
    Hessen, Germany
    Posts
    539
    Thanks
    192
    Thanked 174 Times in 81 Posts
    I modificated Precomp to not apply the GIF differences it stores, the result is this GIF file, 3,549,090 bytes in size. Outputting the diff codes shows that they are all clear codes, exactly 518 of them, so it seems that the strategy used just was to make heavy use of the clear codes (the GIF consists of 86 frames, so it was used about 6 times per frame) so that the LZW process doesn't expand the data because of the growing dictionary.

    Lossy LZW is possible, too, but not really useful at is can be noticed very soon. Here are some results from a lossy LZW transform I made when working for Ocarina:

    Code:
    tolerance	size
    35              2,888,736
    40              2,760,815
    50              2,540,638
    75              2,143,709
    Image URLs (EDIT: Tolerance 50 link fixed):
    Tolerance 35
    Tolerance 40
    Tolerance 50
    Tolerance 75

    As you can see, at least the approach I used there (replacing parts of the image with previous seen parts to increase matches) creates clearly visible artifacts when the tolerance is set too high.
    Last edited by schnaader; 28th January 2013 at 21:26.
    http://schnaader.info
    Damn kids. They're all alike.

  5. #5
    Member chornobyl's Avatar
    Join Date
    May 2008
    Location
    ua/kiev
    Posts
    153
    Thanks
    0
    Thanked 0 Times in 0 Posts
    From what i see this artifacts are basically single color runs, with max length about 30. It looks like RLE optimization, not the LZW one.
    origin_v_p.pcx 7036918
    loss35_v_p.pcx 4709466

    origin_v_p.tga 7610940
    loss35_v_p.tga 5215929

    origin_v_p.gif 4635472
    loss35_v_p.gif 3866624

    Maybe single color runs can be limited, or treated separately.
    p.s. tolerance 50 link is messed up

  6. #6
    Programmer schnaader's Avatar
    Join Date
    May 2008
    Location
    Hessen, Germany
    Posts
    539
    Thanks
    192
    Thanked 174 Times in 81 Posts
    Quote Originally Posted by chornobyl View Post
    From what i see this artifacts are basically single color runs, with max length about 30. It looks like RLE optimization, not the LZW one.
    Fixed the tolerance 50 link.

    AFAIR, the algorithm replaces pixel blocks with one of these 3 possibilities:

    - Previous part of the image
    - Single color runs
    - Transparent color runs

    All of the optimizations are limited by the set tolerance which basically was a RGB delta.
    For this image, the first one doesn't seem to occur very often or perhaps not at all, so the two others are used. You can see the last one used in the tolerance 75 image often, lots of data from the previous frames "shines through".
    http://schnaader.info
    Damn kids. They're all alike.

  7. #7
    Member
    Join Date
    Jul 2013
    Location
    UK
    Posts
    17
    Thanks
    5
    Thanked 1 Time in 1 Post
    When developing lossy GIF encoder I've noticed that regular encoders are unable to efficiently re-encode a lossy LZW file.

    http://pornel.net/lossygif

    I suspect this file has been encoded using a slightly lossy LZW compressor - dithering is noisier than from a typical ordered or floyd-steinberg diffusion, so it could have been done by taking advantage of lossy encoder's distortion for dithering.

  8. #8
    Member Surfer's Avatar
    Join Date
    Mar 2009
    Location
    oren
    Posts
    203
    Thanks
    18
    Thanked 7 Times in 1 Post
    Quote Originally Posted by porneL View Post
    Your optimized GIF can't be displayed in Firefox 22 http://pornel.net/lossygif-gifsicle-1.gif

  9. #9
    Member
    Join Date
    Dec 2012
    Location
    Russia
    Posts
    11
    Thanks
    25
    Thanked 1 Time in 1 Post
    Quote Originally Posted by Surfer View Post
    Your optimized GIF can't be displayed in Firefox 22 http://pornel.net/lossygif-gifsicle-1.gif
    Firefox 21.0 - normally displayed
    Firefox 22.0 - downloaded image by 2/3 and displays an error

  10. #10
    Member
    Join Date
    Jul 2013
    Location
    UK
    Posts
    17
    Thanks
    5
    Thanked 1 Time in 1 Post
    Hm, it is corrupt indeed -- ImageMagick agrees. I guess that's what you get from an experimental image

Similar Threads

  1. Optimization to increase speed
    By BetaTester in forum Data Compression
    Replies: 8
    Last Post: 11th November 2012, 20:31
  2. C++ optimization guide
    By Bulat Ziganshin in forum The Off-Topic Lounge
    Replies: 4
    Last Post: 25th May 2012, 12:23
  3. New 7zip SFXs optimization !!!
    By Yuri Grille. in forum Data Compression
    Replies: 6
    Last Post: 4th May 2009, 23:42
  4. Parameter optimization
    By toffer in forum Data Compression
    Replies: 42
    Last Post: 30th June 2008, 00:53
  5. unsupported Gif verient for Precomp
    By maadjordan in forum Data Compression
    Replies: 3
    Last Post: 16th May 2008, 21:14

Posting Permissions

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