From: Gautier write-only on
On May 3, 1:01 am, tmo...(a)acm.org wrote:

> Generic handling at the pixel level will surely be slower than direct
> coding that knows what it's operating on, and that will be an issue
> if there's any significant pixel level processing.
Not necessarily if the generics are properly inlined (perhaps you are
thinking of shared generics).
The range of primary colors is now a generic parameter too. So there
will be tests like "if Color_Range'Last=255 then..." which will be
resolved at compile-time by smart compilers.

[...]
> But is your package aimed more at processing images, or at doing IO on
> the myriad file formats of images?
Only decoding images of various formats, that's all!
> And how about video?
This is not excluded. Probably I'll add an out parameter,
time_of_next_frame, to the Load_image_contents procedure.
_________________________________________________________
Gautier's Ada programming -- http://sf.net/users/gdemont/
NB: For a direct answer, e-mail address on the following web site:
http://www.fechtenafz.ethz.ch/wm_email.htm
From: Gautier write-only on
Thanks for the feedback.
The project is really restricted to decoding images of the broadest
spectrum of formats and do whatever the user wants to do with the
pixels: store into a buffer (and process, save, or save that buffer),
or display them directly in a GUI object, or whatever else...
The current state so far is:
* BMP is done, except RLE compression and some unusual bit depths
* GIF is complete (including animated pictures)
* PNG is covering all but transparent formats; there is a nasty glitch
with the decompression, so it works on some pictures and on some,
not...
up to now I was able to have a common source for all formats;
sure, I should have a closer look to PNG_IO...
* TGA is on a good way to be complete

You can have a look via a svn checkout:
svn co https://gen-img-dec.svn.sf.net/svnroot/gen-img-dec gid
and with gnatmake -P gid.gpr
It builds ./test/to_bmp on your platform.
Note: there is a "Fast" mode in the gid.gpr project file!
Gautier


On May 24, 10:51 pm, Stephen Sangwine <s...(a)essex.ac.uk> wrote:

> Interesting idea. What you are proposing looks to me like a sort
> of binding to various image libraries, in that you provide basic
> image reading/writing to a variety of formats. Of course, you
> can't handle all the special features of each image format, but
> for an application that just needs to read or write the pixels
> and a few other basics like palettes, alpha etc, the approach
> would be useful. I can speak from experience of developing PNG_IO
> to say that handling any non-trivial format is not a small task.
> BMP is pretty easy - TIFF is probably the hardest to handle. In
> both PNG and TIFF the pixel data is stored in disparate pieces
> within the file - not as a single block of pixel data. In the
> case of PNG the compression runs across these blocks, not within
> each block. What this means is that code for handling the pixel
> data can't easily be common to different types of image file.
>
> You have available an Ada package for PNG already in PNG_IO.
> I've thought about GIF as a student project now that the
> compression is no longer subject to patent protection, but no
> work has been done on it yet.
>
> Steve Sangwine