Here is the 2nd patch (is attached) I produced.
* use the file-stream from libc now
* some more cleanups
* added ppm read support
* added bmp (both OS/2 and Windows-format) read and write support
The patch compiles for me, but be beware:
I have nothing tested yet, so there might be some bugs.
I have some comments too:
Adam Scislowicz([EMAIL PROTECTED]) wrote:
> It is more fficient to use libpng, libjpeg, libtiff, etc. Then it would
> be to pipe through conversion programs. As a last ditch effort a call to
> convert could be used(as in imlib), but normally a dlopen of a
> image-loader lib(again, as in imlib) is very efficient. I have a small
> program that dlopens libpng and displays a png image using GGI, but I
> did not implement it as the file-target :(
Send me the source, and I will do it.
Originally I planned to use the libtiff, libjpeg and libpng -libs to
support these file-formats.
Andreas Beck ([EMAIL PROTECTED]) [000203 13:09] wrote:
> The idea of the ppmtools is to finally put an end to reinventing the
> picture loading and saving wheel for every program/lib/whatever.
> As long as you can load/save ppms (which is trivial) you can load/save
> any format by just piping the output through the appropriate ppmtools.
Uhm, I assumed at the beginning, that the RAW-file-format, which is
already implemented by Andrew, is designed for every
So I thought: OK - implement some read and writing stuff for generel
purposes, and hack support for some file-formats in...
E-Mail: [EMAIL PROTECTED]
P.S.: I don't forget to add the patch as attachment. I have yesterday sent
this mail to the ML with the attachment, but it seems that mails with
attachments even in text only, umcompressed are refused by the ML-server.
So, if you want to have a look at it, feel free to mail me.