Short:        GIF 24 Bit (truecolor) extensions
Author:       info@ar-kleinert.de
Uploader:     info ar-kleinert de
Type:         docs/misc
Version:      1.0
Architecture: generic

 The GIF fileformat does not support 24 bit truecolor
 RGB data - however with a trick it is possible to
 describe more than 256 colors within the same file,
 using a "tiled" approach.

 Using a second trick it can be achieved to store
 real "truecolor" information within such a file.

 The efficieny and compression is lousy and this
 approach is entirely disrecommended.

 However, such images can be found on the web
 and in fact Wikipedia contains a link to such
 a demo site.

 The aim of this readme is to document the
 writing strategy which SView5-Library uses
 when writing such "truecolor" GIF files.


 Writing Strategy:

 1.  The image is split into tiles of 16x16 pixels,
     each of which becomes a GIF image block,
     while the GIF screen width/height remains that
     of the original image (e.g. 640x480 or 240x240).

 2.  If the width/height is not an even multiple of
     16, the last tile in each row and all tiles
     in the last row will have a different width
     respectively height, e.g.

         240x240 -> 15x15 tiles of 16x16
         248x245 -> (15+1)x(15+1) tiles,
                    +1 horizontal: 8x16
                    +1 vertical:   16x5

 3.  Each 16x16 tile gets its own colormap.

 4.  The colormap depth is 8 (256 entries).

 5.  Now for each of the 16x16 = 256 pixels
     there is exactly one colormap entry.

 6.  The 256 tile pixels are stored as linear
     buffer in memory.

 7.  The colormap entries are filled exactly
     in the same order as the linear tile
     buffer in memory, i.e.


        UBYTE colors[256][3];
        UBYTE rgb_tile[768];
        UBYTE tile[256];

        // pixel is x=5, y=6
        x   = 5; y = 6;
        idx = y*16 + x;

        colors[idx][0] = rgb_tile[idx*3+0];
        colors[idx][1] = rgb_tile[idx*3+1];
        colors[idx][2] = rgb_tile[idx*3+2];

        tile[idx] = idx;

 8.  This means, each pixel in the 16x16 tile
     is mapped exactly 1:1 to a colormap
     entry - within a GIF image block there
     always are as many colormap entries
     as pixels.

 9.  For a 640x480 image this means that
     40x30 tiles (of 16x16) are stored,
     thus 1200 tiles plus 1200 colormaps
     of 768 bytes size.

 10.  The global colormap is that of the
     first tile.

 11. Any (optional) GIF89a graphic control
     extension should be written for each
     image control block or for none; if
     so, the image disposal method should
     be "1" (do not dispose) and the delay
     should be "0" (zero).

 This is the most straightforward approach.


 Possible optimizations/improvements:

  - support upto 1 transparent color per tile
  - dynamically adjust local colormap sizes
    to really required amount of different colors,
    i.e. if everyhing is black, only 6 bytes
    instead of 768 bytes
  - merge two or more local colormaps into
    the global one, if there is an overlap;
    in this case write an image block without
    local colormap (e.g. black areas)
  - if tiles have the same content and/or
    colormap, these might be merged as
    well, i.e. a square of 16x16 tiles may
    become one single 32x32
  - now this is the "lossless" approach,
    however it would also be possible to
    design some "lossy" compression mode;
    in this mode, the colormap(s) could
    be further optimized so that "similar"
    colors are merged; the effect might
    be comparable to JPEG if done right
  - in any case, the start for any further
    optimization runs should be the defined
    16x16 tile pattern

 For a proof-of-concept export module however
 such optimizations should not be vitally
 necessary.


 Final Remarks:

 Note, that this works for GIF87a and GIF89a,
 however many programs will not accept GIF87a
 files with tiles - and with GIF89a they will
 treat them as animations instead.

 Unfortunately most programs will not correctly
 treat the animation rendering information
 provided within the graphic control extension.

 As a consequence, image viewers capable of
 rendering GIF animations likely will show such
 graphics as endless animation.

 Still, such an animation would really consist
 of truecolor information.

 --
 (C)opyright 2007 by Andreas Kleinert.
 All rights reserved.