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

Reply via email to