M-GIF(4)M-GIF(4)NAMEm-gif - GIF87a and annimated GIF89a format (MedCon)
DESCRIPTION
The Graphics Interchange Format from CompuServe allows between 1 and 8 bits
of color information with an RGB color palette. The image arrays are com‐
pressed with an LZW coding. The extension of the file is `.gif'.
The basic defines for the format:
---------------------------------------------------------------------------
typedef struct {
char sig[6]; /* GIF87a or GIF89a */
Uint16 screenwidth,screenheight; /* screen dimensions */
Uint8 flags,background,aspect; /* background color, ratio */
} MDC_GIFHEADER;
#define MDC_GIF_GH_SIZE 13
typedef struct {
Uint16 left,top,width,height; /* image dimensions */
Uint8 flags;
} MDC_GIFIMAGEBLOCK;
#define MDC_GIF_IBLK_SIZE 9
typedef struct { /* display information */
Uint8 blocksize;
Uint8 flags;
Uint16 delay;
Uint8 transparent_colour;
Uint8 terminator;
} MDC_GIFCONTROLBLOCK;
#define MDC_GIF_CBLK_SIZE 6
typedef struct { /* plain text block */
Uint8 blocksize;
Uint16 left,top;
Uint16 gridwidth,gridheight;
Uint8 cellwidth,cellheight;
Uint8 forecolour,backcolour;
} MDC_GIFPLAINTEXT;
#define MDC_GIF_TBLK_SIZE 13
typedef struct { /* application block */
Uint8 blocksize;
char applstring[8];
char authentication[3];
} MDC_GIFAPPLICATION;
#define MDC_GIF_ABLK_SIZE 12
---------------------------------------------------------------------------
What does the format support or not support:
===========================================================================
Item Supported Not Supported
===========================================================================
Color Map : max 256 RGB colors -
File Endian : little big
Pixeltypes : Uint8 -
===========================================================================
Scaling factors : quantify & calibrate factors/image are NOT supported
---------------------------------------------------------------------------
Dimensions/Image : different dimensions for each image are supported
---------------------------------------------------------------------------
Pixeltypes/Image : different pixeltypes for each image are NOT supported
===========================================================================
Because of the flexible nature of the GIF format it could be possible to
include scaling factors per image with the GIF extension blocks, but more
about this later. The image is stored from left to right and from top to
bottom, unless the images are interlaced.
First some explanation on the GIF format and its different structures.
=======================
The GIFHEADER structure
=======================
This data structure is the very first information in a GIF file:
sig[6] Holds the signature of the file "GIF87a" or "GIF89a".
screenwidth, screenheight
The required screen dimensions in pixels to display the images.
background
This represents the background color. It is in fact an index
entry in the color palette.
aspect The aspect ratio of the pixels in the image. If this field is
not 0 the aspect ratio is: ((gh.aspect + 15) / 64). This entry
is always 0 for the GIF87a format.
flags This fields contains a number of bits of information.
if (gh.flags & 0x0080) is true, a global color map will follow.
The number of color bits: ((gh.flags & 0x0007) + 1)
The number of colors : (1 << ((gh.flags & 0x0007) + 1)
if (gh.flags > 0x0008) is true, the color palette is sorted with
the most important colors first. This bit is low in GIF87a.
Finally (1 << ((gh.flags >> 4) + 1) represents the number of
color bits in the original image. This bit is low in GIF87a.
After reading the GIFHEADER and any global colormap, there should be a
`block separator' which introduce the following block of GIF information.
There are three kind of `block separators' : a comma, an exclamation mark
and a semicolon.
',' => the next block will be an image
'!' => the next block will be an extension
';' => the end of the GIF file
The image block after a comma consists of the IMAGEBLOCK structure and the
compressed image. The IMAGEBLOCK structure defines the nature of the image
and supersedes the global definitions.
========================
The IMAGEBLOCK extension
========================
left, top
The upper left coordinate of the image relative to the screen.
width, height
The image dimensions. Width is the number of pixels in a line.
Depth represents the number of rows.
flags This field is similar to the global flags in the GIFHEADER
structure. Number of colors in the image is ((iblk.flags &
0x0007) + 1).
If (iblk.flags & 0x0040) is true, the image is interlaced. In
this case the image is split into four passes instead of sequen‐
tial lines:
1st pass: lines 0 8 16 24 ... (+8)
2nd pass: lines 4 12 20 28 ... (+8)
3rd pass: lines 2 6 10 14 ... (+4)
4th pass: lines 1 3 5 7 ... (+2)
If (iblk.flags & 0x0080) is true, there is a local color map.
If (iblk.flags & 0x0020) is true, the color map is sorted.
The next byte, after the IMAGEBLOCK should be the initial image code size
The compressed image consists of subblocks of code, of which the first byte
gives the amount of code bytes that follow. The last block is a zero-length
block. This is how you could skip an image:
FILE *fp;
int i,n;
do {
n = fgetc(fp); /* get code size */
if (n != EOF) {
for (i=0; i<n; i++) fgetc(fp); /* skip the block */
}
}while( (n != 0) && (n != EOF)) /* read the next block, if any */
After reading this hole image block, the next byte should be again a `block
separator'. If this separator is an exclamation mark, the following block
is an extension. The GIF extension blocks allow additional features.
=====================
The COMMENT extension
=====================
This is a very simple extension. The byte 0xfe after a block separator,
introduces a comment block. It contains text that does not make part of the
image. The comment block is stored as subblocks, ending with a zero-length
subblock (or endblock).
=======================
The PLAINTEXT extension
=======================
This is identified by the byte 0x01 after the block separator. The data
structure follows this byte.
left, top
The items give the starting position of the displayed text.
gridwidth, gridheight
Two elements that specify the distance in pixels from one char‐
acter to the next.
cellwidth, cellheight
These fields represent the actual dimensions in pixels of the
characters to be displayed.
forecolor, backcolor
Color map indices for the foreground and background respec‐
tively.
The next data after this structure is the text itself, stored in data sub‐
blocks just like the comment block is.
==========================
The CONTROLBLOCK extension
==========================
A GIF file with more then one picture also contains a CONTROLBLOCK exten‐
sion. The byte 0xf9 after the block separator, represents this graphics con‐
trol block. Following this byte is the data structure.
blocksize
This field always contains the value 0x04.
flags if (cb.flags & 0x01) is true, cb.transparent_color will contain
a valid transparent color index.
if (cb.flags & 0x02) is true, the viewing program should wait
for user input before displaying the next image. if (cb.delay)
is greater than zero, the viewer should at least wait for the
number of seconds specified in the delay data field.
The value ((cb.flags >> 2) & 0x0007) tells the method to remove
the present image from the screen:
0 = do nothing
1 = leave it
2 = restore with the background color
3 = restore with the previous graphic
delay The delay in 1/100ths of a second to dispose the present
graphic.
transparant_color
This fields represents the color index of the transparant color.
terminator
Any clues on this?
=========================
The APPLICATION extension
=========================
The final extension is the APPLICATION block. The application data structure
is identified by the byte 0xff just after the block separator.
blocksize
This contains the value 0x0b.
applstring
An 8-byte string that specifies the creator software.
authentication
This field should contain 3 bytes based on the applstring field
to check the integrity of the applstring field.
The APPLICATION block extension can be followed by subblocks, ending with a
zero-length subblock.
A special kind of APPLICATION block extension is the LOOPBLOCK extension
used for annimated GIF files in concern to Netscape Navigator. This block
comes between the GIFHEADER and IMAGEBLOCK data structures. It contains the
following items:
1. An application block
ap.blocksize = 0x0b;
ap.applstring = "NETSCAPE";
ap.authentication = "2.0";
2. subblock of 3 bytes: 0x03
0x01,0xe8,0x03
3. endblock of 0 bytes: 0x00
NOTES
For complete information on the GIF format, we liked reading this book:
``Supercharged Bitmapped Graphics''
written by Steve Rimmer
published by Windcrest/McGraw-Hill
ISBN: 0-8306-3788-5
FILES
/usr/local/xmedcon/source/m-gif.h The header file.
/usr/local/xmedcon/source/m-gif.c The source file.
SEE ALSOmedcon(1), xmedcon(1), xmedcon-config(1)m-acr(4), m-anlz(4), m-inw(4), m-intf(4), m-ecat(4)medcon(3)AUTHOR
(X)MedCon project was originally written by Erik Nolf (eNlf) for the former
PET-Centre at Ghent University (Belgium).
e-mail: enlf-at-users.sourceforge.net www: http://xmedcon.sourceforge.net
M-GIF(4)
