Hi all.
I saw that there is no gif support in fpc/lazarus, so I started looking at libungif.
I am not a graphic expert (truly I know very little about graphics and so on) but I wanted to try.
My idea was to port libungif headers and to write code to support gif in fpimage and in lazarus.
I converted the header (gif_lib.pas) and a simple c program that came with libungif to pascal to test the headers.
Then I started writing a fpreadgif.pas file which should be put in fcl/image dir.
Basically it works (I tested it through imgconv, which I modified adding support for TFPReaderGIF) but I need some infos.

I think that TFPReaderGIF should provide InternalRead and InternalCheck methods, and then other properties or methods that are suitable for the specific file format (eg: Interlaced property, version property, and so on) so that it can be used either in a "automatic" way if the user wants to work with fpimages either in a more "specialized" way: there could be a class (TGifImage?) that could make use of the additional properties and methods of TFPReaderGIF.
The problem is that a gif file can have multiple images stored in it: I think that TFPReaderGIF shold load the image passed via InternalRead with the first image in the file since TFPCustomImage is a still image, and then load the other images somewhere else, so that they could be available for use by other "specialized" classes.

Initially i was thinking about a
property Images : TObjectList read something
to store multiple TFPCustomImages, but the problem is that each image needs to store additional informations than the ones provided by TFPCustomImage (transparent color is relative to the single image, not to the whole file, and this is true also for interlaced property, to delay between this image and the next one in the file, comments and so on). I don't know whether subclassing TFPCustomImage for this purpose could be a good idea: I mean, we could have a
TFPGifImage = class(TFPCustomImage)
and then a Images property in TFPReaderGIF that is a list of TFPGifImages: specialized classes that deal with gif files could access them, but other classes could not use them with the features of other descendants of TFPCustomImage, but only as a TFPCustomImage.
Mh... maybe I'm a little confused... any ideas?

Then there is another problem, regarding saving gif files. Actually when TFPReaderGIF is used to load a gif in a TFPCustomImage, it loads the palette of the TFPCustomImage with the palette of the first image in the gif file (or with the global palette of the gif file if the image doesn't have one of its own).
But gif files can handle at most 256 colors, so a TFPWriterGIF class (which I still have to write) should generate a 256-color palette from the palette of the TFPCustomImage.
I've seen that it's a common problem: actually there is no support for color quantization (that is, the generation of a palette with less colors) and bitmaps can only be saved with 24 or 32 bpp and so the other image formats that support different bpp.
Now, on the net there are some free algorithms that could be used (static color table, median cut, popularity, octree and the wonderful neuquant that is also used in java).
So, why not introduce something in TFPCustomImage that could be used for color quantization?
The idea is that there is a class called TQuantizator that is the base (abstract) class to implement a quantization algorithm. TFPCustomImage could have a Quantizator property to read or set this object. So when bpp is changed, or when the image must be saved to a format that needs a specific bpp (such as gif) the quantizator is used to quantize the image.
I think that the fastest algorithm (which usually is the poorest in terms of image quality) should be used by default (that is, assigned to Quantizator property of TFPCustomImage in its constructor) if the user doesn't provide one of its own.

Cheers,
Giulio