There are many animation graphics file formats, some of which are more suitable for certain types of data. This section of this report examines some animated graphics file formats in detail, and is followed by a summary of other formats.
Animation is moving images, but different file formats handle the data in different ways. Animations are usually split up into frames, each of which is a "snapshot" of an instance of the animation. The formats vary from having a separate graphical image for each frame, to only maintaining the changes between frames, to specifying the animation sequence as a computer program.
Sound is a common feature of animations, but with sound comes the added complexity of synchronising the sound with the images. Some formats neglect this synchronisation factor, and play the sound independent of the images. This can result in sounds occurring at inappropriate times.
File sizes can be large for animations, therefore compression is often used to reduce the file size. This comes at the cost of additional creation time, but can (for some file formats) increase the playback rate. Another drawback of compression is that some formats loose picture quality (this is typical of lossy compression techniques).
The first file format that is discussed in detail is the FLI, FLC file format. This format stores the changes between frames. The colour map can be changed during the animation.
The second file format discussed is GRASP. This format uses an animation programming language to render objects onto the screen (in 2D or 3D) and then allows animation commands to be applied to the view.
The MPEG file format is discussed in a significant amount of detail, and is included for its synchronisation of video and audio packets. MPEG is particularly concerned with having data uncompressed and ready at a certain time.
Following these detailed explanations, a summary of many different animated file formats is given, but this is in no way supposed to contain all animation formats available. It does however cover a reasonable number of formats.
1.1 Selected Animation
File Formats in Detail
1.1.1 FLI, FLC
Acronym
FLI - Flic Files: Autodesk Animator
FLC - Flic Files: Autodesk Animator Pro, 3D Studio
Versions
Version 1.0 FLI Supports only 320 200 pixel images
Version 1.0 FLC Supports any size image and 256 entry colour tables
Data Types
Number of frames in animation sequence
Size of images
Speed of display
Raster image data
Overview
Major Type of Data 2D raster; animation
Colour Representation Colour table
Data Organisation Sequential
Data Encoding Binary
Data Compression None, run-length encoding
Data Organisation
A FLI or FLC file has a 128-byte header followed by a sequence
of frames. An optional prefix chunk may immediately follow the
animation file header. The first frame is compressed using a
bytewise run-length compression scheme. Subsequent frames are
stored as the difference from the previous frame. (Occasionally
the first frame and/or subsequent frames are uncompressed.) There
is one extra frame at the end of a FLI or FLC which contains the
difference between the last frame and the first frame (called
the ring frame).
FLI Header
A 128-byte header with the following data values (stored in LSB first).
Note: This is the FLI header which is a subset of the FLC header.
| Details | ||
| Length of file in bytes (including this header). This is for programs that want to read the FLI all at once if possible | ||
| Always Hex AF11 | ||
| Number of frames (maximum = 4000). This does not include the ring frame | ||
| Screen width in pixels: 320 | ||
| Screen height in pixels: 200 | ||
| Bits per pixel (always 8) | ||
| Always 0 in FLI file | ||
| Number of video ticks (jiffies) between frames during playback; a jiffy is 1/70 of a second | ||
| Set to 0 | ||
| Set to 0 | ||
| All zeroes; for future expansion |
FLC Header
A 128-byte header with the following data values (stored in LSB
first).
| Details | ||
| Length of file in bytes (including this header). This is for programs that want to read the FLC all at once if possible | ||
| Always Hex AF12 | ||
| Number of frames (maximum = 4000). This does not include the ring frame | ||
| Screen width in pixels: 320, 640, 800, 1280 | ||
| Screen height in pixels: 200, 480, 600, 1024 | ||
| Bits per pixel (always 8) | ||
| Set to Hex 0003 after ring frame is written and FLC header is updated. This indicates that the file was properly finished and closed. | ||
| Number of milliseconds to delay between each frame during playback. | ||
| Set to 0 | ||
| The MSDOS-formatted date and time of the file's creation | ||
| The serial number of the Animator Pro program used to create the file. If the file y some other program using the FlicLib development kit, this value is Hex 464C4942 ("FLIB") | ||
| The MSDOS-formatted date and time of the file's most recent update | ||
| Indicates who last updated the file. See Creator above | ||
| The x-axis aspect ratio at which the file was created | ||
| The y-axis aspect ratio at which the file was created. Most often the x:y aspect ratio will be 1:1. A 320 200 FLC has a ratio of 6:5 | ||
| Set to 0 | ||
| Offset from the beginning of the file to the first animation frame chunk | ||
| Offset from the beginning of the file to the second animation frame chunk. is value is used when looping from the ring frame back to the second frame during playback. | ||
| All zeroes; for future expansion |
Prefix Header
An optional prefix chunk may immediately follow the animation
file header. This chunk is used to store auxiliary data which
is not directly involved in the animation playback. The prefix
chunk starts with a 16-byte header (identical in structure to
a frame header) as follows:
| Details | ||
| Length of prefix chunk in bytes, including this header and all subordinate chunks that follow. | ||
| Prefix chunk identifier. Always Hex F100 | ||
| Number of subordinate chunks in the prefix chunk | ||
| All zeroes; for future expansion |
To determine whether a prefix chunk is present, read the 16-byte header following the file header. If the type value is Hex F100, it is a prefix chunk. If the value is Hex F1FA it is the first frame chunk and no prefix chunk exists.
Programs other than Animator Pro should never need to create
Flic files that contain a prefix chunk. Programs reading a Flic
file should skip the prefix chunk by using the size value in the
prefix header to read and discard the prefix, or by seeking directly
to the first frame using the OFrame1 field from the file header.
Frame Header
Each frame has a header consisting of:
| Details | ||
| Length of frame in bytes (must be 64K - Autodesk Animator demands this) | ||
| Always Hex F1FA | ||
| Number of chunks in frame | ||
| All zeroes; for future expansion |
Chunks
The data for a frame is divided into chunks of data. If the colour table changes from one frame to the next, then the first chunk contains a colour table. The second chunk contains the pixel data in one of several different possible formats. This chunk will not be used if pixel data has not changed from the previous frame. If the frame is absolutely identical to the last frame there will be no chunks at all.
A chunk itself has a header followed by the data. All chunks
are aligned to word (even address) byte offsets. If the compressed
data ends up being an odd length a single pad byte is inserted
so that the FLI_COPY's always start at an even address for faster
DMA.
| Details | ||
| Length of chunk in bytes | ||
| Type of chunk (see below) | ||
| The colour or pixel data |
There are currently eight types of chunk, but not all are supported
by both FLI and FLC file formats.
| Description | ||
| Compressed colour table (colour range from 0 to 255) | ||
| Word-oriented delta compressed line data (FLC only) | ||
| Compressed colour table (colour range from 0 to 63) | ||
| Byte oriented delta compressed line data (FLI only) | ||
| Set whole screen to background colour 0 (first frame only) | ||
| Byte run-length compression (first frame only) | ||
| Uncompressed pixels; 64000 bytes (320 200) | ||
| Postage stamp sized image (FLC only) |
FLI_COLOR and FLI_COLOR256 Chunks
A colour chunk is divided into packets. A packet is composed
of a skip value, a change value, and a set of RGB values as shown
below. The RGB values in the FLI_COLOR chunk are limited to a
range from 0 to 63. The RGB values in the FLI_COLOR256 chunk
are limited to a range from 0 to 255.
| Details | ||
| Number of packets in chunk | ||
| Number of colours to skip in the colour table | ||
| Number of RGB values that follow (0 means 256) i.e. how many colours to change | ||
| New entry for colour table | ||
| More RGB values | ||
| Possibly more packets (i.e. skip, change, RGB values) |
FLI_LC (Line Coded) Chunks
This is only used by FLI. In the worst case a FLI_LC frame can
be about 70K. If it comes out to be 60000 bytes or more Autodesk
Animator decides to abandon compression and saves the frame as
FLI_COPY.
| Details | ||
| Number of lines in this frame that are unchanged from the previous frame (from top of screen). | ||
| Number of scan lines in this chunk | ||
|
| Compressed Pixel data |
"Unchanged Lines" is the number of lines starting
from the top of the screen that are the same as the previous frame.
e.g. if there is motion only on the bottom line of the screen
there would be a 199 here.
Compressed Line
Since each line is compressed individually, this makes it much
easier to play back the FLI at a reduced size.
| Details | ||
| Starting position on this scan line for data | ||
| Number of packets for this scan line | ||
|
| 0 or more run-length packets |
Run-length packet
If more than 255 pixels are to be skipped, the skip count must
be broken into two packets.
| Details | ||
| Number of pixels to skip on a scan line from current location | ||
| >0: count bytes follow
<0: one byte follows; repeat |count| times | ||
FLI_SS2 Chunks
This chunk is similar to the FLI_LC chunk except it is word-oriented
(2 bytes) instead of byte-oriented. This is the format most often
used by Animator Pro for frames other than the first frame of
an animation.
FLI_BLACK
No data is stored in this chunk; it is used to clear the screen
to the background colour (index 0).
FLI_BRUN (Byte Run-length)
Exactly like the FLI_LC chunk above - except there are no "skip
count" values in each run-length packet. The entire image
is run-length encoded. Usually this chunk is used in the first
frame of an animation, or within a postage stamp image chunk.
FLI_COPY
There is no compression. The contains exactly (image width)
(image height) bytes that define an image in scan-line order from
left to right and then top to bottom. This type of chunk is created
when the preferred compression method (SS2 or BRUN) generates
more data than the uncompressed frame image; a relatively rare
situation. For FLI files the chunk contains 64000 bytes for a
320 200 pixel image.
FLI_PSTAMP (Postage Stamp Image)
This is only used by FLC. This chunk type holds a postage stamp - a reduced-size image - of the frame. It generally appears only in the first frame chunk within an FLC file.
When creating a postage stamp, Animator Pro considers the ideal size to be 100 63 pixels. The actual size will vary as needed to maintain the same aspect ratio as the original.
The pixels in a postage stamp image are mapped into a six-cube
colour space, regardless of the colour palette settings for the
full frame image. A six-cube colour space is formed as follows:
| start at palette entry 0
for red = 0 to 5 for green = 0 to 5 for blue = 0 to 5 palette_red = (red * 256)/6 palette_green = (green * 256)/6 palette_blue = (blue * 256)/6 move to next palette entry end blue end green end red |
When a frame data chunk has been identified as a postage stamp,
the header for the chunk contains more fields than just size and
type. The full postage stamp header is defined as follows:
| Details | ||
| The size of the postage stamp chunk (including this header) | ||
| Always Hex 18 | ||
| Height of the postage stamp in pixels | ||
| Width of the postage stamp in pixels | ||
| Colour translation type; always 1, indicating six-cube colour space |
Immediately following this header is the postage stamp data.
The data is formatted as a chunk with standard size/type header.
The type will be one of:
| Description | ||
| Byte run-length compression (first frame only) | ||
| Uncompressed pixels; 64000 bytes (320 200) | ||
| Six-cube colour Xlate table |
The FPS_BRUN and FPS_COPY types are identical to the FLI_BRUN and FLI_COPY encoding methods described above.
The FPS_XLAT256 type indicates that the chunk contains a 256-byte colour translation table instead of pixel data. To process this type of postage stamp, read the pixel data for the full-sized frame image, and translate its pixels into six-cube space using a lookup in the 256-byte colour translation table. This type of postage stamp appears when the size of the animation frames is smaller that the standard 100 63 postage stamp size.
Filename Suffix
DOS .fli, .flc
Unix .fli, .flc
1.1.2 GRASP
Acronym
GRAphical System for Presentation
Versions
Version 1.10 May 1986
Version 2
Version 3.1
Overview
Major Type of Data 2D raster; 2D geometric; animation control
Colour Representation Colour table
Data Organisation Animation language is random access
Data Encoding ASCII
Data Compression None for animation language
Data Types
The GRASP language accepts the following commands. The commands
are divided according to function.
| Graphics commands | |
| CLEARSCR | Clear screen |
| POINT x, y,<x2, y2> | Draw a point |
| LINE x, y, x2, y2 | Draw a line |
| BOX x, y, x2, y2, <width> | Draw a box |
| CIRCLE x, y, rx, <ry> | Draw an ellipse |
| TEXT x, y, "some text", <delay> | Put up text @ x,y |
| COLOR colour 1, <colour 2> | Set colour 1 and colour 2 |
| FGAPS <char_gap, space_gap> | Set text gaps |
| FSTYLE style | Set text style |
| OFFSET x, y | Set x and y for relative addressing |
| WINDOW x0, y0, x1, y1 | Set clip window |
| Animation commands | |
| CFADE #, x, y, <buffer>, <speed>, <delay> | Fade a clipping to screen |
| FLOAT xs, ys, xe, ye, step, delay, clp1... | Float clip across screen |
| FLY xs, ys, xe, ye, step, delay, clp1... | Fly clip across screen |
| PFADE #, <buffer>, <speed>, <delay> | Fade a picture to the screen |
| PUTUP x, y, <buffer>, <delay> | Put a clip to the screen |
| TRAN on/off, colour | Transparent mode on/off |
| Memory commands | |
| CFREE buffer, <buffer>, ... | Free up clipping buffers |
| CLOAD clipping filename, <buffer> | Load a clipping |
| FFREE | Free the font buffer |
| FLOAD character set filename | Load a font |
| PFREE buffer, <buffer>, ... | Free up picture buffers |
| PLOAD picture filename, <buffer> | Load a picture |
| Device commands | |
| CHGCOLOR from, to, <from, to>, ... | EGA, change colour index |
| MODE border colour, <palette> | CGA border and palette set |
| PALETTE border | EGA mode set palette |
| NOISE freq1, freq2, duration | Make some noise |
| PAN x0, yo, x1, y1, <buffer> | EGA pan image |
| RESETSCR | Reset screen to default |
| SETCOLOR c1, c2, c3, ..., c16 | EGA mode set 16 colours |
| VIDEO videomode | Set video mode |
| Program control commands | |
| EXEC program, <parameters> | Execute program from GRASP |
| EXIT | Quit program |
| GOSUB | Execute a subroutine |
| GOTO label | Go to a labelled statement |
| IFKEY label | If key match, goto label |
| LINK textfile filename | Link to another text file |
| LOOP | Loop to a previous statement |
| MARK loop count | Mark for looping |
| RETURN | Return from a subroutine |
| WAITKEY <timeout>, <label> | Wait for a key press |
Data Organisation
The language is line oriented. Each line contains one of the following:
The language definition includes jumps (goto), looping (mark/loop), and subprograms (gosub). The data stream must be random access to support these constructs.
Filename Suffix
DOS .txt The GRASP command file
.pic An image
.clp An image with no colour map
.set A font
.fnt A font
.GL A combined archive of all of the above
1.1.3 MPEG
Acronym
Moving Picture Experts Group
Formal Title: Coded Representation of Picture, Audio and
Multimedia/Hypermedia
Information
ISO CD 11172 Title: Information Technology - Coding of moving
pictures and associated audio - For digital storage media at up
to about 1.5 Mbits/s
Versions
Committee Draft (CD) November 1991
Draft International Standard (DIS) March 1992
International Standard (IS) March 1993
Overview
MPEG defines three distinct functions:
| Synchronisation of multiple compressed streams on
playback
Interleaving of multiple compressed streams into a single stream on creation Initialisation of buffering for playback start up Continuous buffer Management Time Identification |
| Encoding and decoding of sequences of 2D raster images or traditional video |
| Encoding and decoding of sound and audio |
The following discussion summarises the system layer and the video codec in two separate sections.
Overview (System layer)
Major Type of Data Timing and synchronisation; data packets
Colour Representation None
Data Organisation Sequential
Data Encoding Binary
Data Compression None
Up to 32 audio and 16 video streams may be multiplexed simultaneously,
along with up to 16 "private" data streams
Data Organisation (System
layer)
Pack Header
This includes the following:
| System clock reference | This indicates the intended time of arrival of the last byte of the "system clock reference field" at the input of the system target decoder |
| Multiplex rate | The rate at which the system target decoder receives the data stream during the pack; measured in 50 bytes/s (rounded up) |
System Header
This includes the following:
| Rate bound | The maximum multiplex rate of any pack in the data stream |
| Audio bound | The maximum number of audio streams (up to 32 allowed) |
| Fixed flag | Indicates a fixed bit-rate or a variable bit-rate operation mode |
| CSPS flag | Indicates whether the data stream is a "constrained system parameters stream" |
| System audio lock flag | Indicates whether there is a specified, constant harmonic relationship between the audio sampling rate and the system clock |
| System video lock flag | Indicates whether there is a specified, constant harmonic relationship between the video sampling rate and the system clock |
| Video bound | The maximum number of video streams (up to 16 allowed) |
Overview (Video Data)
Major Type of Data Raster (2D digital video)
Colour Representation YCrCb (4:1:1)
Data Organisation Sequential
Data Encoding Binary
Data Compression DCT: for individual frame images
Differencing (with motion compensation) - for temporal
compression between frames
The size of the pictures and the frame rate is not mandated by
the MPEG standard. However the target data rate of 1.5 Mb/s effectively
limits these parameters. The practical limits are approximately
350 250 pixels displayed at 24 to 30 pictures per second. MPEG
does not support scan-line interlacing.
Data Types (Video Data)
Three types of picture encodings are defined:
Intra (I) Pictures
These pictures are encoded without reference to any other pictures.
They are compressed by using DCT and by sub-sampling the chrominance
information (CrCb) of the picture at half the spatial resolution
of the luminance information (Y).
Predicted (P) Pictures
These pictures are coded in reference to a previous "I picture"
(or another "P picture"). Only the differences between
the current picture and the previous reference picture are stored.
Typically the differences are small. To reduce the differences
even further, "motion vectors" are stored to indicate
shifts in the horizontal or vertical directions between the pictures.
Offsetting a 16 16b macroblock of pixels by a motion vector
"lines up" the values so that their differences are
as small as possible (and often zero).
Bidirectional (B) Pictures
These pictures are encoded in reference to either previous or future pictures ("I" or "P" pictures). Forward motion vectors reference previous pictures and backward motion vectors reference future pictures.
B Frames are disliked by some people due to the computational
complexity, bandwidth, delay and picture buffer size. Computation
complexity is increased since some macroblock modes require averaging
between two macroblocks. In the worst case, memory bandwidth
is increased an extra 16 MByte/s (601 rate) for this extra prediction.
In addition to this, an extra picture buffer is needed to store
the future prediction reference (bi-directionality). Finally,
extra delay is introduced in encoding since the frame used for
backwards prediction needs to be transmitted to the decoder before
the intermediate B-pictures can be decoded and displayed.
Data Organisation (Video
Data)
The following picture denotes the conceptual organisation
of the data stream (in terms of picture order):
Note: The order of the pictures in the data stream does not match the order in which they are displayed. They are ordered in the data stream to simplify decoding. During video playback, the B pictures are displayed before the P pictures.
The number of P pictures and B pictures included in the data stream is not specified by the standard. More P and B type encodings produces better compression at the cost of poorer image quality. Limiting the P and B type encodings produces better compression at the cost of poorer image quality. Limiting the P and B type encodings typically increases image quality at the cost of higher data rates (i.e. lower compression).
The actual syntax of the data stream is:
There are exactly 6 data blocks per macroblock.
Sequence Header
This contains information related to one or more
"group-of-pictures"
| Details | ||
| In Hex 000001B3 | ||
| In pixels | ||
| In pixels | ||
| See below | ||
| See below | ||
| In units of 400 bits/s (rounded up) | ||
| Always 1 | ||
| Minimum buffer needed to decode this sequence of pictures; in 16 KB units | ||
| 0 : false; 1 : true (matrix follows) | ||
| Optional | ||
| 0 : false; 1 : true (matrix follows) | ||
| Optional | ||
| Optional | ||
| Optional application-dependent data |
Aspect ratios are defined by a code which represents the height and width of the Video image. Picture rates are also defined by a code that represents the number of pictures that may be displayed each second.
Each group of pictures has a header that contains one "I
picture" and zero or more B and P pictures. The header is
concerned with the time synchronisation for the first picture
in this group, and the closeness of the previous group to this
one.
Filename Suffix
Dos .mpg
Unix .mpg
.mpeg
1.2 Animation File
Formats Short Summary
This section contains a short summary of many different (and some
not so different) animated file formats.
1.2.1 ANM
DeluxePaint Animation ".ANM" files consist of a large header and a series of structures that can be up to 64 KB long each. The programmer refers to these structures as "Large Pages". Large Pages are a format for dividing a file into 64 KB chunks that can be stored out-of-sequence in the file. That is, a large page can be logically inserted into the file, without having to move all the following data out of the way.
Each large page holds one or more "records". A record represents one frame of the original animation. A record is of any length from 0 to almost 64 KB. The records in a large page are sequential. However, the first large page may not contain the first frames of the animation file. Each large page contains a sequential set of records but the large pages themselves are not in sequential order. It is possible for the first large page in a file to contain the last few frames of the animation. When the animation file is processed the large page structures must be scanned to determine which large page contains the frame you wish to display or process next.
An ANM file is built on this mechanism, so that as frames
change in size, they can be maintained with a minimum of extra
file i/o, yet without loss of playback performance. In addition,
there is an optional special record which is the delta from the
last frame to the first frame, for smooth playback of looping
animations.
1.2.2 AVI
The AVI (Audio Video Interleave) format was developed by Microsoft, and is a common format on PC's. It is a RIFF file specification used with applications that capture, edit, and playback audio-video sequences. In general AVI files contain multiple streams of different types of data.
The format is interleaved such that video and audio data are stored consecutively in an AVI file (i.e. a segment of video data is immediately followed by a segment of audio data). Each frame is also compressed.
AVI hopes that the video and sound frames synchronise together - instead of synchronising to a common clock, video plays at its own clock rate and sound is clocked to its sample rate. The AVI architecture also means that a silent VFW file must include a "silent" (null) sound in order to play correctly which leads to a waste of bandwidth.
1.2.3 DL
This animation file format, developed by Davide Tome' and Luca
De Gregorio, is not public domain.
1.2.4 DPX
This is a standard developed by the Society of Motion Picture and Television Engineers (SMPTE). It is a file format for the exchange of digital moving pictures on a variety of media between computer-based systems. It does not define the characteristics of input or output devices or displays. DPX is, in fact, the Kodak Cineon raster file format with a few slight modifications to the file's header.
The DPX specification is referred to as the ANSI/SMPTE 268M-1994
Standard.
1.2.5 FLM
This is a low resolution colour Atari ST format. The speed and direction of the animation can be altered, as can the action to perform at the end of the animation. Actions include:
The Animatic version number is also recorded.
The image data consists of each frame to display (in the order
of their execution). No compression is used.
1.2.6 FLX
The FLX file format is a 16 bit High colour file. It is an animation file that plays animations without having to change, optimise or merge palettes. The file format is ideal for direct conversion of video into animations.
The file is derived from the AutoDesk Animator Pro FLC format, and the basic file is the same as the FLC file except for the following:
1.2.7 GIF
A GIF file consists of a screen colour map and a series of images, each with an optional colour map. The images do not have to be at the origin and can be any size smaller than the screen size. This allows GIF animations to be created that only update the part of the screen that changes. GIF files use the LZH compression algorithm.
GIF89a is a 256-colour (maximum) format. GIF allows for any number of colours between 2 and 256. The fewer colours, the less data and the smaller the graphic files. If a GIF only uses 4 colours, the palette can be reduced to only 2 bits (4 colour) and decrease the file size by upwards of 75%.
GIF animation is starting to appear on the World Wide Web (WWW), with Netscape 2.0 (and later versions), and Microsoft's Internet Explorer supporting it. It must be noted however that none of these fully support the GIF specification.
GIF89a (like GIF87a before it) allows multiple images to be compiled within a single GIF file. This "stream" of images can be used like frames in an animation sequence or movie. In addition, GIF89a allows more control over the "play" of the frames by allowing the GIF to:
With GIF89a based animation, self-contained GIF files are
downloaded once and played from the computer's disk cache. Several
may be downloaded per page, and a single animated GIF can be placed
dozens of times on the same page, creating effects that would
never be possible with server-based solutions. Unlike other movie
formats, GIF still supports transparency, even in animations.
They are as simple to use and implement as any still GIF image.
The only thing GIF lacks is sound, a feature that has been added
to GIF's in the past. A GIF animation can be slowed down or interrupted
by other images being downloaded and other playing animations.
1.2.8 IFF ANIM
The Amiga's IFF format was designed as a universal (extensible)
data format. Many different data types and chunks can be found
in IFF ANIMs. Many ANIMs include sound chunks or colour cycling.
There are a plethora of compression techniques (with different
tradeoffs) used. Most IFF ANIMs are meant to be double-buffered,
with deltas applying to frames two distant. A looping ANIM means
the last two deltas produce images that are the same as the first
two.
1.2.9 MovieSetter
This is the format used by GoldDisk on the Amiga. It is a very
flexible animation format. Animations are stored as a bunch of
backgrounds, sounds and sets. Sets are smaller images that get
placed on top of the background (with transparent pixels). A
frame list at the end describes each frame. Each frame specifies
which background to use (backgrounds can also scroll in different
directions and speeds), and a list of sets to put on that background
with depth information so characters can pass behind or in front
of each other. Sound information is contained here as well to
synchronise it with the action. There is also colour cycling
and specialty fades and wipes. The format can come as one file
or as three directories and a control file.
1.2.10 NEOchrome
Animation
This is an Atari ST animated graphics format that displays a sequence
of NEO files. Files of the animation format have an ANI suffix.
Colour animation is supported, and the speed and direction can
be modified. The number of frames is stored, as is the speed
to run the animation, and the palette to use for each frame.
The image data contains all the NEO frames concatenated together.
The animation is not compressed.
1.2.11 PFX
PageFlipper Plus F/X on the Amiga is the creator of these files.
PFX contains a series of deltas with a play list at the end.
The format supports colour map changes, nested loops and dynamic
timing.
1.2.12 QuickTime
This format is commonly used on Macintosh computers and is expanding to other platforms. QuickTime is not only a video or animation file format, but is more of a multimedia format. QuickTime supports two Movie formats, namely the Movie format and an extended version of the PICT format.
The Movie format is used to manage different forms of dynamic data. The format consists of different tracks that begin and end at different times during a presentation. There are currently five types of tracks available however new types are possible:
QuickTime synchronises the playing of the tracks, and it ensures that all data is uncompressed on time (including audio). QuickTime's architecture was designed for the synchronisation of time-based data, which is a factor omitted by many formats.
QuickTime offers several different techniques for compressing data:
The second format, the extended version of the PICT format, allows PICT files to be compressed, and the images scanned easily.
1.2.13 VICAR
The VICAR (Video Image Communication And Retrieval) file format, was developed for the general purpose VICAR image processing software system that has been developed since 1966 to digitally process multi-dimensional imaging data. VICAR was developed primarily to process images from the Jet Propulsion Laboratory's unmanned planetary spacecraft. It is now used for a variety of other applications including biomedical image processing, cartography, earth resources, astronomy, and geological exploration.
The VICAR and VICAR2 file formats are used to store planetary image data gathered from Earth and by spacecraft, and are similar in design to the FITS and PDS formats.
A VICAR file consists of two major parts: the labels, which describe what the file is, and the image area, which contains the actual image. The labels are potentially split into two parts, one at the beginning of the file, and one at the end. Normally, only the labels at the front of the file will be present. However, if the EOL keyword in the system label (described below) is equal to 1, then the EOL labels (End Of file Labels) are present. This happens if the labels expand beyond the space allocated for them.
The VICAR file is treated as a series of fixed-length records. The image area always starts at a record boundary, so there may be unused space at the end of the label, before the actual image data starts.
A label is essentially the same as a header in other file formats. It is divided into three logical parts: System labels, Property labels, and History labels, in that order.
System labels describe the format of the image and how to access it. They are always the first labels in the file. The system labels extend from the beginning of the file until the first PROPERTY or TASK keyword, or until the end of the label (if there are no property or history labels). Any program attempting to read a VICAR file should be able to accept (and ignore) system label items it does not understand, as new system label items are added from time to time. Some system label items are mandatory, while others are optional.
Property labels describe properties of the image in the image domain. Property labels do not describe the physical layout of the image; that is handled by the system labels. They do contain other current information about the file, such as the map projection used, a lookup table, or latitude/longitude information for the image. Property labels are divided into named sets called properties. Each property is made up of zero or more label items that contain the actual property information. The name space for each property is independent, so the same label item keyword may be used in more than one property. Only one property of a given name may exist. As with system labels, if any program reading a VICAR file encounters a label it does not understand it can be skipped.
History labels describe the processing history of the image. Each processing step has an entry (called a task) in the history label. Each task can optionally have label items further describing the task (such as parameters to the program). History labels do not describe the physical layout of the image; that is handled by the system labels. They should contain only historical information; however, they often contain current state information that should be in a property label, since property labels are new and not yet well utilised.
History labels are divided into sets called tasks. Each task
is made up of three mandatory label items, and zero or more label
items that contain additional history information. The name space
for each task is independent, so the same label item keyword may
be used in more than one task. Each task has a task name associated
with it, which is the name of the program that created that part
of the history label. However, the task names are not unique.
Several tasks may have the same name. Each occurrence of the
task name is called an instance, so the task name and the instance
combine to uniquely identify the task set.