> > The purpose of the file-target is to transparently render a LibGGI
> > application's output to a file.
> And the application's output can be _anything_. And "anything" means, that
> this could be also a screenshot for example, which is usually saved as
> *.pcx, *.ppm or something like that.
That is the idea, and that is already possible with the file target. Have a
look at doc/targets.txt . The target itself will only write the simple raw
and ppm formats and has hooks to externally convert them.
> > Making it _read_ files does not gain you anything over any other
> > approach, and is plain wrong.
> No. You can easily write a ggiviewer for example (have a look at the
> attachment).
Yes. But thinking closely, Marcus is pretty much right.
I have for now only argued with respect to bloating the file target.
While IMHO a p?m loader wouldn't add much bloat, Marcus is right with the
"we need a good image loading library anyway" argument.
LibGGI programs keep reinventing this over and over, and I have done so
myself as well several times for loading P?M, GIF and JPG.
As Marcus said, it would be a good idea to have a generic lib not tied to
LibGGI or whatever in any way, that can just load images.
Anyone can use it, then. I myself would be one of the first customers, as
I do image processing at the university and have both LibGGI-using and
commandline-only programs that have to load/save images.
Separating the image-loader from LibGGI would be good there ... (right now I
use a memvisual-only mode for that, but actually that's a bit of overkill).
It would be good, though, not to repeat the old error of tons of other libs
to first load the image into some in-memory structure and then go on.
While this is o.k. for say an icon or a background image of a few MB, it
hits your swap very badly once you go to high resolution scans for DTP
purposes etc.
I have been hit by that bad practice lots of times when scanning and
postprocessing the stuff. Even simple conversions filled up my RAM and swap
without any need.
For my image-processing stuff, it's even worse: We often work with tomography
data what means 512x512x256 pixels at 16 bit/pixel ... 128MB of raw data ...
Newer systemswill produce even better resolution ...
IMHO we should, while we are at it, implement a lib that does the storage
part (or the reading part, if we also implement saving images) by using a
user-provided callback.
That will allow us to directly load into memory visuals or similar and
others to push it into memory or whatever.
This callback is also a nice hooking point, where you can layer it with a
colorspace conversion utility. Jpegs already contain yuv-data ... why waste
time on converting that to rgb and then back to yuv to display it on a video
out card.
So the lib should just announce the format it will have in its
callback-buffers and leave it to a higher level to do conversions.
I have read someone here has some image loading lib already.
Could you make a preview available ? We should probably adopt it into our
development tree to be able to improve it together.
With such a lib below, it should be pretty trivial to implement image
loading in any LibGGI application.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
