World Library  
Flag as Inappropriate
Email this Article


ANIM is a file format, used to store digital movies and computer generated animations (hence the ANIM name), and is a variation of the ILBM format, which is a subformat of Interchange File Format.


  • Main Features 1
    • Anim FileTypes 1.1
    • Additions to IFF Standard 1.2
  • History 2
  • Technical Overview 3
    • Compression methods used in Anim format 3.1
    • Playing ANIM files 3.2
  • Influences of ANIM on other Animation filetypes 4
  • External links 5

Main Features

Anim FileTypes

Known filetypes for Anim into AmigaOS are: Anim1, Anim2, Anim3, Anim5 and Anim7. Anim1 to Anim3 did not support audio. Anim 5 and Anim7 should be able to contain Audio Data and being a complete movie animation file format.

Additions to IFF Standard

In addition to the normal ILBM chunks, ANIM filetype also defines:

  • ANHD (ANimation HeaDer)
  • DLTA - stores changes between frames, with various compression methods supported to make use of the redundancy between frames.

Compression modes:

  • ANIM-0 ILBM BODY (no delta compression)
  • ANIM-2 Long Delta mode
  • ANIM-3 Short Delta mode
  • ANIM-4 General Delta mode
  • ANIM-5 Byte Vertical Delta mode (most common)
  • ANIM-6 Stereo Byte Delta mode (stereoscopic frames)
  • ANIM-7 Anim-5 compression using LONG/WORD data
  • ANIM-8 Anim-5 compression using LONG/WORD data
  • ANIM-J Eric Grahams compression format (Sculpt 3D / Sculpt 4D)

It is possible to have several compression modes inside a file.


The ANIM IFF format was developed in 1988 at Sparta Inc., a firm based in California, originally for the production of animated video sequences on the Amiga computer, and was used for the first time in AEGIS Videoscape and Video Titler programs for the Amiga line of computers. As being very efficient and also being an official subset of existing Amiga ILBM/IFF standard file format, it became the de facto standard for any animation file on Amiga.

The file format must had these characteristics:

  • Be able to store, and play back, sequences of frames and to minimize both the storage space on disk (through compression) and playback time (through efficient de-compression algorithms).
  • Maintain maximum compatibility with existing IFF formats and to be able to display the initial frame as a normal still IFF picture.

Several compression schemes have been introduced in the ANIM format. Most of these are strictly of historical interest as the only one currently used is the vertical run length encoded byte encoding developed by Atari software programmer Jim Kent.

Amiga Anim7 format was created in 1992 by programmer Wolfgang Hofer.

The fileformat used by CDTV and Amiga CD32, was called CDXL and were nothing than ANIM files with another name. CD32 supported mainly Anim7.

Technical Overview

Minimum Anim file consists of three ILBM interleaved bitmap images. The first bitmap is necessary for the creation of the "next" frame and the two more for the "history" in order to create the "delta" images calculated as differences from the first one.

The initial frame is a normal run-length-encoded, IFF picture, and this allows to have an initial preview of the contents of the file. Subsequent frames are then described by listing only their differences from a previous frame.

While the actual frame is shown on, the subsequent frame is loaded into a swap buffer page of graphic memory and Amiga switch between the screens istantanely while loading the subsequent frames thanks to its bit-blitter circuit capabilities and the DMA feature of its graphic chipset that could access memory without asking request of the CPU. This technique is called double buffering.

To better understand this, suppose one has two screens, called A and B, and the ability to instantly switch the display from one to the other. The normal playback mode is to load the initial frame into A and duplicate it into B. Then frame A is displayed on the screen. Then the differences for frame 2 are used to alter screen B and it is displayed. Then the differences for frame 3 are used to alter screen A and it is displayed, and so on. Note that frame 2 is stored as differences from frame 1, but all other frames are stored as differences from two frames back.

ANIM is an IFF FORM and its chunk structure is as follows:


  • FORM ILBM (first frame)
    • BMHD (normal type IFF data)
    • ANHD (optional animation header chunk for timing of 1st frame)
    • CMAP (Colormap)
    • BODY
  • FORM ILBM (frame 2)
    • ANHD (animation header chunk)
    • DLTA (delta mode data)
  • FORM ILBM (frame 3)
    • ANHD
    • DLTA

(And so on...)

The initial FORM ILBM can contain all the normal ILBM chunks, such as CRNG, etc. The BODY will normally be a standard run-length-encoded data chunk (but also any other legal compression mode as indicated by the BMHD). If desired, an ANHD chunk can appear here to provide timing data for the first frame. If it is here, the operation field should be =0.

The subsequent FORMs ILBM contain an ANHD, instead of a BMHD, which duplicates some of BMHD and has additional parameters pertaining to the animation frame. The DLTA chunk contains the data for the delta compression modes. If the older XOR compression mode is used, then a BODY chunk will be placed here. In addition, other chunks may be placed in each of these as deemed necessary (and as code is placed in player programs to utilize them). For example the CMAP chunks to alter the color palette.

A basic assumption in ANIMs is that the size of the bitmap, and the display mode (e.g. HAM) will not change through the animation.

The DLTA chunks are not interleaved bitmap representations, thus the use of the ILBM form is inappropriate for these frames. However, this inconsistency was not noted until there were a number of commercial products either released or close to release which generated/played this format.

Compression methods used in Anim format

Anim format allow five methods of compression: XOR mode, Long Delta mode, Short Delta mode, General Delta mode and Byte Vertical Compression.

Playing ANIM files

Playback of ANIMs will usually require two buffers, as mentioned above, and double-buffering between them. The frame data from the ANIM file is used to modify the hidden frame to the next frame to be shown. When using the XOR mode, the usual run-length-decoding routine can be easily modified to do the exclusive-or operation required. Note that runs of zero bytes, which will be very common, can be ignored, as an exclusive or of any byte value to a byte of zero will not alter the original byte value. The general procedure, for all compression techniques, is to first decode the initial ILBM picture into the hidden buffer and double buffer it into view. Then this picture is copied to the other (now hidden) buffer. At this point each frame is displayed with the same procedure. The next frame is formed in the hidden buffer by applying the DLTA data (or the XOR data from the BODY chunk) and the new frame is double-buffered into view. This process continues to the end of the file.

Influences of ANIM on other Animation filetypes

The Anim standard of Amiga influenced the development of Animated GIF format.

External links

  • Amiga Animations - A collection of animations created with the Amiga computer.
  • ANIM specification by Sparta Inc. and Aegis Development Co., revised 4 May 1988
This article was sourced from Creative Commons Attribution-ShareAlike License; additional terms may apply. World Heritage Encyclopedia content is assembled from numerous content providers, Open Access Publishing, and in compliance with The Fair Access to Science and Technology Research Act (FASTR), Wikimedia Foundation, Inc., Public Library of Science, The Encyclopedia of Life, Open Book Publishers (OBP), PubMed, U.S. National Library of Medicine, National Center for Biotechnology Information, U.S. National Library of Medicine, National Institutes of Health (NIH), U.S. Department of Health & Human Services, and, which sources content from all federal, state, local, tribal, and territorial government publication portals (.gov, .mil, .edu). Funding for and content contributors is made possible from the U.S. Congress, E-Government Act of 2002.
Crowd sourced content that is contributed to World Heritage Encyclopedia is peer reviewed and edited by our editorial staff to ensure quality scholarly research articles.
By using this site, you agree to the Terms of Use and Privacy Policy. World Heritage Encyclopedia™ is a registered trademark of the World Public Library Association, a non-profit organization.

Copyright © World Library Foundation. All rights reserved. eBooks from Project Gutenberg are sponsored by the World Library Foundation,
a 501c(4) Member's Support Non-Profit Organization, and is NOT affiliated with any governmental agency or department.