Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
branch: master
Commits on Nov 27, 2013
  1. Handle 'deferred clear codes' when decoding nonstandard gifs

    authored
    This patch handles the 'deferred clear codes' clarification noted on
    the coversheet of http://www.w3.org/Graphics/GIF/spec-gif89a.txt
    
    --
        DEFERRED CLEAR CODE IN LZW COMPRESSION
    
        There has been confusion about where clear codes can be found in the
        data stream.  As the specification says, they may appear at anytime.  There
        is not a requirement to send a clear code when the string table is full.
    
        It is the encoder's decision as to when the table should be cleared.  When
        the table is full, the encoder can chose to use the table as is, making no
        changes to it until the encoder chooses to clear it.  The encoder during
        this time sends out codes that are of the maximum Code Size.
    
        As we can see from the above, when the decoder's table is full, it must
        not change the table until a clear code is received.  The Code Size is that
        of the maximum Code Size.  Processing other than this is done normally.
    
        Because of a large base of decoders that do not handle the decompression in
        this manner, we ask developers of GIF encoding software to NOT implement
        this feature until at least January 1991 and later if they see that their
        particular market is not ready for it.  This will give developers of GIF
        decoding software time to implement this feature and to get it into the
        hands of their clients before the decoders start "breaking" on the new
        GIF's.  It is not required that encoders change their software to take
        advantage of the deferred clear code, but it is for decoders.
    --
    
    These show up fairly frequently in the wild; ImageMagick handles them
    correctly while ImageIO throws an error and JAI and GifDecoder only load
    the top portion of the frames. Ex:
    http://24.media.tumblr.com/tumblr_mceuhx0qgj1r5hubco1_500.gif
    http://uberhumor.com/wp-content/uploads/2012/09/Gyvdz2.gif
    https://i.chzbgr.com/completestore/12/10/23/H0I7k2e8M069BDdrEDb5ww2.gif
Commits on Nov 25, 2013
  1. Update CONTRIBUTING.md

    authored
  2. Add a contribution doc

    authored
Commits on May 2, 2013
  1. Set background color when frame size is different from requested size

    authored
    Contributed with tests by @holmes in pull request #1, some tweaks made
    (DRY in the test, scoping test dependencies to 'test' in the pom,
    minimised pom.xml diff size by removing whitespace changes)
Commits on Feb 5, 2012
  1. Initial import of Animated-GIF processing code (v1.03) from fmsware.com

    authored
    This code is a re-package of the Animated GIF processing classes made
    available by Kevin Weiner at http://www.fmsware.com/stuff/gif.html, which
    states that the code "may be freely used for any purpose. _Unisys patent
    restrictions may apply to the LZW portions._".
    
    You may find the following link relevant in determining the current extent
    of the Unisys patent restrictions:
    
    http://en.wikipedia.org/wiki/Graphics_Interchange_Format#Unisys_and_LZW_patent_enforcement
    
    The classes are largely unaltered, though as the code was originally placed in
    the 'default' package, I've assigned the Java package name of
    `com.madgag.gif.fmsware`.
    
    This repo is intended mainly for packaging those classes into a
    maven-friendly format - for full attribution of the original code, check
    the Java file headers.
    
    Where alterations have occurred since the initial import, those changes are
    licenced under the Apache V2 licence.
Something went wrong with that request. Please try again.