Provided by: libmdc-dev_0.22.0-gtk3+dfsg-1_amd64 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

       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

       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

       forecolor, backcolor
              Color map indices for the foreground and background respectively.

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

              This fields represents the color index of the transparent 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

  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: