[Lazarus] fpimage use of Lazarus

[Marco van de Voort]

On Sat, Feb 16, 2008 at 09:41:34PM +0100, Mattias Gaertner wrote:
> > 
> > Those are all to interpret pixel data (depending on what you mean by
> > depth). Not to extract or allocate storage.
> 
> Does this mean every function that uses scanline must support all
> these things?

Yes, of course. But it is already the same now for the pixel format. But
keep in mind that readers can decrease the number of formats by converting
lesser used ones to more typical ones.

Note that a similar scheme as what I suggest for the storage requirements
can be applied to pixel encoding too, in e.g. a TFPCustomImage descendant.
The reader says "I have found CMY pixels" and the image says "I only support
RGB" so the reader has to convert. And the image can be called TRGBImage.

> OR it allocates an image in a 32bit format and later the whole image is
> converted to the needed format.

That is possible. In that case the img always returns "32" if the reader
says he found "16". That's the reason the supports(bpp,bytesperline) has var
parameters. It is more or less the reader saying what it finds in the file,
and the image saying what storage form matches, without only forcing one
size fits all.

Keep in mind that while 32-bit pixels have been a realistic max for a long
time, but it won't last forever, and afaik the first 10 en 12 bits per color
displays are starting to appear (but still very expensive). It is only a
matter of time before OSes start to support it.