From da@ski.org Tue Jun 1 19:27:11 1999 From: da@ski.org (David Ascher) Date: Tue, 1 Jun 1999 11:27:11 -0700 (Pacific Daylight Time) Subject: [Image-SIG] Need 12 or 16 bits/pixel images In-Reply-To: <14161.37593.25525.75046@octopus.chem.uu.nl> Message-ID: On Sun, 30 May 1999, Rob Hooft wrote: > I have a similar application. Scaling the image to 8 bits is really > the only sensible thing to do, as the human eye cannot differentiate > much more anyway, and there are AFAIK no regular graphics cards that > can do more than 8 bit greyscale. FWIW, I can think of applications where > 8 bits matters, both in cases where perception is involved and cases where the images contain data which is to be analyzed by non-human processes (as I suspect is the case in Roger's app). If you do find you have to settle for 8-bits, depending on the case, you might find that some other compressive transform besides scaling is more appropriate (e.g. by knowing something about the noise in the imaging device, information loss might be reduced by compressing e.g. the low values more than the high values). The image won't be "veridical", but then again, neither are the CCD, the monitor and the eye. I have no answer to Roger's original question, alas. --david "vision scientist" ascher From rburnham@cri-inc.com Tue Jun 1 21:45:45 1999 From: rburnham@cri-inc.com (Roger Burnham) Date: Tue, 1 Jun 1999 12:45:45 -800 Subject: [Image-SIG] 16 bit TIFF support Message-ID: <199906011946.OAA20969@smtp2.gte.net> Thanks to all who responded to my "Need 12 or 16 bits/pixel images" query. As David Ascher said, my app is one where > 8 bits is needed for optimal analysis. This is to announce that I have added 16 bit luminance image support to Imaging- 1.0b1. I usurped the TIFF 16 bit 'L' mode (which converted 16 bit images to 8 bits), and called it mode 'W' (word length bits). It all seems to work for the Imaging functions my apps use, altho there is some tiff functionality missing from 1.0b1: e.g. writing a tiff file does not write out the tags that were read in (working on this). Going thru the diffs, this is what I've implemented for 16 bit grayscale images: TYPE_UINT16 and IMAGING_TYPE_UINT16 defines added UINT16 *image16 member to the ImagingInstance structure point operations (not tested) getpixel getink (not tested) histogram putdata (not tested) putpixel export the PyCObject (ala Numeric) for extensions to "import_imaging();" (extensions #include "ImageObject.h" instead of Image.h) in map.c and imDib.h , undef INT32 and UINT32 before including windows.h to avoid compiler error. blend operations chop operations (some tested) convert 'W' to 'L' draw operations (untested) spread effect (random pixels) (untested) disallow fill operations on 'W' images filter operations (untested) geometry ops (untested) getbbox (untested) offset (untested) added a {"W", "W", 16, packW16B} packer appropriate paste operations (some tested) quantize (untested) create new 16 bit 'W' images added {"W", "L;16B", 16, unpackW16B}, {"W", "W", 16, unpackW16B}, unpackers In TiffImagePlugin, changed OPEN entry (1, (16,)): ("L", "L;16B"), to (1, (16,)): ("W", "L;16B"), added a SAVE entry "W": ("W", 16, 1), The point of all this is that this is my first time delving into pil internals, and I'm sure I'm on shaky ground in places (particularly the nuances of packers and unpackers) and am asking if anyone who is familiar with the Imaging API would be willing to review and comment on what I've done, so that I can clean up, add, or delete functionality as appropriate before submitting the changes to Fredrick (I've gotten no responses from /F, is he the right place to submit patches?). Cheers, Roger Burnham Cambridge Research & Instrumentation rburnham@cri-inc.com http://www.cri-inc.com/ http://starship.python.net/crew/roger/ PGP Key: http://www.nai.com/default_pgp.asp PGP Fingerprint: 5372 729A 9557 5F36 177F 084A 6C64 BE27 0BC4 CF2D From fredrik@pythonware.com Wed Jun 2 09:28:11 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 2 Jun 1999 10:28:11 +0200 Subject: [Image-SIG] Saving TIFF References: Message-ID: <00bd01beacd1$dcfc09c0$f29b12c2@pythonware.com> > I have a problem when saving a TIFF Image with the PIL (version 0.3a1). > The function 'save' saves an inverted image of the displayed image (with > ImageTk.PhotoImage, mode "L"). the tiff module is known to be somewhat broken, and it's currently being overhauled for the 1.0 final release. in the meantime, you can invert the image on the way out: if im.mode == "L": # workaround for broken TIFF writer im.point(lambda i: 255-i).save("out.tif") else: im.save("out.tif") From fredrik@pythonware.com Wed Jun 2 09:34:12 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 2 Jun 1999 10:34:12 +0200 Subject: [Image-SIG] 16 bit TIFF support References: <199906011946.OAA20969@smtp2.gte.net> Message-ID: <00d001beacd2$b1925720$f29b12c2@pythonware.com> > (I've gotten no responses from /F). you should have, by now ;-) as some of you might know, I'm operating in "single process, single thread" mode, and I'm only reading the image-sig about once a week. also see: http://www.pythonware.com/people/fredrik/busy.htm From akuchlin@mems-exchange.org Wed Jun 2 17:42:39 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Wed, 2 Jun 1999 12:42:39 -0400 (EDT) Subject: [Image-SIG] Threading patch for SANE module Message-ID: <199906021642.MAA13585@amarok.cnri.reston.va.us> Here's a small patch to Sane/_sanemodule.c, which allows other threads to run while an image is being acquired. I noticed this on the microscope server, where there's an option to send lots of low-res images while the stage is in motion. Enabling this caused movements to take 4 times as long, and I figured this was because the image acquiring thread was taking all the CPU time; this starved the thread that monitors the stage and terminates the first thread when the stage stops. The patch below helps a bit; I didn't add this to the .snap() method because that method is pretty complicated, and I didn't want to introduce a bug. Also, I may have sent this before, but the following line should go into Setup.in to show how to compile the SANE module. (I've been reinventing the line every time I do a fresh compile of PIL, which is silly.) #_sane Sane/_sanemodule.c -IlibImaging -L/usr/local/lib/sane/ -lsane-dll -- A.M. Kuchling http://starship.python.net/crew/amk/ Aristocrats need not be rich, but they must be free, and in the modern world freedom grows rarer the more we prate about it. -- Robertson Davies, "Osbert Sitwell" *** _sanemodule.c 1999/06/02 16:24:24 1.1 --- _sanemodule.c 1999/06/02 16:25:56 *************** *** 152,156 **** --- 152,160 ---- return NULL; } + + Py_BEGIN_ALLOW_THREADS st=sane_start(self->h); + Py_END_ALLOW_THREADS + if (st) return PySane_Error(st); Py_INCREF(Py_None); *************** *** 170,174 **** --- 174,182 ---- return NULL; } + + Py_BEGIN_ALLOW_THREADS sane_cancel(self->h); + Py_END_ALLOW_THREADS + Py_INCREF(Py_None); return Py_None; From fpinel@fedex.com Fri Jun 4 21:47:54 1999 From: fpinel@fedex.com (frederic pinel) Date: Fri, 04 Jun 1999 20:47:54 +0000 Subject: [Image-SIG] TIF G4 Message-ID: <37583B7A.A985F02B@fedex.com> Hello, I can't modify a G4 compressed TIF file, apparently the G4 is not supported, is that correct? thanks for any help, regards, frederic From KCAZA@cymbolic.com Tue Jun 8 01:18:30 1999 From: KCAZA@cymbolic.com (Kevin Cazabon) Date: Mon, 07 Jun 1999 17:18:30 -0700 Subject: [Image-SIG] problems with Image.crop Message-ID: It seems that I get a few nagging problems when using the Image.crop function: If I do a crop function on an Image object, I very frequently get AttributeErrors afterwards when I try to perform other methods (such as Image.convert). These AttributeErrors are always related to palette and info (palette stops it in its tracks first). I've gotten around it for now by making a deepcopy of the .palette and .info attributes of the image BEFORE doing a crop, then re-assigning them to the Image, but it's a pain in the butt. Here's the actual error, please let me know if you have any hints. Thanks, Kevin Cazabon Traceback (innermost last): File "", line 0, in ? File "D:\Python\Fusion_Analyzer_200Beta_allfiles\Unzipped Fusion Analyzer 2.00BETA\lib\imaging\Image.py", line 327, in convert return self._makeself(im) File "D:\Python\Fusion_Analyzer_200Beta_allfiles\Unzipped Fusion Analyzer 2.00BETA\lib\imaging\Image.py", line 223, in _makeself new.palette = self.palette AttributeError: palette From fredrik@pythonware.com Wed Jun 9 15:07:12 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 9 Jun 1999 16:07:12 +0200 Subject: [Image-SIG] problems with Image.crop References: Message-ID: <002f01beb281$afe2bc30$f29b12c2@pythonware.com> > It seems that I get a few nagging problems when using the Image.crop function: > > If I do a crop function on an Image object, I very frequently get AttributeErrors > afterwards when I try to perform other methods (such as Image.convert). These > AttributeErrors are always related to palette and info (palette stops it in its > tracks first). what version are you using. this bug was fixed back in 0.3a4 (March 98). the problem was that the _ImageCrop constructor didn't call Image's __init__ method, which left some attributes uninitialized. > Traceback (innermost last): > File "", line 0, in ? > File "D:\Python\Fusion_Analyzer_200Beta_allfiles\Unzipped Fusion Analyzer > 2.00BETA\lib\imaging\Image.py", line 327, in convert > return self._makeself(im) > File "D:\Python\Fusion_Analyzer_200Beta_allfiles\Unzipped Fusion Analyzer > 2.00BETA\lib\imaging\Image.py", line 223, in _makeself > new.palette = self.palette > AttributeError: palette fwiw, those line numbers don't seem to match 1.0b1 (too much work to figure out which one, though). From fredrik@pythonware.com Wed Jun 9 15:09:26 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 9 Jun 1999 16:09:26 +0200 Subject: [Image-SIG] TIF G4 References: <37583B7A.A985F02B@fedex.com> Message-ID: <003001beb281$b028ecf0$f29b12c2@pythonware.com> > I can't modify a G4 compressed TIF file, apparently the G4 is not supported, is > that correct? that's correct. PIL cannot read or write any of the CCITT formats supported by TIFF. various people have promised me interfaces to libtiff, but a complete interface has still to appear (I have a partial implementation by someone somewhere, but no time to finish it -- at least not in time for 1.0). From KCAZA@cymbolic.com Wed Jun 9 20:59:29 1999 From: KCAZA@cymbolic.com (Kevin Cazabon) Date: Wed, 09 Jun 1999 12:59:29 -0700 Subject: [Image-SIG] PIL 1.0 for Mac... Message-ID: Is there a pre-compiled version of PIL 1.0 for the Mac? I'm doing my development on Win98 and WinNT, but most of my end-users are on Mac stations (Service-Bureau type places that do all their imaging on Macs, which are the only POWERFUL units they have). I don't have a compiler for my Mac here, and was wondering if there's an easy out.... I can only find it pre-compiled for 95/98/NT and Linux. Thanks, Kevin Cazabon. From David_Marko2@digi-trade.cz Thu Jun 10 08:38:44 1999 From: David_Marko2@digi-trade.cz (David Marko2) Date: Thu, 10 Jun 1999 08:38:44 +0100 Subject: [Image-SIG] How to past image to another with transparency Message-ID: <375F6B84.21BB021B@digi-trade.cz> I have got two images. Big one(map) and small one GIF image made in Photoshop and saved with transparency enabled(transparent color is white). When I paste the second image to first one the shadow rectangle appears around the image ... no transparency is used. Hot to make it work? Please help. David From jack@oratrix.nl Thu Jun 10 09:58:44 1999 From: jack@oratrix.nl (Jack Jansen) Date: Thu, 10 Jun 1999 10:58:44 +0200 Subject: [Image-SIG] PIL 1.0 for Mac... In-Reply-To: Message by Kevin Cazabon , Wed, 09 Jun 1999 12:59:29 -0700 , Message-ID: <19990610085845.2256C303120@snelboot.oratrix.nl> > Is there a pre-compiled version of PIL 1.0 for the Mac? PIL is part of the standard MacPython distribution. It's an optional part, but I think it is installed by default (otherwise you'll have to go to the "custom installation" section of the installer). The version in the last Python distribution is 1.0beta1, I'll try to get the latest version included for Python 1.5.2, but I won't promise anything. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From KCAZA@cymbolic.com Thu Jun 10 16:42:56 1999 From: KCAZA@cymbolic.com (Kevin Cazabon) Date: Thu, 10 Jun 1999 08:42:56 -0700 Subject: [Image-SIG] PIL 1.0 for Mac... Message-ID: The Python 1.5.1 distrubution I downloaded about two weeks ago from www.python.org (python151.sit) included 0.3 I believe... because I'm getting the .palette and .info errors I mentioned a couple days ago (which have been rectified on my PC using 1.0). Is there better source for MacPython distrubutions (as I mentioned, most of my work is on NT/98, but I need to verify everything on Mac before I distribute it). Thanks again, Kevin Cazabon. >>> Jack Jansen 06/10/99 01:58AM >>> > Is there a pre-compiled version of PIL 1.0 for the Mac? PIL is part of the standard MacPython distribution. It's an optional part, but I think it is installed by default (otherwise you'll have to go to the "custom installation" section of the installer). The version in the last Python distribution is 1.0beta1, I'll try to get the latest version included for Python 1.5.2, but I won't promise anything. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm From pg@puggy.com" maybe a simple problem, if you know the solution.... Hi all, I'm trying to write a class for my own image processing needs. In this matter, I'm having problems with some variable declarations I'd like to create a image variable, let's call it myPicture . So I tried to declare myPicture = Image.Image() outside the class. This works fine for opening an image like myPicture.open("MyImage.jpg") file but I get an error when I try to save the image. Traceback (innermost last): File "D:\Inetpub\wwwroot\test_image\smPicUpload2.py", line 203, in ? smPic.save(savePath) File "D:\Inetpub\wwwroot\test_image\smPicture.py", line 45, in save myPicture.save(filename) File "c:\python.151\PIL\Image.py", line 615, in save SAVE[string.upper(format)](self, fp, filename) File "c:\python.151\PIL\JpegImagePlugin.py", line 297, in _save raise IOError, "cannot write mode %s as JPEG" % im.mode IOError: cannot write mode as JPEG Thanks for any help ! Patrick Note: Is it possible to use an Image object and pass it to a procedure ? From mona@eel.ucsd.edu Fri Jun 11 00:55:25 1999 From: mona@eel.ucsd.edu (Mona Wong) Date: Thu, 10 Jun 1999 16:55:25 -0700 Subject: [Image-SIG] Compile problem on SGI IRIX 6.2 Message-ID: <9906101655.ZM28345@eel.ucsd.edu> Hi: I'm attempting to compile PIL 1.0b1 on a SGI IRIX 6.2 machine. I got the following error: ... gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c Draw.c -o Draw.o In file included from Draw.c:28: /usr/local/lib/gcc-lib/mips-sgi-irix6.2/2.8.1/include/math.h:686: parse error before `size_t' gmake: *** [Draw.o] Error 1 I looked at the math.h file and it is this line: extern char * initstate(unsigned int, char *, size_t); Does anyone know how to fix this problem? Mona -- ================================================================== Mona Wong graphics / visualization programmer wanna-be & web fool-arounder National Center for Microscopy and Imaging Research University of California, San Diego http://www-ncmir.ucsd.edu/ ================================================================== From fredrik@pythonware.com Sun Jun 13 20:46:55 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Sun, 13 Jun 1999 21:46:55 +0200 Subject: [Image-SIG] help wanted: new TiffImagePlugin needs testing Message-ID: <009901beb5d5$7f59ddd0$f29b12c2@pythonware.com> An almost entirely rewritten TiffImagePlugin.py can be found at: http://www.pythonware.com/madscientist/tiff-990613.zip this version can read and write all standard PIL modes (including F and I), and seems to work just fine with all other apps I've gotten around to test it with. if you can, why not take it on a test drive, and report your findings back to this list. I'll check back on Wed- nesday. From cepaul@aether.bluelight.net Tue Jun 15 04:01:39 1999 From: cepaul@aether.bluelight.net (Charles Esteban Paul) Date: Mon, 14 Jun 1999 23:01:39 -0400 Subject: [Image-SIG] Errors compiling _tkinter with Imaging support Message-ID: <19990614230139.A1506@aether.bluelight.net> Output of compile attempt: ***************************** ~/src/python/Python-1.5.2/Modules$ make gcc -DWITH_APPINIT -I/usr/include -I/usr/X11R6/include -DWITH_PIL -I../Extensions/Imaging/libImaging -g -O2 -I./../Include -I.. -DHAVE_CONFIG_H -c ./tkImaging.c ./tkImaging.c:44: Imaging.h: No such file or directory make: *** [tkImaging.o] Error 1 ***************************** I have looked inside all of the include/ directories for Python1.52 and for Imaging-1.0b1 - yet I still cannot find Imaging.h I followed the directions in the Imaging README to the 't' - is there a logical step that I am missing here, or do I have to download Imaging.h in another tarball? Thanks for your time :) From cepaul@aether.bluelight.net Tue Jun 15 04:10:25 1999 From: cepaul@aether.bluelight.net (Charles Esteban Paul) Date: Mon, 14 Jun 1999 23:10:25 -0400 Subject: [Image-SIG] Excuse my previous message Message-ID: <19990614231025.B1506@aether.bluelight.net> I found what was errant in my procedure. Everything is OK now. Thanks again for your time :) From rburnham@cri-inc.com Tue Jun 15 15:40:23 1999 From: rburnham@cri-inc.com (Roger Burnham) Date: Tue, 15 Jun 1999 06:40:23 -800 Subject: [Image-SIG] Re: help wanted: new TiffImagePlugin needs testing Message-ID: <199906151339.IAA01344@mail1.gte.net> On 13 Jun 99, at 21:46, Fredrik Lundh mused: > An almost entirely rewritten TiffImagePlugin.py can be > found at: > > http://www.pythonware.com/madscientist/tiff-990613.zip > > this version can read and write all standard PIL modes > (including F and I), and seems to work just fine with all > other apps I've gotten around to test it with. > > if you can, why not take it on a test drive, and report > your findings back to this list. I'll check back on Wed- > nesday. > Thanks Fredrik, nice work! I tested this only on 16-bit grayscale images, using my modified _imaging.dll. To the OPEN_INFO, I added: (1, 1, (16,), ()): ("W", "L;16B"), and to SAVE_INFO, I added: "W": ("W", 1, 1, (16,), None), and then tested 5 images, written by a variety of other tiff writers (PhotoShop 4, ImagePro 4, another CRI C++ app, MetaMorph, and the previous version of TiffImagePlugin). The test was to read the image, write it out, read that image back in, and then test that all the pixel values (original vs written/read) were the same...all passed. The only thing I see missing is that many of the original tags are not written out in the saved tif: tag: ImageDescription (270) tag: Software (305) tag: DateTime (306) tag: unknown (33628) etc, Fredrik, have you had a chance to look at the 16bit mods I sent you? I understand you probably do not have time to fold this into 1.0 final, so, if you could comment on what I did send you, I'll fold it back into 1.0 final with your suggested changes. In particular, I know I need some guidance on implementing the packers/unpackers: What I did was somewhat blind copying/modifying of existing ones, not entirely sure I know what I'm doing and will be happy to change it to your satisfaction! I'd also volunteer to add the tag save functionality. Cheers, Roger Burnham Cambridge Research & Instrumentation rburnham@cri-inc.com http://www.cri-inc.com/ http://starship.python.net/crew/roger/ PGP Key: http://www.nai.com/default_pgp.asp PGP Fingerprint: 5372 729A 9557 5F36 177F 084A 6C64 BE27 0BC4 CF2D From fredrik@pythonware.com Wed Jun 16 12:05:57 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 16 Jun 1999 13:05:57 +0200 Subject: [Image-SIG] WG: How to create instance of Image ? References: <01BEB39E.AE7DB070.pg@puggy.com> Message-ID: <01c101beb7e8$e01dfd30$f29b12c2@pythonware.com> Graf Patrick wrote: > maybe a simple problem, if you know the solution.... > > I'm trying to write a class for my own image processing needs. > In this matter, I'm having problems with some variable declarations > I'd like to create a image variable, let's call it myPicture . > > So I tried to declare > > myPicture = Image.Image() what made you think you could write that? ;-) the only way to create new images in PIL is to use a factory function; the two most commonly used functions are Image.open and Image.new. see the docs for more info: http://www.pythonware.com/library/pil/handbook/image.htm > Note: Is it possible to use an Image object and pass it to a procedure ? pass it do a Python function? sure. like, say: def procedure(im): im.save("out.jpg") procedure(Image.open("in.ppm")) From fredrik@pythonware.com Wed Jun 16 12:10:41 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 16 Jun 1999 13:10:41 +0200 Subject: [Image-SIG] Compile problem on SGI IRIX 6.2 References: <9906101655.ZM28345@eel.ucsd.edu> Message-ID: <01c201beb7e8$e0645500$f29b12c2@pythonware.com> Mona Wong wrote: > I'm attempting to compile PIL 1.0b1 on a SGI IRIX 6.2 machine. I got > the following error: > > ... > gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c Draw.c -o Draw.o > In file included from Draw.c:28: > /usr/local/lib/gcc-lib/mips-sgi-irix6.2/2.8.1/include/math.h:686: parse error > before `size_t' > gmake: *** [Draw.o] Error 1 > > I looked at the math.h file and it is this line: > > extern char * initstate(unsigned int, char *, size_t); > > Does anyone know how to fix this problem? from the look of it, your math.h library doesn't include the necessary support files. you could try adding: #include before the math.h include in Draw.c. please tell us if that helped (I have access to a lot of platforms, but no SGI. contributions are wel- come ;-) From akuchlin@mems-exchange.org Thu Jun 17 23:34:12 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Thu, 17 Jun 1999 18:34:12 -0400 (EDT) Subject: [Image-SIG] PIL 1.0b1 bug confirmation wanted Message-ID: <199906172234.SAA07133@amarok.cnri.reston.va.us> PIL 1.0b1 seems to have problems generating PNG files; I can replicate it, but want to verify that other people see the bug too. Here's how to reproduce it: 1) Go to http://www.mems-exchange.org/software/microscope/PIL/ and download gif2png.py and output.gif into the same directory. (The output.png file in that directory is an example of a corrupt PNG file.) 2) Run gif2png.py, which reads output.gif and writes it out as output.png. When attempting to view output.png, xv reports 'libpng error: bad adaptive filter type'. The error happens whether I run PIL on Solaris or Linux; it does not happen with PIL 0.3b2 on Linux, but I haven't verified that on Solaris. I wrote a little Python program to parse the PNG apart into chunks, because I initially suspected my patch for adding comments to PNG files. However, the PNG seems to be legal; the problem is in the masses of compressed data making up the image. I'm willing to expend some effort tracking this down, but want to be sure that other people can reproduce the bug first, in case it depends on the version of libpng, zlib, or some other factor. -- A.M. Kuchling http://starship.python.net/crew/amk/ I want to be young and wild, and then I want to be middle-aged and rich, and then I want to be old and annoy people by pretending that I'm deaf. -- _Blackadder III_: "Nob and Nobility" From akuchlin@mems-exchange.org Thu Jun 17 23:51:51 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Thu, 17 Jun 1999 18:51:51 -0400 (EDT) Subject: [Image-SIG] Clarifying Image.info Message-ID: <199906172251.SAA07181@amarok.cnri.reston.va.us> The .info attribute of the Image class is vaguely defined, and only imperfectly supported. .info is a dictionary that's sometimes used for storing image comments and other metadata; on other occasions, it's used for internal functions by a given en/decoder. For instance, a while back I posted a patch to the PNG plug-in that writes out the contents of .info{} as text chunks. However, the PNG code sets info['gamma'] to a gamma-correction value, so I have to exclude it when writing out text chunks. The GIF module sets info['version'] to a string like 'GIF87a', and info['background'] to an integer (presumably the index of the background colour); my patch will need to be changed to exclude those keys, too. Using .info for both comments and various bits of private data mixes two different purposes in the same data structure. I propose, therefore, that these two purposes be separated, by creating a new attribute of Image objects such as .comments or .metadata (I'm vague on the name). This new attribute would hold textual comments, and *only* textual comments; image plug-ins would make an effort to incorporate this data when saving a new image. A plug-in might either only handle certain keys, or might handle everything in the dictionary. For example, if an image format has a single field for a comment, the PIL plug-in might only write out .comments['comment'], ignoring other keys. On the other hand, PNG text chunks contain key/value pairs, so the plug-in could just iterate over them. I think this is important, because in many applications where Python scripts will be doing image processing automatically, it's useful to be able to reliably add metadata; for example, a graph might contain info about the parameters used to draw it, or, in my microscope application, an image will hold metadata about the time, microscope settings, process step with which to associate this image, etc. I'm not sure how to introduce this change into PIL in a backwards-compatible way. Thoughts, anyone? -- A.M. Kuchling http://starship.python.net/crew/amk/ We were here before any other city that now stands. And we will sing the funeral songs that are sung for cities for them when they die. -- The role of the Necropolis Litharge, in SANDMAN #55: "Cerements" From rburnham@cri-inc.com Fri Jun 18 03:05:48 1999 From: rburnham@cri-inc.com (Roger Burnham) Date: Thu, 17 Jun 1999 18:05:48 -800 Subject: [Image-SIG] PIL 1.0b1 bug confirmation wanted In-Reply-To: <199906172234.SAA07133@amarok.cnri.reston.va.us> Message-ID: <199906180104.UAA10081@smtp2.gte.net> On 17 Jun 99, at 18:34, Andrew M. Kuchling mused: > PIL 1.0b1 seems to have problems generating PNG files; I can replicate > it, but want to verify that other people see the bug too. Here's how > to reproduce it: > > On Win95: Paint Shop Pro 4.12 says "An unknown filter type was encountered" IrfanView 3.0 says "PNG Decode error!" IE5 chugs for a while, then silently displays nothing, as does Netscape 4.5. Microsoft Photo Editor 3.0 says "Error reading file" after getting thru about 80% of its progress bar. (locally built _imaging.dll, with zlib 1.1.3). Cheers, Roger Burnham Cambridge Research & Instrumentation rburnham@cri-inc.com http://www.cri-inc.com/ http://starship.python.net/crew/roger/ PGP Key: http://www.nai.com/default_pgp.asp PGP Fingerprint: 5372 729A 9557 5F36 177F 084A 6C64 BE27 0BC4 CF2D From akuchlin@mems-exchange.org Sat Jun 19 15:56:14 1999 From: akuchlin@mems-exchange.org (A.M. Kuchling) Date: Sat, 19 Jun 1999 10:56:14 -0400 Subject: [Image-SIG] PNG writing bug Message-ID: <199906191456.KAA10256@207-172-35-110.s110.tnt9.brd.va.dialup.rcn.com> I'm beginning to suspect that this is a bug in zlib that trips when it fills up its output buffer in one particular situation, perhaps missing a byte somewhere. The code in ZipEncode seems OK and hasn't changed since 0.3b2; recompiling 0.3b2 with my current zlib library also manifests the bug. Changing Z_NO_FLUSH to Z_SYNC_FLUSH makes the bug go away, as does making the output buffer so large that it never fills up. I'm trying to find older versions of zlib to figure out what changed, but haven't succeeded yet. -- A.M. Kuchling http://starship.python.net/crew/amk/ "Everyone else got to read the Fatima prophecy... and all I got was this lousy T-shirt." Thanks. I'll treasure it always. -- Mulder gets a Christmas gift from Scully in X-FILES #1 From hshen@ski.org Wed Jun 23 02:08:38 1999 From: hshen@ski.org (Huiying Shen) Date: Tue, 22 Jun 1999 18:08:38 -0700 Subject: [Image-SIG] return Imaging to Python Message-ID: <37703396.B1F1E3D5@ski.org> Hi, I am writing an C-extension which takes Imaging as input from Python interpreter as well as return Imaging back to Python environment. I am having problem with the latter. VC++5.0 says: The instruction at 0x1e1388a9" referenced at "0x00000048". The memory could not be read. I used the identical code to generate a Python list in C and return it to python just fine. Any suggestion is appreciated. Huiying Here is the code: import skImagingc sk = skImagingc.skImTst2() #works ok dir(sk) #crashs python static PyObject *_wrap_skImTst2(PyObject *self, PyObject *args) { PyObject * _resultobj; self = self; if(!PyArg_ParseTuple(args,":skImTst2")) return NULL; { _resultobj = (PyObject*)skImTst2(); Py_INCREF(_resultobj); } return _resultobj; } Imaging skImTst2() { Imaging im = ImagingNew("RGB",10,15); return im; } -- Huiying Shen Programmer/System Administrator Smith-Kettlewell Eye Research Institute 2318 Fillmore Street San Francisco, CA 94115 e-mail: hshen@ski.org From fredrik@pythonware.com Thu Jun 24 14:24:30 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 24 Jun 1999 15:24:30 +0200 Subject: [Image-SIG] return Imaging to Python References: <37703396.B1F1E3D5@ski.org> Message-ID: <009301bebe44$e53ac480$f29b12c2@secret.pythonware.com> Huiying Shen wrote: > I am writing an C-extension which takes Imaging as input from Python > interpreter as well as return Imaging back to Python environment. I am > having problem with the latter. VC++5.0 says: The instruction at > 0x1e1388a9" referenced at "0x00000048". The memory could not be read. > > I used the identical code to generate a Python list in C and return it > to python just fine. an Imaging object is just an ordinary C struct, it's not a valid Python type (it doesn't have the PyObject_HEAD stuff required by Python). the Python bindings are defined in _imaging.c, and are currently not exported to external users. to work around this, you can: 1) link your stuff with the _imaging module, and call PyImagingNew to wrap an Imaging pointer in a Python-compatible Imaging- Object (see the _imaging.c sources for details). or: 2) create the new image in Python code, and pass its "id" attribute to your extension. an example: def myoperation(imIn, arg): imIn.load() imOut = Image.new(imIn.mode, imIn.size, None) mymodule.myoperation(imIn.im.id, imOut.im.id, arg) return imOut I usually use approach 2 for PIL extensions. From KCAZA@cymbolic.com Mon Jun 28 17:11:09 1999 From: KCAZA@cymbolic.com (Kevin Cazabon) Date: Mon, 28 Jun 1999 09:11:09 -0700 Subject: [Image-SIG] Tags in image headers... Message-ID: Just wondering if there's any easy to set the TIFF tag headers (and JPEG, BMP, etc as well) so that the DPI of the image (or more importantly, the physical size of the image) can be properly recorded. Currently, all images revert to the default 72dpi, so that if you want to print PIL images in a program like Photoshop, you have to manually go set the dpi setting again. I'd like to be able to do this properly... Is there some way to do this through the im.info attribute? Thanks, Kevin Cazabon. From gregc@cgl.ucsf.EDU Tue Jun 29 01:25:51 1999 From: gregc@cgl.ucsf.EDU (gregc@cgl.ucsf.EDU) Date: Mon, 28 Jun 1999 17:25:51 -0700 (PDT) Subject: [Image-SIG] 2 bug fix patches for Imaging-1.0b1 Message-ID: <199906290025.RAA127376@socrates.cgl.ucsf.EDU> Enclosed are two patches: one patch for PIL/ImageTk.py which allows PIL to work with multiple Tk interpreters (we run grail in a separate interpreter for application help and tutorials), and one for PIL/TiffImagePlugin.py so it recognizes more TIFF files (we still use Nextstep). Greg Couch gregc@cgl.ucsf.edu ---- *** ImageTk.py 1999/06/17 22:49:47 1.1 --- ImageTk.py 1999/06/17 22:54:02 *************** *** 171,179 **** class UI(Tkinter.Label): def __init__(self, master, im): if im.mode == "1": ! self.image = BitmapImage(im, foreground="white") else: ! self.image = PhotoImage(im) Tkinter.Label.__init__(self, master, image=self.image, bg="black", bd=0) --- 171,179 ---- class UI(Tkinter.Label): def __init__(self, master, im): if im.mode == "1": ! self.image = BitmapImage(im, foreground="white", master=master) else: ! self.image = PhotoImage(im, master=master) Tkinter.Label.__init__(self, master, image=self.image, bg="black", bd=0) *** TiffImagePlugin.py 1999/06/17 22:51:09 1.1 --- TiffImagePlugin.py 1999/06/17 22:53:45 *************** *** 209,215 **** self.tile = [] if self.tag.has_key(273): # striped image ! h = self.tag[278][0] w = self.size[0] a = None for o in self.tag[273]: --- 209,218 ---- self.tile = [] if self.tag.has_key(273): # striped image ! if self.tag.has_key(278): ! h = self.tag[278][0] ! else: ! h = self.size[1] w = self.size[0] a = None for o in self.tag[273]: From gelhaar@csi.com Tue Jun 29 23:59:16 1999 From: gelhaar@csi.com (Jens Gelhaar) Date: Wed, 30 Jun 1999 00:59:16 +0200 Subject: [Image-SIG] problems with Imaging 1.0b1 Message-ID: <001301bec283$11ff4940$0f42d3d4@gej98> This is a multi-part message in MIME format. ------=_NextPart_000_0010_01BEC293.C6C47F20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I use the following versions, Python 1.5.2 , Imaging 1.0b1. I tried to run the simple test: import os, sys import Image for infile in sys.argv[1:]: outfile =3D os.path.splitext(infile)[0] + "_NEU.JPG" print outfile if infile !=3D outfile: try: im =3D Image.open(infile) im.save(outfile,"JPEG") except IOError: print "cannot create thumbnail for", infile but, I got alway the following error message File "F:\Python\JPEGKleinerMachen.py", line 11, in ? im.save(outfile,"JPEG") File "E:\Programme\Python\Lib\imaging\Image.py", line 654, in save self.load() File "E:\Programme\Python\Lib\imaging\ImageFile.py", line 134, in load d =3D Image._getdecoder(self.mode, d, a, self.decoderconfig) File "E:\Programme\Python\Lib\imaging\Image.py", line 225, in = _getdecoder return apply(decoder, (mode,) + args + extra) TypeError: illegal argument type for built-in operation What is wrong? The example is from the tuturial? ------=_NextPart_000_0010_01BEC293.C6C47F20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

I use the following versions, Python 1.5.2 , Imaging 1.0b1.

I tried to run the simple = test:

import os, = sys
import=20 Image

for infile in=20 sys.argv[1:]:
    outfile =3D = os.path.splitext(infile)[0] +=20 "_NEU.JPG"
    print outfile
    if = infile=20 !=3D outfile:
       =20 try:
           = ; im =3D=20 Image.open(infile)
        &nb= sp;  =20 im.save(outfile,"JPEG")
        = except=20 IOError:
          &= nbsp;=20 print "cannot create thumbnail for", infile

but, I got alway the following error=20 message

File=20 "F:\Python\JPEGKleinerMachen.py", line 11, in ?
im.save(outfile,"JPEG")
File=20 "E:\Programme\Python\Lib\imaging\Image.py", line 654, in = save
self.load()
File=20 "E:\Programme\Python\Lib\imaging\ImageFile.py", line 134, in = load
d =3D=20 Image._getdecoder(self.mode, d, a, self.decoderconfig)
File=20 "E:\Programme\Python\Lib\imaging\Image.py", line 225, in=20 _getdecoder
return = apply(decoder, (mode,)=20 + args + extra)
TypeError: = illegal argument=20 type for built-in operation
 
What is wrong? The example is from the=20 tuturial?
------=_NextPart_000_0010_01BEC293.C6C47F20-- From fredrik@pythonware.com Wed Jun 30 11:58:07 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Wed, 30 Jun 1999 12:58:07 +0200 Subject: [Image-SIG] PNG writing bug References: <199906191456.KAA10256@207-172-35-110.s110.tnt9.brd.va.dialup.rcn.com> Message-ID: <001c01bec2e7$705ab7e0$f29b12c2@secret.pythonware.com> A.M. Kuchling wrote: > I'm beginning to suspect that this is a bug in zlib that trips when it > fills up its output buffer in one particular situation, perhaps > missing a byte somewhere. The code in ZipEncode seems OK and hasn't > changed since 0.3b2; recompiling 0.3b2 with my current zlib library > also manifests the bug. Changing Z_NO_FLUSH to Z_SYNC_FLUSH makes the > bug go away, as does making the output buffer so large that it never > fills up. I'm trying to find older versions of zlib to figure out > what changed, but haven't succeeded yet. should I change Z_NO_FLUSH to Z_SYNC_FLUSH? (if I understand things correctly, this will make the files a bit larger, but as long as the output buffer size is kept relatively large, that shouldn't matter much. just a few extra bytes per 64k block, most likely) From akuchlin@mems-exchange.org Wed Jun 30 13:58:50 1999 From: akuchlin@mems-exchange.org (Andrew M. Kuchling) Date: Wed, 30 Jun 1999 08:58:50 -0400 (EDT) Subject: [Image-SIG] PNG writing bug In-Reply-To: <001c01bec2e7$705ab7e0$f29b12c2@secret.pythonware.com> References: <199906191456.KAA10256@207-172-35-110.s110.tnt9.brd.va.dialup.rcn.com> <001c01bec2e7$705ab7e0$f29b12c2@secret.pythonware.com> Message-ID: <14202.5258.954159.439366@amarok.cnri.reston.va.us> Fredrik Lundh writes: >should I change Z_NO_FLUSH to Z_SYNC_FLUSH? I'm not presenting that as a solution; perhaps the bug only occurs when buffer space runs out at one particular point in the zlib code, and the Z_SYNC_FLUSH is merely disguising the problem by making the buffer space run out at a different point in zlib's code. It's annoying that there's no mailing list for discussion of zlib development and bug reports; the closest thing is comp.compression, but that's swamped with lots of questions about archiving programs. I'd like boil down the problem to a data set and a brief C program that manifests the bug, but haven't gotten around to doing that yet. -- A.M. Kuchling http://starship.python.net/crew/amk/ I've always believed that guilt was an emotion for weaker men -- so where does that leave me? -- Wesley Dodds, in SANDMAN MYSTERY THEATRE: "The Cannon", act I