1M-GIF(4) Kernel Interfaces Manual M-GIF(4)
2
6 m-gif - GIF87a and annimated GIF89a format (MedCon)
7
9 The Graphics Interchange Format from CompuServe allows between 1 and 8 bits
10 of color information with an RGB color palette. The image arrays are com‐
11 pressed with an LZW coding. The extension of the file is `.gif'.
12 The basic defines for the format:
14 ---------------------------------------------------------------------------
16 typedef struct {
18 char sig[6]; /* GIF87a or GIF89a */
19 Uint16 screenwidth,screenheight; /* screen dimensions */
20 Uint8 flags,background,aspect; /* background color, ratio */
21 } MDC_GIFHEADER;
23 #define MDC_GIF_GH_SIZE 13
25 typedef struct {
27 Uint16 left,top,width,height; /* image dimensions */
28 Uint8 flags;
29 } MDC_GIFIMAGEBLOCK;
30 #define MDC_GIF_IBLK_SIZE 9
32 typedef struct { /* display information */
34 Uint8 blocksize;
35 Uint8 flags;
36 Uint16 delay;
37 Uint8 transparent_colour;
38 Uint8 terminator;
39 } MDC_GIFCONTROLBLOCK;
40 #define MDC_GIF_CBLK_SIZE 6
42 typedef struct { /* plain text block */
44 Uint8 blocksize;
45 Uint16 left,top;
46 Uint16 gridwidth,gridheight;
47 Uint8 cellwidth,cellheight;
48 Uint8 forecolour,backcolour;
49 } MDC_GIFPLAINTEXT;
50 #define MDC_GIF_TBLK_SIZE 13
52 typedef struct { /* application block */
54 Uint8 blocksize;
55 char applstring[8];
56 char authentication[3];
57 } MDC_GIFAPPLICATION;
58 #define MDC_GIF_ABLK_SIZE 12
60 ---------------------------------------------------------------------------
62 What does the format support or not support:
64 ===========================================================================
66 Item Supported Not Supported
67 ===========================================================================
68 Color Map : max 256 RGB colors -
69 File Endian : little big
70 Pixeltypes : Uint8 -
71 ===========================================================================
72 Scaling factors : quantify & calibrate factors/image are NOT supported
73 ---------------------------------------------------------------------------
74 Dimensions/Image : different dimensions for each image are supported
75 ---------------------------------------------------------------------------
76 Pixeltypes/Image : different pixeltypes for each image are NOT supported
77 ===========================================================================
78 Because of the flexible nature of the GIF format it could be possible to
80 include scaling factors per image with the GIF extension blocks, but more
81 about this later. The image is stored from left to right and from top to
82 bottom, unless the images are interlaced.
83 First some explanation on the GIF format and its different structures.
85 =======================
87 The GIFHEADER structure
88 =======================
89 This data structure is the very first information in a GIF file:
91 sig[6] Holds the signature of the file "GIF87a" or "GIF89a".
93 screenwidth, screenheight
95 The required screen dimensions in pixels to display the images.
96 background
98 This represents the background color. It is in fact an index
99 entry in the color palette.
100 aspect The aspect ratio of the pixels in the image. If this field is
102 not 0 the aspect ratio is: ((gh.aspect + 15) / 64). This entry
103 is always 0 for the GIF87a format.
104 flags This fields contains a number of bits of information.
106 if (gh.flags & 0x0080) is true, a global color map will follow.
107 The number of color bits: ((gh.flags & 0x0007) + 1)
108 The number of colors : (1 << ((gh.flags & 0x0007) + 1)
109 if (gh.flags > 0x0008) is true, the color palette is sorted with
110 the most important colors first. This bit is low in GIF87a.
111 Finally (1 << ((gh.flags >> 4) + 1) represents the number of
112 color bits in the original image. This bit is low in GIF87a.
113 After reading the GIFHEADER and any global colormap, there should be a
115 `block separator' which introduce the following block of GIF information.
116 There are three kind of `block separators' : a comma, an exclamation mark
117 and a semicolon.
118 ',' => the next block will be an image
119 '!' => the next block will be an extension
120 ';' => the end of the GIF file
121 The image block after a comma consists of the IMAGEBLOCK structure and the
123 compressed image. The IMAGEBLOCK structure defines the nature of the image
124 and supersedes the global definitions.
125 ========================
127 The IMAGEBLOCK extension
128 ========================
129 left, top
131 The upper left coordinate of the image relative to the screen.
132 width, height
134 The image dimensions. Width is the number of pixels in a line.
135 Depth represents the number of rows.
136 flags This field is similar to the global flags in the GIFHEADER
138 structure. Number of colors in the image is ((iblk.flags &
139 0x0007) + 1).
140 If (iblk.flags & 0x0040) is true, the image is interlaced. In
141 this case the image is split into four passes instead of sequen‐
142 tial lines:
143 1st pass: lines 0 8 16 24 ... (+8)
144 2nd pass: lines 4 12 20 28 ... (+8)
145 3rd pass: lines 2 6 10 14 ... (+4)
146 4th pass: lines 1 3 5 7 ... (+2)
147 If (iblk.flags & 0x0080) is true, there is a local color map.
148 If (iblk.flags & 0x0020) is true, the color map is sorted.
149 The next byte, after the IMAGEBLOCK should be the initial image code size
151 The compressed image consists of subblocks of code, of which the first byte
152 gives the amount of code bytes that follow. The last block is a zero-length
153 block. This is how you could skip an image:
154 FILE *fp;
156 int i,n;
157 do {
159 n = fgetc(fp); /* get code size */
160 if (n != EOF) {
161 for (i=0; i<n; i++) fgetc(fp); /* skip the block */
162 }
163 }while( (n != 0) && (n != EOF)) /* read the next block, if any */
164 After reading this hole image block, the next byte should be again a `block
166 separator'. If this separator is an exclamation mark, the following block
167 is an extension. The GIF extension blocks allow additional features.
168 =====================
170 The COMMENT extension
171 =====================
172 This is a very simple extension. The byte 0xfe after a block separator,
174 introduces a comment block. It contains text that does not make part of the
175 image. The comment block is stored as subblocks, ending with a zero-length
176 subblock (or endblock).
177 =======================
179 The PLAINTEXT extension
180 =======================
181 This is identified by the byte 0x01 after the block separator. The data
183 structure follows this byte.
184 left, top
186 The items give the starting position of the displayed text.
187 gridwidth, gridheight
189 Two elements that specify the distance in pixels from one char‐
190 acter to the next.
191 cellwidth, cellheight
193 These fields represent the actual dimensions in pixels of the
194 characters to be displayed.
195 forecolor, backcolor
197 Color map indices for the foreground and background respec‐
198 tively.
199 The next data after this structure is the text itself, stored in data sub‐
201 blocks just like the comment block is.
202 ==========================
204 The CONTROLBLOCK extension
205 ==========================
206 A GIF file with more then one picture also contains a CONTROLBLOCK exten‐
208 sion. The byte 0xf9 after the block separator, represents this graphics con‐
209 trol block. Following this byte is the data structure.
210 blocksize
212 This field always contains the value 0x04.
213 flags if (cb.flags & 0x01) is true, cb.transparent_color will contain
215 a valid transparent color index.
216 if (cb.flags & 0x02) is true, the viewing program should wait
217 for user input before displaying the next image. if (cb.delay)
218 is greater than zero, the viewer should at least wait for the
219 number of seconds specified in the delay data field.
220 The value ((cb.flags >> 2) & 0x0007) tells the method to remove
221 the present image from the screen:
222 0 = do nothing
224 1 = leave it
225 2 = restore with the background color
226 3 = restore with the previous graphic
227 delay The delay in 1/100ths of a second to dispose the present
229 graphic.
230 transparant_color
232 This fields represents the color index of the transparant color.
233 terminator
235 Any clues on this?
236 =========================
238 The APPLICATION extension
239 =========================
240 The final extension is the APPLICATION block. The application data structure
242 is identified by the byte 0xff just after the block separator.
243 blocksize
245 This contains the value 0x0b.
246 applstring
248 An 8-byte string that specifies the creator software.
249 authentication
251 This field should contain 3 bytes based on the applstring field
252 to check the integrity of the applstring field.
253 The APPLICATION block extension can be followed by subblocks, ending with a
255 zero-length subblock.
256 A special kind of APPLICATION block extension is the LOOPBLOCK extension
258 used for annimated GIF files in concern to Netscape Navigator. This block
259 comes between the GIFHEADER and IMAGEBLOCK data structures. It contains the
260 following items:
261 1. An application block
262 ap.blocksize = 0x0b;
263 ap.applstring = "NETSCAPE";
264 ap.authentication = "2.0";
265 2. subblock of 3 bytes: 0x03
266 0x01,0xe8,0x03
267 3. endblock of 0 bytes: 0x00
268
270 For complete information on the GIF format, we liked reading this book:
271 ``Supercharged Bitmapped Graphics''
273 written by Steve Rimmer
274 published by Windcrest/McGraw-Hill
275 ISBN: 0-8306-3788-5
276
278 /usr/local/xmedcon/source/m-gif.h The header file.
279 /usr/local/xmedcon/source/m-gif.c The source file.
280
282 medcon(1), xmedcon(1), xmedcon-config(1)
283 m-acr(4), m-anlz(4), m-inw(4), m-intf(4), m-ecat(4)
285 medcon(3)
287
289 (X)MedCon project was originally written by Erik Nolf (eNlf) for the former
290 PET-Centre at Ghent University (Belgium).
291 e-mail: enlf-at-users.sourceforge.net www: http://xmedcon.sourceforge.net
293 M-GIF(4)