From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6d07d0186a356c56 X-Google-Attributes: gid103376,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx02.iad.newshosting.com!newshosting.com!69.16.185.16.MISMATCH!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!cyclone1.gnilink.net!spamkiller.gnilink.net!gnilink.net!nwrddc01.gnilink.net.POSTED!a5a7929f!not-for-mail Subject: Re: Representing image data Newsgroups: comp.lang.ada References: <9WAtl.2301$gm6.1634@nwrddc02.gnilink.net> <49b71100$1_6@news.bluewin.ch> From: ka@sorry.no.email (Kenneth Almquist) Message-ID: Date: Wed, 11 Mar 2009 21:12:41 GMT NNTP-Posting-Host: 96.242.119.89 X-Complaints-To: abuse@verizon.net X-Trace: nwrddc01.gnilink.net 1236805961 96.242.119.89 (Wed, 11 Mar 2009 17:12:41 EDT) NNTP-Posting-Date: Wed, 11 Mar 2009 17:12:41 EDT Xref: g2news2.google.com comp.lang.ada:5020 Date: 2009-03-11T21:12:41+00:00 List-Id: Thanks for the responses. > What sort of applications have you in mind? Ideally, any application that uses raster image data. The idea behind row-at-a-time mode is that the application will read the data in each row and store it in a format appropriate for the application. The ability to read an entire image at once is based on the assumption that the result will in a useable format for a lot of applications, but that may be more true in C, where we are concerned with binary compatibility rather than logical compatibility between types. > There are various libraries, full Ada (at least for BMP, GIF, TGA & PPM) > or bindings, which support these usual formats. I found ImageMagick, which Srini mentioned, and found two more libraries listed on www.adapower.com. Any suggestions of where else to look? With ImageMagick the only way to change the pixel format is to recompile the library, so the interface doesn't have to deal with multiple pixel formats. It uses Interfaces.C.Pointers to enable the interface to return a pointer to an array of pixels; a solution that the documentation acknowledges isn't very good. PNG-IO, which reads PNG files, has functions to access the sample values: function Pixel_Value(F : PNG_File; R, C : Coordinate) return Natural; function Red_Value(F : PNG_File; R, C : Coordinate) return Natural; function Green_Value(F : PNG_File; R, C : Coordinate) return Natural; function Blue_Value(F : PNG_File; R, C : Coordinate) return Natural; function Alpha_Value(F : PNG_File; R, C : Coordinate) return Natural; These functions are inlined, but require a fair amount of computation because their behavior depends on the attributes of the image, which have to be checked every call. Open-image has declarations for the various pixel types, which seems to be a workable approach, but I have to think about it some more. Kenneth Almquist