software for generating image files from gridded arrays of data?
I need a simple way to turn an array of data values into a picture. I think I once did this with imagemagick but when I looked at the documentation yesterday almost none of the documentation was familiar, as if there has been a major redirection of the project. Can I use the imagemagick that is in Etch? How? Or is there a different package that can start with data _that_is_not_already_in_a_recognized_image_format? I remember that imagemagick had a way of treating a binary file as raw image, and allowed one to tell it the image size with command options, but I couldn't find it documented in the current version. Is my memory simply faulty? Was it some other software? I generate the data from several existing sources of gridded geographic data, e.g. USGS, NASA, USDOE. But I want, for each data set, a picture and a matching collection of numeric data, free of image formatting. Suggestions? -- Paul E Condon [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: software for generating image files from gridded arrays of data?
Paul == Paul E Condon [EMAIL PROTECTED] writes: I need a simple way to turn an array of data values into a picture. That is fairly easy with the python imaging library (http://www.pythonware.com/products/pil/). I'm sorry I don't have an example at my finger tips though. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: software for generating image files from gridded arrays of data?
Hi all, Perl+ImageMagick can still do this (use Image::Magick). Attached is a *very* dirty hack that I used to threshold an image according to my own strange criteria. It actually creates a new black white image and sets each pixel individually within that image. So that's how you can set a pixel... I'm doing it based on the data in another image but there's no reason why you couldn't do it from your own data. This, perhaps, is a useful example for you. good luck! Stuart PS in the example you can see that I've used xc: and png: to specify the file type, but I think there's also a raw: type that you might be able to use. YMMV. -- Stuart Prescott www.nanoNANOnano.net areacalc.pl Description: Perl program
Re: software for generating image files from gridded arrays of data?
On 4/18/07, Paul E Condon [EMAIL PROTECTED] wrote: I need a simple way to turn an array of data values into a picture. I think I once did this with imagemagick but when I looked at the documentation yesterday almost none of the documentation was familiar, as if there has been a major redirection of the project. Can I use the imagemagick that is in Etch? How? Or is there a different package that can start with data _that_is_not_already_in_a_recognized_image_format? The IDL language was designed for this -- from the start it supported more data types than many other matrix languages. The free implementation is gdl (gnudatalanguage), but I'm not sure about packages (I build it from the CVS repo). IDL originated a week's worth of hard riding N. of matlab around the same date. It is heavly used in niche areas of astronomy, remote sensing, and medical imaging where image processing has been done for many years. It is a very idiosyncratic language, but also very robust and economical of resources (since it dates from the days when the biggest systems around had 10G disks and 128k RAM). I remember that imagemagick had a way of treating a binary file as raw image, and allowed one to tell it the image size with command options, but I couldn't find it documented in the current version. Is my memory simply faulty? Was it some other software? gdl uses the ImageMagick library to write data to image formats. I generate the data from several existing sources of gridded geographic data, e.g. USGS, NASA, USDOE. But I want, for each data set, a picture and a matching collection of numeric data, free of image formatting. -- George N. White III [EMAIL PROTECTED] Head of St. Margarets Bay, Nova Scotia -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: BALLView: new package version
Hi, On Mon, Jan 29, 2007 at 02:07:24PM +0100, Andreas Moll wrote: again, there a new improved package version available. I saw this thread now; I tried to package BALL and BALLView for Debichem a while ago (because WOW the screenshots look great) and took another shot at it today before seeing your ITP. I got a few comments on the package (the latest one on mentors.d.n): * tetex-* got retired in Debian, texlive and texlive-latex-extra should get added as Build-Depends. However, that still didn't do it for me, it failed on fancyheadings.sty, and this doesn't appear to be in any package right now. Maybe we will have to do without fancy headings for now. * Where do you have the 1.2 tarball from? The official release seems to be 1.1.1, and development releases seems to be 1.2 pre 04.07. * You should make clear in debian/copyright which parts of the upstream tarball you removed (as I understand it, you repackaged it). * Can you convince upstream that CF_VERSION_CHECK is maybe not needed? You work around it by touching config.lic, which doesn't look very nice either (if that code wasn't written by upstream, anyway). As BALL is LGPL, I see no reason to bother the user with a Yes, I agree kind of stuff similar to Windows EULAs. * The way you not just rename upstream's debian/ to debian-upstream/, but extensively use it in debian/rules looks very dubious to me; e.g. debian-upstream/createBALLVIEWDEB looks very un-debianish to me. I really suggest you just ignore debian-upstream; I very much doubt it would pass the ftp-master checks for entering the Debian archive as well. * Priority: in debian/control should be `optional' not `extra' I think. * What about the rest of BALL? Will you package it eventually? I'd be interested in them, but haven't taken a closer look. You said in an earlier mail that there are too many configure options for it, but unless there are many conflicting ones, there's lots of precedent in Debian - we just turn on the most useful options, and if users request further options, that can be thought about as well. That's it for now, it's getting late :) Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
