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: http://www.fechtenafz.ethz.ch/wm_email.htm
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, 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
First
|
Prev
|
Pages: 1 2 3 Prev: Language Revision : "/" and "div" Next: gnat-ajis-2009 jvm2ada missing packages? |