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.