The joy of animated GIF

Scott Raney raney at metacard.com
Tue Nov 19 13:22:01 EST 2002


On Mon, 18 Nov 2002 Scott Rossi <scott at tactilemedia.com> wrote:

Just a minor correction here:

> In a Web browser environment, the browser has the ability store the contents
> of the first frame it encounters in the GIF, and then render each subsequent
> frame on top of the first.  The browser can also account for redundant
> pixels, meaning that your GIFs can weigh in lighter since you can eliminate
> duplicate pixels that occur in subsequent frames.  These rendering features
> are not present in Rev/MC's handling of GIFs, and may cause your GIF to
> render unexpectedly in Rev/MC.  You can work around this by rendering your
> GIFs with complete frames (including any transparency).

Actually it's not the deltas between frames that are the problem, it's
the fact that some encoders "cheat" by not even encoding the deltas
for the mask at all.  This looks right if you always go forward
through the movie and draw each frame in the same location, it won't
if you don't, nor is it possible to use the image mask to "hit test"
the image to see if the user is clicking on it.  There is a hack
workaround for this cheat that you might try if you're stuck with a
GIF that's been encoded this way and that is to set the image's
"constantMask" property to true.  Unfortunately this can't be the
default because it breaks hit-testing on images that do have the mask
properly encoded.

> Using Adobe's ImageReady for example, I create an animation as needed and
> then, using a color not present in the animation, I introduce a solid color
> frame between every frame of my original animation.  This forces ImageReady
> to generate an animated GIF without any optimization (redundant pixel
> removal, etc).  I then open the GIF in a simple GIF editor (GIFMation),
> delete all the solid color frames and resave.  The final file contains a
> complete image on every frame of the animation and is suitable for display
> in Rev/MC.  True, the filesize will weight in heavier than an optimized GIF,
> but the resulting display behavior will be predictable.

Not sure if the various GIF encoders have a specific option for
disabling only this cheat, but your workaround is a little more
brute-force than should be necessary and disables even the *legal*
delta encoding, resulting in much larger file sizes than necessary.
  Regards,
    Scott

> Regards,
> 
> Scott Rossi
> Creative Director
> Tactile Media, Multimedia & Design
> -----
> E: scott at tactilemedia.com
> W: http://www.tactilemedia.com

********************************************************
Scott Raney  raney at metacard.com  http://www.metacard.com
MetaCard: You know, there's an easier way to do that...




More information about the use-livecode mailing list