Provided by: libmdc2-dev_0.10.7-1build1_i386 bug


       m-gif - GIF87a and annimated GIF89a format (MedCon)


  The  Graphics Interchange Format from CompuServe allows between 1 and 8 bits
  of color information with  an  RGB  color  palette.  The  image  arrays  are
  compressed 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  */


  #define MDC_GIF_GH_SIZE 13

  typedef struct {
          Uint16 left,top,width,height;       /* image dimensions         */
          Uint8  flags;

  #define MDC_GIF_IBLK_SIZE  9

  typedef struct {                           /* display information      */
          Uint8 blocksize;
          Uint8 flags;
          Uint16 delay;
          Uint8 transparent_colour;
          Uint8 terminator;

  #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;

  #define MDC_GIF_TBLK_SIZE 13

  typedef struct {                           /* application block        */
          Uint8 blocksize;
          char applstring[8];
          char authentication[3];

  #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.

              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
              sequential 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
              character 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

  The  next  data  after  this  structure  is  the text itself, stored in data
  subblocks just like the comment block is.

  The CONTROLBLOCK extension

  A GIF  file  with  more  then  one  picture  also  contains  a  CONTROLBLOCK
  extension. The byte 0xf9 after the block separator, represents this graphics
  control block. Following this byte is the data structure.

              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

              This fields represents the color index of the transparant color.

              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.

              This contains the value 0x0b.

              An 8-byte string that specifies the creator software.

              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
         3. endblock of 0 bytes: 0x00


       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


  /usr/local/xmedcon/source/m-gif.h     The header file.
  /usr/local/xmedcon/source/m-gif.c     The source file.


  medcon(1), xmedcon(1), xmedcon-config(1)

  m-acr(4), m-anlz(4), m-inw(4), m-intf(4), m-ecat(4)



  (X)MedCon project was originally written by Erik Nolf (eNlf) for the  former
  PET-Centre at Ghent University (Belgium).

  e-mail:   www: