From: Gautier write-only on 3 May 2010 08:18
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:
From: Gautier write-only on 24 May 2010 17:42
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,
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!
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