8 GIF File Writing

(require file/gif)

The file/gif library provides functions for writing GIF files to a stream, including GIF files with multiple images and controls (such as animated GIFs).

A GIF stream is created by gif-start, and then individual images are written with gif-add-image. Optionally, gif-add-control inserts instructions for rendering the images. The gif-end function ends the GIF stream.

A GIF stream can be in any one of the following states:

• 'init : no images or controls have been added to the stream

• 'image-or-control : another image or control can be written

• 'image : another image can be written (but not a control, since a control was written)

• 'done : nothing more can be added

The width and height determine a virtual space for the overall GIF image. Individual images added to the GIF stream must fit within this virtual space. The space is initialized by the given background color.

Finally, the default meaning of color numbers (such as the background color) is determined by the given colormap, but individual images within the GIF file can have their own colormaps.

If interlaced? is true, then bstr should provide bytes ininterlaced order instead of top-to-bottom order. Interlaced order is:

• every 8th row, starting with 0

• every 8th row, starting with 4

• every 4th row, starting with 2

• every 2nd row, starting with 1

If a global color is provided with gif-start, a #f value can be provided for cmap.

The bstr argument specifies the pixel content of the image. Each byte specifies a color (i.e., an index in the colormap). Each row is provided left-to-right, and the rows provided either top-to-bottom or in interlaced order (see above). If the image is prefixed with a control that specifies an transparent index (see gif-add-control), then the corresponding “color” doesn’t draw into the overall GIF image.

The GIF image model involves processing images one by one, placing each image into the specified position within the overall image’s virtual space. An image-control command can specify a delay before an image is added (to create animated GIFs), and it also specifies how the image should be kept or removed from the overall image before proceeding to the next one (also for GIF animation).

The disposal argument specifies how to proceed:

• 'any : doesn’t matter (perhaps because the next image completely overwrites the current one)

• 'keep : leave the image in place

• 'restore-bg : replace the image with the background color

• 'restore-prev : restore the overall image content to the content before the image is added

If wait-for-input? is true, then the display program may wait for some cue from the user (perhaps a mouse click) before adding the image.

The delay argument specifies a delay in 1/100s of a second.

If the transparent argument is a color, then it determines an index that is used to represent transparent pixels in the follow image (as opposed to the color specified by the colormap for the index).

Given a set of pixels expressed in ARGB format (i.e., each four bytes is a set of values for one pixel: alpha, red, blue, and green), quantize produces produces

• bytes for the image (i.e., a array of colors, expressed as a byte string)

• a colormap

• either #f or a color index for the transparent “color”

The conversion treats alpha values less than 128 as transparent pixels, and other alpha values as solid.

The quantization process uses Octrees [Gervautz1990] to construct an adaptive palette for all (non-transparent) colors in the image. This implementation is based on an article by Dean Clark [Clark1996].

To convert a collection of images all with the same quantization, simply append them for the input of a single call of quantize, and then break apart the result bytes.