The GIF file format has a bit of history when it comes to patents. The fount of all knowledge, Wikipedia, suggests that a ton of brick shaped lawyers is not going to descend from on high for posting this page. Let's hope not anyway, it's a new world after all!
This library does not seem to have the weight behind it that say LibPNG or ZLib has, and for obvious reasons. PNG is in real terms a better format. Nevertheless, it's not right to ignore the many people who use, nay need to use, GIF. Especial thanks must go to those who wrote this library because, I suppose, someone had to. We include the delightfully small and neat source code here for this library, mainly because it doesn't seem to have an explicit, well publicised home.
Lets be clear here, it isn't ours, we don't know how it works, we accept no responsibility for it.
As usual there were some changes made on our part, although the posted header and source files are those that we found under a particularly attractive, and seemingly enchanted, rock. The changes we made were purely for the purpose of specifying our own memory manager. In this respect LibGIF seemed quite well versed. It seemed to expect that a file called App.h, would provide references to allocation routines. Such a file was not provided, but nor was the file License.txt. The latter missing dependency gave us more trouble than the former.
In practice we simply provided functions in the LibGIF source file that mapped our memory manager to the function calls in the LibGIF source file. The functions were purely local so the only prototypes are given below;
void* app_alloc(unsigned long Size);
void* app_realloc(void* pMem,unsigned long Size);
void app_free(void* pMem);
void* app_zero_alloc(unsigned long Size);
void app_memcpy(void* pDst,void* pSrc,unsigned long Size);
As all this comes together, we have a similar interface to all the others we provided to link the overall file Image.dll with our own C++ class wrappers;
Our overall implementation takes a buffer, a buffer size and an ImgGIFInfo struct. The buffer and size are modified, reallocated and translated into the new format. This works in both directions i.e. both to and from GIF. The "other" format is nominally windows bitmap. For details of the use of the ImgGIFInfo struct see LibPNG. In general this implementation is the same but there is slightly less complexity. In particular the TrnsIndex and Trns flag only indicate possible transparency for a single palette index.
The GIF format is quite constrained, because it only supports paletted images up to 256 colours. Clearly it is not possible to submit a 24bit colour windows bitmap for conversion. Nothing will prevent the attempt, but results are undefined in such a case.