The joy of animated GIF

[Chipp Walters]

Scott,

I'm pretty sure the reason for the non-optimized redundant pixel removal
MC/RR animated gif is that it's very difficult to do a:

set the currentframe of img "optimized.gif" to 12

unless you have *all* the data in frame 12. Else, you would have to 'step
through' each frame and build frame 12 from the previous frames. Unlike
QuickTime, animated GIF's have no 'keyframes', so you would have to playback
the entire GIF each time you wanted to set the currentframe.

-Chipp

> -----Original Message-----
> From: use-revolution-admin at lists.runrev.com
> [mailto:use-revolution-admin at lists.runrev.com]On Behalf Of Scott Rossi
> Sent: Monday, November 18, 2002 5:48 PM
> To: use-revolution at lists.runrev.com
> Subject: Re: The joy of animated GIF
>
>
> > I have just caught up and discovered how useful animated GIFs
> can be -- I
> > have been making card-based animations since my HC days, and
> although they
> > work in RR, I have encountered some problems controlling the
> sequence with
> > sticky mousedown loops and leaky locking messages. Now the
> entire animation
> > is on one card and I can control the speed, and the sequence, by sending
> > messages to the image. Before I get too happy, are there any
> cross-platform
> > issues or other problems associated with animated GIFs? So far,
> I have only
> > tested on Mac OS 9.2.
>
> As you have discovered, animated GIFs are quite powerful in
> Rev/MC.  You can
> do some very complicated/elaborate things in the environment with a good
> deal of control.  The following is not a cross-platform issue,
> but rather a
> GIF rendering issue to note: Rev/MC may not display optimized GIFs
> consistently or accurately.
>
> 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).
>
> 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.
>
> Regards,
>
> Scott Rossi
> Creative Director
> Tactile Media, Multimedia & Design
> -----
> E: scott at tactilemedia.com
> W: http://www.tactilemedia.com
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution