[fpc-devel] GIF support and color quantization

[Giulio BERNA]

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