* A generic image decoder - specification design @ 2010-05-01 17:03 Gautier write-only 2010-05-01 20:30 ` Gautier write-only ` (3 more replies) 0 siblings, 4 replies; 16+ messages in thread From: Gautier write-only @ 2010-05-01 17:03 UTC (permalink / raw) Hello, I've just started a generic image decoder package project. You can read the specification here: http://gen-img-dec.svn.sourceforge.net/viewvc/gen-img-dec/gid.ads?revision=1&view=markup Before going on with the implementation, I would be glad to get any comment on it. From typos, naming, to possible performance considerations related to generics, or image formats, or what else ?... TIA ______________________________________________________________ Gautier's Ada programming -- http://gautiersblog.blogspot.com/ NB: For a direct answer, e-mail address on the following web site: http://www.fechtenafz.ethz.ch/wm_email.htm ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-01 17:03 A generic image decoder - specification design Gautier write-only @ 2010-05-01 20:30 ` Gautier write-only 2010-05-02 9:19 ` Andre 2010-05-02 11:45 ` brian ` (2 subsequent siblings) 3 siblings, 1 reply; 16+ messages in thread From: Gautier write-only @ 2010-05-01 20:30 UTC (permalink / raw) Here is already a tiny update: http://gen-img-dec.svn.sf.net/viewvc/gen-img-dec/gid.ads?view=markup&pathrev=2 I've discovered the possibility of an Inline pragma to a procedure listed in a generic formal part. At least GNAT and ObjectAda don't protest on that, so probably it makes some sense... G. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-01 20:30 ` Gautier write-only @ 2010-05-02 9:19 ` Andre 2010-05-02 10:48 ` RasikaSrinivasan@gmail.com 2010-05-02 15:09 ` Gautier write-only 0 siblings, 2 replies; 16+ messages in thread From: Andre @ 2010-05-02 9:19 UTC (permalink / raw) Gautier, The first question which comes up in mind is: where do you want to use it for? Is it an initial step for your Ada based browser? The 2nd question is more basic, are you write the load image functions in Ada or use bindings to existing libraries (like the JPEG one)? Basically all pixel based images are a block of memory. The one which are 8 bit based use normally a Palette (like GIF and 8-bit BMP). The full color versions (JPEG, 24-bit BMP) use 3 or 4 byte per pixel (4th one is in general the alpha channel) in a memory map. So that can easily be modeled. If it is for a browser, you can forget about the 1-, 2- and 4-bit images. So how will be your real image data be modeled? Do you plan to just use a 24-bit with alpha channel format and convert lower grade images (like GIF) into this format? Or do you want to represent the different image types also in you data model? just some feedback, Andr� On 5/1/2010 22:30, Gautier write-only wrote: > Here is already a tiny update: > > http://gen-img-dec.svn.sf.net/viewvc/gen-img-dec/gid.ads?view=markup&pathrev=2 > > I've discovered the possibility of an Inline pragma to a procedure > listed in a generic formal part. At least GNAT and ObjectAda don't > protest on that, so probably it makes some sense... > > G. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-02 9:19 ` Andre @ 2010-05-02 10:48 ` RasikaSrinivasan@gmail.com 2010-05-02 15:09 ` Gautier write-only 1 sibling, 0 replies; 16+ messages in thread From: RasikaSrinivasan@gmail.com @ 2010-05-02 10:48 UTC (permalink / raw) On May 2, 5:19 am, Andre <avsa...@hotmail.com> wrote: > Gautier, > > The first question which comes up in mind is: where do you want to use > it for? > Is it an initial step for your Ada based browser? > > The 2nd question is more basic, are you write the load image functions > in Ada or use bindings to existing libraries (like the JPEG one)? > > Basically all pixel based images are a block of memory. The one which > are 8 bit based use normally a Palette (like GIF and 8-bit BMP). The > full color versions (JPEG, 24-bit BMP) use 3 or 4 byte per pixel (4th > one is in general the alpha channel) in a memory map. So that can easily > be modeled. > If it is for a browser, you can forget about the 1-, 2- and 4-bit images. > > So how will be your real image data be modeled? > Do you plan to just use a 24-bit with alpha channel format and convert > lower grade images (like GIF) into this format? > Or do you want to represent the different image types also in you data > model? > > just some feedback, > André > > On 5/1/2010 22:30, Gautier write-only wrote: > > > Here is already a tiny update: > > >http://gen-img-dec.svn.sf.net/viewvc/gen-img-dec/gid.ads?view=markup&... > > > I've discovered the possibility of an Inline pragma to a procedure > > listed in a generic formal part. At least GNAT and ObjectAda don't > > protest on that, so probably it makes some sense... > > > G. > > If it helps plan, I have an almost complete thin OpenCV binding at projectlets.sourceforge.net IMHO if the intent is to support Image Processing algorithms, then OpenCV or itk would be the libraries to model after and possibly support to leverage. Cheers, srini ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-02 9:19 ` Andre 2010-05-02 10:48 ` RasikaSrinivasan@gmail.com @ 2010-05-02 15:09 ` Gautier write-only 2010-05-02 15:21 ` Dmitry A. Kazakov 1 sibling, 1 reply; 16+ messages in thread From: Gautier write-only @ 2010-05-02 15:09 UTC (permalink / raw) On May 2, 11:19 am, Andre <avsa...@hotmail.com> wrote: > The first question which comes up in mind is: where do you want to use > it for? > Is it an initial step for your Ada based browser? Many things, from image manipulation without display, loading of textures for GL (there it would replace the "input" part of the GL.IO provided with GLOBE_3D), display into a rectangle of a GUI system and an in-memory cache (good guess: for a browser :-) ),... > The 2nd question is more basic, are you write the load image functions > in Ada or use bindings to existing libraries (like the JPEG one)? The whole would be in Ada. The code already exists for GIF, BMP, TGA, in different places. The decompression for PNG can be taken from UnZip.Decompress. JPEG is a bit trickier. There are "Pascal" sources that could be used, perhaps. > Basically all pixel based images are a block of memory. The one which > are 8 bit based use normally a Palette (like GIF and 8-bit BMP). The > full color versions (JPEG, 24-bit BMP) use 3 or 4 byte per pixel (4th > one is in general the alpha channel) in a memory map. So that can easily > be modeled. > If it is for a browser, you can forget about the 1-, 2- and 4-bit images. > > So how will be your real image data be modeled? > Do you plan to just use a 24-bit with alpha channel format and convert > lower grade images (like GIF) into this format? > Or do you want to represent the different image types also in you data > model? The color model is 24-bit. Palettes will be decoded. The transparent pixels in GIF will have alpha=Opacity_range'First and the others will have Opacity_range'Last. All the rest (basically, the choice of the memory model, and what to do with transparency) is left to the user. For instance GL.IO will keep its model: a data buffer, which is sent to GL via Insert_into_GL. But decoded pixels might be even directly sent to a "screen" or a GUI object if it makes sense (e.g when decoding an interlaced PNG to a visible image on a Web page), without any Ada storage of the image. > just some feedback, > André Thanks for it! Gautier ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-02 15:09 ` Gautier write-only @ 2010-05-02 15:21 ` Dmitry A. Kazakov 2010-05-02 19:21 ` Gautier write-only 0 siblings, 1 reply; 16+ messages in thread From: Dmitry A. Kazakov @ 2010-05-02 15:21 UTC (permalink / raw) On Sun, 2 May 2010 08:09:35 -0700 (PDT), Gautier write-only wrote: > On May 2, 11:19�am, Andre <avsa...@hotmail.com> wrote: > >> The first question which comes up in mind is: where do you want to use >> it for? Is it an initial step for your Ada based browser? > > Many things, from image manipulation without display, loading of > textures for GL (there it would replace the "input" part of the GL.IO > provided with GLOBE_3D), display into a rectangle of a GUI system and > an in-memory cache (good guess: for a browser :-) ),... Do you plan image processing stuff? I have somewhere half-written pyramid and region-growing segmenting in Ada. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-02 15:21 ` Dmitry A. Kazakov @ 2010-05-02 19:21 ` Gautier write-only 0 siblings, 0 replies; 16+ messages in thread From: Gautier write-only @ 2010-05-02 19:21 UTC (permalink / raw) On 2 mai, 17:21, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de> wrote: > Do you plan image processing stuff? Not yet - maybe one day... > I have somewhere half-written pyramid and region-growing segmenting in Ada. Sounds good! G. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-01 17:03 A generic image decoder - specification design Gautier write-only 2010-05-01 20:30 ` Gautier write-only @ 2010-05-02 11:45 ` brian 2010-05-02 15:15 ` Gautier write-only 2010-05-02 19:24 ` Gautier write-only 2010-05-05 21:07 ` A generic image decoder - first preview! Gautier write-only 2010-05-24 20:51 ` A generic image decoder - specification design Stephen Sangwine 3 siblings, 2 replies; 16+ messages in thread From: brian @ 2010-05-02 11:45 UTC (permalink / raw) On May 2, 1:03 am, Gautier write-only <gautier_niou...@hotmail.com> wrote: > Hello, > I've just started a generic image decoder package project. > You can read the specification here:http://gen-img-dec.svn.sourceforge.net/viewvc/gen-img-dec/gid.ads?rev... > Before going on with the implementation, I would be glad to get any > comment on it. > From typos, naming, to possible performance considerations related to > generics, or image formats, or what else ?... Have you thought about supporting the FITS (http:// fits.gsfc.nasa.gov/) format? -Brian ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-02 11:45 ` brian @ 2010-05-02 15:15 ` Gautier write-only 2010-05-02 19:24 ` Gautier write-only 1 sibling, 0 replies; 16+ messages in thread From: Gautier write-only @ 2010-05-02 15:15 UTC (permalink / raw) On May 2, 1:45 pm, brian <brian.cat...@gmail.com> wrote: > Have you thought about supporting the FITS (http://fits.gsfc.nasa.gov/) format? Until now, not, but I've of course added it to the [wish] list of formats. Thanks! Gautier ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-02 11:45 ` brian 2010-05-02 15:15 ` Gautier write-only @ 2010-05-02 19:24 ` Gautier write-only 2010-05-02 22:07 ` Brian Drummond 1 sibling, 1 reply; 16+ messages in thread From: Gautier write-only @ 2010-05-02 19:24 UTC (permalink / raw) On 2 mai, 13:45, brian <brian.cat...@gmail.com> wrote: > Have you thought about supporting the FITS (http://fits.gsfc.nasa.gov/) format? Do you know what maximum color depth there is with FITS ? I guess it might be more than 255 per fundamental color, but I got lost in the docs. Perhaps I should let this 255 boundary as a generic parameter as well. Gautier ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-02 19:24 ` Gautier write-only @ 2010-05-02 22:07 ` Brian Drummond 2010-05-02 23:01 ` tmoran 0 siblings, 1 reply; 16+ messages in thread From: Brian Drummond @ 2010-05-02 22:07 UTC (permalink / raw) On Sun, 2 May 2010 12:24:13 -0700 (PDT), Gautier write-only <gautier_niouzes@hotmail.com> wrote: >On 2 mai, 13:45, brian <brian.cat...@gmail.com> wrote: > >> Have you thought about supporting the FITS (http://fits.gsfc.nasa.gov/) format? > >Do you know what maximum color depth there is with FITS ? >I guess it might be more than 255 per fundamental color, but I got >lost in the docs. >Perhaps I should let this 255 boundary as a generic parameter as well. If it's not just for viewers, but also for photography and graphic arts, it would be well worth supporting 16-bit per channel colour depths. (Some scanners are 12-bit but that is often padded to 16 anyway.) - Brian ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-02 22:07 ` Brian Drummond @ 2010-05-02 23:01 ` tmoran 2010-05-03 12:18 ` Gautier write-only 0 siblings, 1 reply; 16+ messages in thread From: tmoran @ 2010-05-02 23:01 UTC (permalink / raw) > >I guess it might be more than 255 per fundamental color, but I got > >lost in the docs. > >Perhaps I should let this 255 boundary as a generic parameter as well. > > If it's not just for viewers, but also for photography and graphic arts, > it would be well worth supporting 16-bit per channel colour depths. 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. CLAW uses tags to distinguish images with different memory layouts, so image processing dispatches to the correct code for the image at hand. Picture : Claw.Bitmaps.Root_DIBitmap_Type'Class := Claw.Bitmaps.Root_DIBitmap_Type'Class'Input(Stream); The different images have arrays of, e.g., for RGB555_Color_Type use record Blue at 0 range 0 .. 4; Green at 0 range 5 .. 9; Red at 0 range 10 .. 14; Alpha at 0 range 15 .. 15; end record; for Triple_Color_Type use record Blue at 0 range 0 .. 7; Green at 1 range 0 .. 7; Red at 2 range 0 .. 7; end record; But is your package aimed more at processing images, or at doing IO on the myriad file formats of images? And how about video? ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-02 23:01 ` tmoran @ 2010-05-03 12:18 ` Gautier write-only 0 siblings, 0 replies; 16+ messages in thread From: Gautier write-only @ 2010-05-03 12:18 UTC (permalink / raw) On May 3, 1:01 am, tmo...@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* A generic image decoder - first preview! 2010-05-01 17:03 A generic image decoder - specification design Gautier write-only 2010-05-01 20:30 ` Gautier write-only 2010-05-02 11:45 ` brian @ 2010-05-05 21:07 ` Gautier write-only 2010-05-24 20:51 ` A generic image decoder - specification design Stephen Sangwine 3 siblings, 0 replies; 16+ messages in thread From: Gautier write-only @ 2010-05-05 21:07 UTC (permalink / raw) ...here (only via svn checkout): http://sf.net/projects/gen-img-dec/develop As a prototype, I've done the .bmp format (1/4/8 bits, uncompressed) so far. A demo/tool for GID is the To_BMP procedure. Enjoy! Gautier ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-01 17:03 A generic image decoder - specification design Gautier write-only ` (2 preceding siblings ...) 2010-05-05 21:07 ` A generic image decoder - first preview! Gautier write-only @ 2010-05-24 20:51 ` Stephen Sangwine 2010-05-24 21:42 ` Gautier write-only 3 siblings, 1 reply; 16+ messages in thread From: Stephen Sangwine @ 2010-05-24 20:51 UTC (permalink / raw) On 2010-05-01 18:03:18 +0100, Gautier write-only <gautier_niouzes@hotmail.com> said: > Hello, > I've just started a generic image decoder package project. > You can read the specification here: > http://gen-img-dec.svn.sourceforge.net/viewvc/gen-img-dec/gid.ads?revision=1&view=markup Before > > going on with the implementation, I would be glad to get any > comment on it. > From typos, naming, to possible performance considerations related to > generics, or image formats, or what else ?... > TIA > ______________________________________________________________ > Gautier's Ada programming -- http://gautiersblog.blogspot.com/ > NB: For a direct answer, e-mail address on the following web site: > http://www.fechtenafz.ethz.ch/wm_email.htm 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: A generic image decoder - specification design 2010-05-24 20:51 ` A generic image decoder - specification design Stephen Sangwine @ 2010-05-24 21:42 ` Gautier write-only 0 siblings, 0 replies; 16+ messages in thread From: Gautier write-only @ 2010-05-24 21:42 UTC (permalink / raw) 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...@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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2010-05-24 21:42 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-05-01 17:03 A generic image decoder - specification design Gautier write-only 2010-05-01 20:30 ` Gautier write-only 2010-05-02 9:19 ` Andre 2010-05-02 10:48 ` RasikaSrinivasan@gmail.com 2010-05-02 15:09 ` Gautier write-only 2010-05-02 15:21 ` Dmitry A. Kazakov 2010-05-02 19:21 ` Gautier write-only 2010-05-02 11:45 ` brian 2010-05-02 15:15 ` Gautier write-only 2010-05-02 19:24 ` Gautier write-only 2010-05-02 22:07 ` Brian Drummond 2010-05-02 23:01 ` tmoran 2010-05-03 12:18 ` Gautier write-only 2010-05-05 21:07 ` A generic image decoder - first preview! Gautier write-only 2010-05-24 20:51 ` A generic image decoder - specification design Stephen Sangwine 2010-05-24 21:42 ` Gautier write-only
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox