Re: !! GRAPHICS QUESTION !!

What I really really hate these days is the over-dependence on
"speciality tools" and that over-zealousness to reply to a post
without even reading the *full* text, let along understand it.

There was that torn-paper thing and people were like "use filters #1"
and "use filter-set #X" etc. etc. while it is quite simple to achive
it using a software that was mentioned in the original question. What
happened of those glorious days when I used to read so many "how-to"
posts over here?

Anyway, this question came and it went and I saw only 2 replies. Such
a shame because this is, afterall, a good question and everybody is
not an expert in creating small-filesize animations....

Let me attempt an answer with the hope that above 3 paragraphs were a
reality-check for at least a few people:

Fuzzy is right in saying that some cool animations might load in what
seems like "ultra-short duration". His example of car is quite good.
And the best thing is that making these kind of graphics doesn't take
much brains.

"So, what are the basics?"
  Anybody who wants to make raster-image animation knows that it
  will be saved ONLY as a .GIF file. I've come across people who
  do not know that the format will be GIF89a (at least, I've been
  told this - correct me if I'm wrong).

"GIF89a? Hey! I've heard that before!"
  Yes, you have. It is the format of .GIF files that have that
  cool ability to have those 'transparent' backgrounds.

"I think I'm getting a picture now"
  Thought so. See. When you're making an animation, the used
  technology is quite different from that of motion-picture
  technology. In the latter, *each* frame is stored individually
  and then rapidly replaced to create an "illusion" of motion.

  However, in our case, we use the technology called "residual
  image technology" (hey! i'm about to patent the name. Come to
  think of it.... i might be the father of a new 'term'! And...)

"Hey! Back to topic. What's this RIT?"
  Basically, what we do is, we create a full image in the first
  frame - the scenary, etc. the works! And then on top of that,
  we move our little objects and make people believe that
  they're moving in the scenery. (something like what they do in
  animated movies)

"That's where transparency kicks in right?"
  Right. Let me explain more. Let's take a grid. In the first
  frame I'm drawing the whole scene; 1a through 4x, a total of
  96 grid boxes. But in the next frame, i'm only drawing 8
  grid-boxes: 3d through 3k. But to the viewer, my "..ooOO)"
  will appear to have moved a full notch to the right.

  Frame #1      abcdefghijklmnopqrstuvwx

            1   ########################
            2   ########################
            3   ###..ooOO)##############
            4   ########################

  Frame #2      abcdefghijklmnopqrstuvwx

            1
            2
            3      #..ooOO)
            4

"But what about the filesize mon?"
  Just coming to that. If you have made any GIF89a static files
  with just 32 colours, etc., you very well know that the file
  size is extremely small since the description-bit-weight is
  low. A 4-bit file describing a 200x100 will definitely be
  *much* smaller than a full 8-bit file. Since the animated GIF
  has a single palette and you control the big-weight... ;-)

  You see that in the above example, only the first frame, which
  describes the 96 grid-boxes makes up the bulk of the size. The
  follow-up frames are *very low* on content and hence _hardly_
  add much in K-force to the image size (most of it is transparent
  and the way GIF compresses, using "areas", the transparent
  area hardly takes *any* space being described in the file - it
  being a chunk)

"And hence, I have my cool animated GIF?"
  Yep. Work on the above principles, and you will get 'em. :)

"Does the software matter?"
  Sometimes it does. Sometimes it doesn't. The major thing is
  getting those 'frames' done in properly.

  Some software require that you have individual frames saved
  as independent .GIF files before they will mould them together.

  Some newer software can read 'proprietory' formats like .PSD
  (of Adobe Photoshop) and pick up the frames from the file
  description (in this case, each layer making up a frame).

  Eventually they will help you optimise the final palette
  used. At first, they will either use the full RGB descriptor
  or add-up individual palettes from the .GIF files to create
  a larger palette.

  We know that one of the major keys to small file-size is
  that we keep the descriptor weight as low as possible. You
  should *always* aim for the lowest possible which will not
  distort your work. Remember, 4-bit file will be smaller than
  a 6-bit file which will be smaller than a 8-bit file,even if
  they're versions of the same animation, just with different
  different descriptor-weights. :)
 
Note: Near the lower part, I have used the term "descriptor-weight".
      I think I need to explain this more.

      When you have a 4-bit file - it essentially means that you are
      using 4 bits or half-a-byte to save information about one
      single pixel of your image. 8-bit means that you're using a
      byte to save information about one single pixel of your image.

      GIF compression works in a way that stores the "areas" of your
      image which are of the same colour, that is, have "identical"
      description that is stored in those "bits". That is the reason
      why you will notice that a 400x250 flag of italy will store in
      a much smaller file than a rainbow even if they are saved using
      the same number of bits describing them.

      It is this "bit-depth" that I have mnemonically used above as
      "descriptor-weight".

[abhay]

PS: I might have made some educated guesses along the way (I'm not
    sure) but if there is any "wrong" information up there, I'd sure
    like to hear about it. :)

----- Original Message -----
From: Captain F.M. O'Lary <ctfuzzy(at)obiwan.TerraNova.net>
Sent: Thursday, October 07, 1999 3:48 AM


> I have noticed some really cool animations on the web where
> there is a fairly large image that has a small component that
> moves across it (obviously an animation - duuh).
>
> I noticed that these files are often very much faster to
> load than a 'normal' animation would be if the image
> background was in each frame ie: Lets take for example, a
> car traveling down a road with an 'open country' background.
> The car obviously moves, but the whole dang file is something
> like 12-14K and it's a 300X 400 pixel image. OBVIOUSLY the
> background can not be in each frame of the animation or it
> would be a 5600000000K file!
>
> Question:
>
> What are some of the tips/techniques for creating this type
> of animation?

HWG: hwg-graphics mailing list archives, maintained by Webmasters @ IWA