Hi,
as Michael has said, there is now (almost) full support for bmps in fcl
(it's missing PNG and JPEG images inside bmps: this is a feature available
in win98+ that let you have a jpeg or png with a bmp header. I think it's
not something very useful, but if someone wants it's easy to add support for
these using jpeg and png readers inside bmp reader).
I admit I haven't used lazarus a lot... When I started to make some work in
fcl/image I thought that lazarus relied on fpimages to handle images, but
when I peeked a little into lazarus sources I noticed something "strange".
While there is a "Images for lazarus" package that relies on fpimage (but
readme file says it must not be used because of bugs in jpeg implementation
in fpimages... what are these bugs?), I saw that in intfgraphics there are
things like "TLazBMPreader" that isn't a descendant of TFPBMPReader.
TLazBMPreader has been copy-pasted from tfpbmpreader and has been modified
(to solve endianess issues and to support 15 and 16 bit bitmaps). Why don't
modify tfpbmpreader if there were problems, instead of copying it and
modifying this copy?
Now bmp support in fcl is very complete, both in reading and writing. If you
want you can use that instead of "reinvent the wheel" in intfgraphics. Maybe
there were other reasons that led to this choice (as I said, I know very
little about lazarus).
Another thing: png endianess issues in fpimage have been solved, so now it's
usable even on big endian machines.
Actually bmp writer raises an exception if you want to save with a color
depth that requires a palette and there isn't palette or it's too big (that
is, if you want to save in 8bpp and image has a palette greater than 256
elements an exception is raised)
In the future you'll see new classes (in fcl/image) related to the reduction
of color depth. These classes implement some widely used algorithms (octree,
median cut, with optional floyd-steinberg dithering) that can be used to
convert images to lower color depths, generate palettes and so on, so maybe
that writers will perform a conversion to the desired color depth (with the
fastest algorithm) instead of raising an exception if there are too many
colors. When Michael completes its work on them we'll write details on the
list.
Bye,
Giulio
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives