Hints, tips, things to watch out for
However, some programs which read GIFs (usually those which either don't understand animations, or don't understand transparency) incorrectly ignore the LSD size and use the FD size. These programs include Acorn ChangeFSI, Claris HomePage, and some early (pre-1.60) versions of ANT Fresco. This is a problem as it can lead to Web authors specifying the wrong WIDTH= and HEIGHT= attributes in Web pages. All versions of Netscape and MSIE use the LSD size (at least for GIF89's).
Early versions of the RiscOS program "Creator" only set the FD size and not the LSD size; such images look wrong in MSIE. Netscape cheats! and uses only the FD size for GIF87 images and (correctly) the LSD size for GIF89 images. As of version 1.63, this is Fresco's behaviour too.
Navigator 4, in both the Windows and Solaris versions, gets it wrong if an interlaced image has a border optimised out on the first frame (in the manner described in "Size is important" above). The symptom is that black, non-transparent lines appear every fourth pixel down "transparent" areas of the image. This is unquestionably a bug in Navigator rather than InterGif, especially in view of the fact that Navigator 3.02 gets it right, but (until Netscape release their source code and I can fix it myself...) I've stopped InterGif from optimising out the border if an interlaced GIF is being made.
This means that such GIFs end up being compressed less optimally than they might. If this is a problem (and it may not be, as interlaced GIFs usually end up compressed less well than non-interlaced ones anyway) you can use the new -trim option to remove, rather than just avoid compressing, the transparent border. When using -trim, InterGif's output will not be the same size in pixels as the input image (it is normally). You can use the HSPACE= and VSPACE= attributes of the HTML <IMG> tag to produce a transparent border around a trimmed image.
InterGif tries to anti-alias the Draw file nicely, but this
involves rendering it into a sprite that's three times too big in
each direction, then reducing down to the right size. This can
take a lot of memory (how much depends on the size of the
picture -- in inches on screen, that is, not Kbytes on disc).
InterGif can take a long time to process Draw files. For this reason, if you want to make an animation from your Draw files and then fiddle with it, it's a good idea to convert your Draw files to a sprite-file animation first, then fiddle with converting the sprites to a GIF with all the other options you require.
The palette optimisation options -216, -256, -pal palfile and -best n plain don't work with Draw files. Draw files are effectively always converted with the -216 option: that is, they're anti-aliased to the PC/Mac standard palette.
If you're using the command-line version of InterGif to convert Draw files, you can't use it from a TaskWindow. Press F12 instead. (This is because the Draw file conversion redirects output to a sprite, and if TaskWindow switches control away from InterGif in the middle of that, it all goes horribly wrong.)
Versions of ChangeFSIThere are several different versions of ChangeFSI circulating. The one available on Acorn's FTP site is, at time of writing, version 1.12, but there are later versions: I think these were distributed with RiscOS 3.6 and 3.7. The version I've got calls itself 1.13S, and I can't remember where I got it.
The only problem that older versions cause to InterGif, is that some early versions set ChangeFSI$Dir in their !Run files but not in their !Boot files, so InterGif won't know where to find the ChangeFSI program until ChangeFSI has already been run once. Version 1.12 fixes this.
In some versions of ChangeFSI, the FSIuse help file mentioned above is in !ChangeFSI.Documents rather than !ChangeFSI itself.
ChangeFSI only knows about single-frame filesThis means that if you wish to run ChangeFSI on an animation file -- if, for instance, you've got an animated GIF you want to reduce in size -- you have to use InterGif twice.
The first time, you need to have the Split output files or -split option set: InterGif will produce a whole series of one-frame sprite files.
You then need to feed these sprite files back into InterGif, this time with Join input files or -join selected (plus your ChangeFSI options to reduce size or whatever): this will produce the reduced-size animation file you wanted.
ChangeFSI doesn't know about masking or transparencyChangeFSI treats all input files as having a completely solid mask (no transparency). There isn't really a good workaround for this, as ChangeFSI can't know what background colour to fade "half-lit" edge pixels against.
All you can really do is edit your animation afterwards, in Paint or The Complete Animator, to re-supply the transparency by hand.
Example ChangeFSI settingsIf all you're doing is using ChangeFSI to cope with an input format that InterGif doesn't understand itself, you just need to click on the ChangeFSI... button to open the "InterGif calling ChangeFSI" window, tick the tickbox, and enter
in the Options icon. The "28" tells ChangeFSI to convert things to 256-colour sprites. The command-line equivalent would be something like
intergif in/bmp -o out/gif -c "28"
To reduce the input file to half-size, enter
If you've got a "deep" (16bpp or 24bpp) input image, you can
use ChangeFSI to convert it to a deep sprite, and then tell
InterGif to choose the optimal 256-colour palette, by
My favourite one is converting a whole directory of
output files from POV-Ray for Windows (in 24bpp Targa
format) into a reduced-size animated GIF in one