> > So what you should do is to use ppmtools to convert other filetypes to/from
> > ppm on the fly.
> I almost agree, let me just clarify some points. I think it should be
> completely transparent. What I think you're suggesting, and what I would
> suggest, is to have this conversion built in the file target: when opening
> something that is not a ppm, file-target tries to find the correct ppmtool
> and spanws it in the background and gets the ppm through a pipe or whatever.
> The user is never aware of the conversion.
Yes. Correct. You just give a filename and the file target will
automatically determine the filetype (I'd say first from extension, and if
that is unclear using the "file" utility or something).
> My only con to this option is that its not really efficient both in terms of
> speed (spawns process, reads file, pipe file...)
Speed is IMHO no big concern when doing a ggiOpen. Loading the dynamic libs
and stuff also has its price (and we do lots of these), so the extra
overhead in speed should not be a big problem. File-IO is usually the limit
anyway, so the extra task-switching overhead for piping stuff around should
be pretty neglegible.
> and memory (at some point two copies of the translated file have to be
> in memory, one for each pipe end
Yes. This is a very unfortunate side effect of bad coding in most ppmtools.
I have solved my jpeg-encoding problem (on-the-fly encoding of scanner data
to jpeg) on a server that was very low on RAM by using cjpeg instead of the
corresponding ppmtool for gifs or tifs, as cjpeg is clever about encoding
and only reads 8 lines at a time (which is needed due to the jpeg tile size).
> --- and that can be a *real* problem in systems with relative with low
> memory, since ppms are not really good in saving memory --- swap, swap...).
Yes. However I think this problem is a minor one for the task at hand.
If someone needs to load huge pictures and/or cares for speed, it should be
obvious that implementing the stuff on its own would be better.
As long as we have several alternatives, we can easily try them in a
best->worst order, like trying djpeg before other less clever decoders.
> Ideally, some very common types could be built in. We have libjpeg.so (I
> think we even have libtiff.so),
Yes. But both are not really small (100k and 300k), not always there and
at least for using libjpeg the double-memory-consumption still holds, except
I have overlooked some mode of operation that wasn't used in the programs I
> I'm really against is implementing a complete jpeg reader from scratch, for
Yes. Libs might be acceptable, though I'd prefer them to be detected and
used at runtime, if at all, to allow for better binary compatibility.
Everything is fine, as long as only one format is really implemented in
LibGGI to save double work and maintainer's nightmares.
= Andreas Beck | Email : <[EMAIL PROTECTED]> =