From tratt@dcs.kcl.ac.uk Thu Sep 10 11:57:27 1998 From: tratt@dcs.kcl.ac.uk (Laurence Tratt) Date: Thu, 10 Sep 1998 11:57:27 +0100 Subject: [Image-SIG] Writing a plugin Message-ID: I'm writing a new plug in decoder for PIL (I'm doing this under 0.3b2) for a format that's specific to the platform I use (Acorn RISC OS) called simply a "Sprite". It's a bit of an odd format (in common with most image formats :)), but I've now managed to get most of the varieties that it can hold working (it can contain 24, 16, 8, 4, 2 and 1 bpp images) with and without palettes. However one thing is currently troubling me: mask data is held away from the main image and I can't see any obvious way of getting this to work. PIL has some nice obvious ways of coping with transparency if the data is held within the picture (ie for 24bpp sprites with a 8bit mask making a 32bit word) or if a colour is denoted to be the transparency (ie for gif files), but if there is support for genuine mask data held externally to the main image (it's actually held directly after the image), I can't find it: it certainly doesn't seem to be documented :( Can anyone help me on this? Oh, and just to make things a little more interesting, any bpp image can have a mask and although the mask data is simply On or Off, depending on the format of individual images, individual mask "bits" can be anything up to 8 bits long (thankfully when someone put their thinking head on this was sorted out a few years ago, so modern images all have 1 bit masks) :) On another note, to get support for 16, 4, 2 and 1bpp images working correctly, I have had to add 4 raw decoders to unpack/c: {"P;1R", 1, unpackP1R}, {"P;2R", 2, unpackP2R}, {"P;4R", 4, unpackP4R}, {"RGB;5", 16, ImagingUnpackRGB5}, RGB;5 is an obvious variation of the existing BGR;5 decoder, and the other ones are the same as their "non" R relatives, except that everything is stored lsb first. I have no idea what PIL policy is on adding raw unpackers (certainly my naming of the P decoders with the 'R' (for reversed :)) on the end is not something I particuarly like), but these decoders aren't down to some ultra- obscure format - it's just a byte-order difference - so that's why I haven't put them in their own /c file. I also have no idea what the procedure is for including any of this in the main distribution, if that's thought appropriate eventually. Suggestions are welcome :) Laurie who - frighteningly - still has some more questions, but thinks the the others should probably wait for a little while :) From fredrik@pythonware.com Thu Sep 10 13:57:13 1998 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 10 Sep 1998 13:57:13 +0100 Subject: [Image-SIG] Writing a plugin Message-ID: <001601bddcba$8e860ee0$f29b12c2@pythonware.com> >I'm writing a new plug in decoder for PIL (I'm doing this under 0.3b2) for >a format that's specific to the platform I use (Acorn RISC OS) called >simply a "Sprite". It's a bit of an odd format (in common with most image >formats :)), but I've now managed to get most of the varieties that it can >hold working (it can contain 24, 16, 8, 4, 2 and 1 bpp images) with and >without palettes. However one thing is currently troubling me: mask data is >held away from the main image and I can't see any obvious way of getting >this to work. > >PIL has some nice obvious ways of coping with transparency if the data is >held within the picture (ie for 24bpp sprites with a 8bit mask making a >32bit word) or if a colour is denoted to be the transparency (ie for gif >files), but if there is support for genuine mask data held externally to >the main image (it's actually held directly after the image), I can't find >it: it certainly doesn't seem to be documented :( Can anyone help me on >this? Well, I'm afraid there isn't any good support for this right now... We've been considering adding support for PA and LA images, but I'm not sure if I want to add a 16-bit internal format, and storing 8+1 bit pixels in 32 bits is a bit too wasteful for my taste (but on the other hand, that's definitely better than no support at all ;-) But for now, the only way out is to tweak the decoder to return such images as RGBA... not elegant, but again, it's better than nothing. >Oh, and just to make things a little more interesting, any bpp image can >have a mask and although the mask data is simply On or Off, depending on >the format of individual images, individual mask "bits" can be anything up >to 8 bits long (thankfully when someone put their thinking head on this was >sorted out a few years ago, so modern images all have 1 bit masks) :) > >On another note, to get support for 16, 4, 2 and 1bpp images working >correctly, I have had to add 4 raw decoders to unpack/c: > > {"P;1R", 1, unpackP1R}, > {"P;2R", 2, unpackP2R}, > {"P;4R", 4, unpackP4R}, > {"RGB;5", 16, ImagingUnpackRGB5}, > >RGB;5 is an obvious variation of the existing BGR;5 decoder, and the other >ones are the same as their "non" R relatives, except that everything is >stored lsb first. > >I have no idea what PIL policy is on adding raw unpackers (certainly my >naming of the P decoders with the 'R' (for reversed :)) on the end is not >something I particuarly like), but these decoders aren't down to some ultra- >obscure format - it's just a byte-order difference - so that's why I >haven't put them in their own /c file. Sounds reasonable. (there's no formal specification for packer names; guess the syntax is something like ; where flags are in alphabetical order. So "P;1R" etc is correct) >I also have no idea what the procedure is for including any of this in the >main distribution, if that's thought appropriate eventually. Suggestions >are welcome :) just send patches against the lastest release (or the affected files) to yours truly, and they'll appear in the next release. (once Garnet [1] goes gold, there will be a final 0.3/1.0 beta. Maybe as early as next week. After that, I just have to update the docs, and PIL will go 1.0). Cheers /F *) http://www.pythonware.com/secretlabs/garnetsnapshot1.jpg From cgw@pgt.com Thu Sep 10 13:25:17 1998 From: cgw@pgt.com (Charles G Waldman) Date: Thu, 10 Sep 1998 08:25:17 -0400 (EDT) Subject: [Image-SIG] Writing a plugin In-Reply-To: <001601bddcba$8e860ee0$f29b12c2@pythonware.com> References: <001601bddcba$8e860ee0$f29b12c2@pythonware.com> Message-ID: <13815.50477.83223.936289@sirius> Fredrik Lundh writes: > > We've been considering adding support for PA and LA images, but I'm > not sure if I want to add a 16-bit internal format, and storing 8+1 bit > pixels in 32 bits is a bit too wasteful for my taste (but on the other > hand, that's definitely better than no support at all ;-) > A 16-bit internal format would be *extremely* useful. I do a lot of processing of X-ray images, where 256 grey levels isn't enough. (I'm not talking about what is displayed, but what is used for intermediate processing). I tend to use the 32-bit "F" format, but a 16-bit format would be much more efficient. I've been thinking about adding a 16-bit format myself. It would be great if you added this to PIL so I don't have to! From Fred L. Drake, Jr." References: <001601bddcba$8e860ee0$f29b12c2@pythonware.com> Message-ID: <13815.55024.882878.611249@weyr.cnri.reston.va.us> Fredrik Lundh writes: > just send patches against the lastest release (or the affected files) > to yours truly, and they'll appear in the next release. Are you planning to include the PNG patches I sent to the SIG earlier? -Fred -- Fred L. Drake, Jr. Corporation for National Research Initiatives 1895 Preston White Dr. Reston, VA 20191 From fredrik@pythonware.com Thu Sep 10 16:03:04 1998 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 10 Sep 1998 16:03:04 +0100 Subject: [Image-SIG] Writing a plugin Message-ID: <008601bddccc$1d83d4e0$f29b12c2@pythonware.com> > Are you planning to include the PNG patches I sent > to the SIG earlier? Yup; I have a backlog of patches that will be in the next release: -- plugging a resource leak in the DIB driver (Roger Burnham) -- improvements for path.c (Richard Jones) -- Grail/pil_interface.py (Fred Drake) -- TIFF and PNG enhancements (various) -- additional unpackers (Laurence Tratt), if he sends me the patches before the weekend. -- (maybe) changes to the Tk interface to eliminate the need for a relinked _tkinter.so plus the usual bunch of bug fixes made in the labs. I'm also awaiting a few other highly interesting contributions... if they arrive before the weekend, they might make it into the next release. Cheers /F From fredrik@pythonware.com Mon Sep 14 22:00:25 1998 From: fredrik@pythonware.com (Fredrik Lundh) Date: Mon, 14 Sep 1998 22:00:25 +0100 Subject: [Image-SIG] Writing a plugin Message-ID: <002a01bde022$b2f0b030$f29b12c2@pythonware.com> A few days ago, I wrote: >(once Garnet [1] goes gold, there will be a final 0.3/1.0 beta. Maybe >as early as next week. After that, I just have to update the docs, and >PIL will go 1.0). Just thought I'd report that we just shipped the "gold master". Since we've worked around the clock (and more) on this one, I'll take a few days off to recharge my batteries. Expect the next PIL release to appear sometime between thurs- day and sunday. Cheers /F From warmerda@home.com Mon Sep 21 05:45:54 1998 From: warmerda@home.com (Frank Warmerdam) Date: Mon, 21 Sep 1998 00:45:54 -0400 Subject: [Image-SIG] PIL and Remote Sensing References: <002101bde232$869c14e0$f29b12c2@pythonware.com> Message-ID: <3605DA02.9F97DAF3@home.com> Fredrik and other Imaging SIGers, I have downloaded, built, and installed Python, and the Image 0.3b2. I have also reviewed the PIL docs at your site, and the web document on extending Python. I have also subscribed to the python imaging sig. Interesting stuff! I come from a satellite remote sensing background, and I am interested in how to integrate support for satelite imagery into Python and PIL. I am the primary author of the GDB API at PCI. GDB is a C API that abstracts access to a variety of remote sensing raster formats (as well as GIS vector formats). I am striking out on my own, and hoping to build a library tentatively called GDAL (GeoSpatial Data Abstraction Library) which would do something similar, but be free. A few things occur to me from this: o Does PIL always load the whole image, once it decides it needs some of it? This could make it difficult to work with very large images. o It seems that multi-band images (more than four bands) would have to handled as image sequences of "L" images. Is that correct? o It appears that 16bit data can only be supported as 32 bit floating point, though I understand you are considering a builtin 16bit data type. o There is no obvious way of supporting virtual file formats. For instance, in GDB there are some formats which aren't really related to files. For instance the file "VD0" opens a socket connection to another process, and accesses it's video memory as an image. I get the impression with PIL that the binary file is already opened, and the handled passed into the driver. On the other hand I was impressed by the way this file can be binary data from a stream, or an in memory string. I have reviewed some of your image file format support plugins, and they strike a familiar cord. :-) I was trying to think about ways of plugging in existing multi-format libraries, like GDB, or my hoped for GDAL. For instance, to add GDB I would need to call out to GDB from the _open() method which doesn't seem to match the pattern of any of your existing formats. I was thinking, it might be easiest to write an interface to the library as another extension, and then have PIL load that extention in a driver, which would allow it to call the Python interface from the PIL driver easily. I presume that the object for the purposes of this other library in Python could be placed into the ``info'' dictionary for specialized use. -- Is there any work on a Python library for vector data support anywhere? Best regards, -----------------------------------+--------------------------------------- Who can give them back their lives | Frank Warmerdam, Software Developer and all those wasted years? - Rush | URL http://members.home.com/warmerda | warmerda@home.com From gm@licht.hl-technik.de Mon Sep 21 12:36:14 1998 From: gm@licht.hl-technik.de (Georg Mischler) Date: Mon, 21 Sep 1998 10:36:14 -0100 Subject: [Image-SIG] how to add floating point color data to PIL ? Message-ID: <98Sep21.122556gmt-0100.32259@charon.HL-Technik.de> Hi all imageneers... I am considering to use PIL for the image manupulation module of a larger python application. However, I have to handle an input image format with is quite a bit different than most others. The images are generated by the lighting simulation system "radiance", and store luminance values as seen from a given view in a simulated scene. Due to the high dynamic range of this data the values are stored in floating point format, represented by 4 bytes for each pixel (the format also uses run length encoding, but that should not be a problem). The first three bytes are the red, green and blue mantissas, and the fourth byte is a common exponent for all three. So far everything is fine, routines to read, store and convert this format exist (in ansi C). The question that bothers me is how difficult it would be to use PIL for handling this kind of data, and how tricky the needed extensions will be to write. The user should be able to read such a file and the result will be converted to rgb image brighness values according to a gamma function for display. Users will want to edit the gamma value and see the result, as well as the "exposure" value, which sets an absolute relation between luminance and brightness. There may be other filters needed, which reduce the dynamic range of the data according to the way the human eye would perceive a given scene in reality. I assume that I will have to keep two sets of data in memory (unless I want to reread the original file for every filter operation), one holding the luminance values, and the other the converted brightness values for display. Now come the questions: - What PIL formats will be best for handling the different kinds of data? I guess that RGB (RGBA?) is simplest for dislpay. - Is it correct that the F format is currently designed for greyscale data only? Would I need to use three sets of F data to hold color luminance? - Could it make sense to "abuse" RGBA and store everything in there as it comes from the file? - Would it be simpler to add a new file format for floating point color data? If yes, how simple? - How difficult will it be to add filters to convert from and to each of the combined F, abused RGBA or new trippleF formats? - Can filters also be implemented as plugins? - I just realised that I haven't found out yet if plugins have to be implemented in python, or if they can also be written in C... - Any simple and obvious solution I may have overlooked? From the style of my descriptions you might be able to tell that I am not a CS guy... My background is architecture and daylighting design, though I do have a few years of programming experience with (auto)lisp, C, oberon and of course python. I plan to sell the result of this project (a GUI to radiance) commercially. If I actually manage to implement the functionality as above with PIL (and your help!), I think I will contribute the generally interesting parts of it to PIL, though maybe not before I see that my application actually sells... (don't hold your breath, this is sill months away). Ah, and before I forget, everything should work with NT and unix. Thanks for any insights! Georg Mischler schorsch@schorsch.com From fredrik@pythonware.com Tue Sep 22 16:36:30 1998 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 22 Sep 1998 17:36:30 +0200 Subject: [Image-SIG] Writing a plugin Message-ID: <009201bde63e$c687a0a0$f29b12c2@pythonware.com> last week, I wrote: >Expect the next PIL release to appear sometime between thurs- >day and sunday. How stupid of me. Of course I didn't find the time needed to merge all those patches and prepare a release kit. And I also received some cool contributions that I really would like to ship with this release: -- bilinear and bicubic interpolation (from Secret Labs) -- quad and mesh transforms (from Secret Labs) -- colour quantization (from Toby Sargeant) Won't have much time to work on this before the weekend, but then! Cheers /F From fredrik@pythonware.com Tue Sep 22 17:00:15 1998 From: fredrik@pythonware.com (Fredrik Lundh) Date: Tue, 22 Sep 1998 18:00:15 +0200 Subject: [Image-SIG] PIL and Remote Sensing Message-ID: <009f01bde642$339c1920$f29b12c2@pythonware.com> (First set of answers, to keep you going). > Interesting stuff! Sure is ;-) (And with you on the team, I think we can make it even more interesting!) > o Does PIL always load the whole image, once it decides it needs some > of it? This could make it difficult to work with very large images. Except for a few mode/compression combos on Win32 platforms, PIL always loads the full image. Adding a paged or tiled access scheme would require a major rewrite, since most operations assume that they have direct access to image data. But it's definitely on the todo list, and there are some clever sub- classing tricks that can be used in some situations. More on this in later posts. > o It seems that multi-band images (more than four bands) would have to > handled as image sequences of "L" images. Is that correct? "L" or "I" or "F", depending on the format. We're using a "DataFile" interface which supports some more advanced formats like NetCDF and GRIB. It basically returns an object that behaves like a list of Image objects, and delays loading until you actually load some image data. More details later. > o It appears that 16bit data can only be supported as 32 bit floating > point, though I understand you are considering a builtin 16bit data > type. Since 0.3a2, there's also support for 32-bit integer images (mode "I"). (not yet in the docs). There's some more info on this format in the CHANGES file. Adding a 16-bit format could require some major surgery, but I haven't ruled that one out yet. Most modern platforms are able to crunch 32-bit data at least as fast as 16-bit data, as long as you don't run out of memory. On the other hand, you always run out of memory sooner or later, and that's no fun... > o There is no obvious way of supporting virtual file formats. For > instance, in GDB there are some formats which aren't really related > to files. For instance the file "VD0" opens a socket connection to > another process, and accesses it's video memory as an image. I get > the impression with PIL that the binary file is already opened, and > the handled passed into the driver. You could subclass the Image class, and override the "load" method for this purpose (the file format handlers are implemented in this way). /snip/ >Is there any work on a Python library for vector data support anywhere? Not that I'm aware of. We're using pretty simple stuff today to deal with ArcInfo ungenerate files and some proprietary formats. Those readers basically returns the vector data as a sequence of ImagePath objects (that's an undocumented corner of PIL; read the path.c source for details...). Gotta run. More stuff to follow. Cheers /F From cgw@pgt.com Wed Sep 23 21:19:00 1998 From: cgw@pgt.com (Charles G Waldman) Date: Wed, 23 Sep 98 16:19 EDT Subject: [Image-SIG] Patch for SunImagePlugin Message-ID: I could have sworn I've submitted this patch before, but the bug is still present in PIL 0.3b2. SunImagePlugin fails to load Sun image files with a palette, because "ImagePalette" is undefined in the scope of SunImagePlugin. As is so often the case, the description of the problem is longer than the patch! rcsdiff -u SunImagePlugin.py =================================================================== RCS file: SunImagePlugin.py,v retrieving revision 1.1 diff -u -r1.1 SunImagePlugin.py --- SunImagePlugin.py 1998/09/23 20:15:32 1.1 +++ SunImagePlugin.py 1998/09/23 20:15:58 @@ -19,7 +19,7 @@ import regex, string -import Image, ImageFile +import Image, ImageFile, ImagePalette def i16(c): From R.Hooft@EuroMail.com Thu Sep 24 10:34:13 1998 From: R.Hooft@EuroMail.com (Rob Hooft) Date: Thu, 24 Sep 1998 11:34:13 +0200 (MZT) Subject: [Image-SIG] Patch for BmpImagePlugin Message-ID: <13834.4629.194259.650515@octopus.chem.uu.nl> Here is a patch that makes PIL read Bmp images made by Windows, where the number of colors is smaller than the maximum for the number of bits per pixel (I have an 8bit image here that uses a 32 color palette). *** /usr/people/hooft/p/basis4/Imaging-0.3b2/PIL/BmpImagePlugin.py Sun Jul 19 16:25:14 1998 --- ./BmpImagePlugin.py Thu Sep 24 11:19:04 1998 *************** *** 70,75 **** --- 70,76 ---- bits = i16(s[10:]) self.size = i16(s[4:]), i16(s[6:]) lutsize = 3 + colors=1 << bits elif len(s) in [40, 64]: *************** *** 77,82 **** --- 78,86 ---- bits = i16(s[14:]) self.size = i32(s[4:]), i32(s[8:]) self.info["compression"] = i32(s[16:]) + colors=i32(s[32:]) + if colors==0: + colors=1 << bits lutsize = 4 else: *************** *** 90,96 **** # LUT if self.mode == "P": - colors = 1 << bits palette = [] greyscale = 1 if colors == 2: --- 94,99 ---- From jcurry@llnl.gov Thu Sep 24 21:22:28 1998 From: jcurry@llnl.gov (James Curry) Date: Thu, 24 Sep 1998 13:22:28 -0700 Subject: [Image-SIG] writing a file decoder Message-ID: <360AAA04.F15979D9@llnl.gov> Hi, I'm attempting to write my own file decoder using the example in the PIL handbook as a model. My image files are in the FITS (Flexible Image Transport System) format. They have a 2880 byte header, followed by the image data which is 32 bit unsigned big-endian integer. I'm using the raw decoder (mode F;32B). The plug-in works - sort of. I'm wondering how I can control how the pixel values get mapped to colors. What I'd like is grey scale mapping or a mapping to a spectrum of red to blue. Can someone offer some pointers? Thanks. -Jim - - James Curry | Phone: 925.423.1106 Lawrence Livermore National Laboratory | FAX: 925.423.6775 P.O. Box 808, MS:L-183 | Livermore, CA 94550 | jcurry@llnl.gov From rburnham@cri-inc.com Tue Sep 29 17:19:58 1998 From: rburnham@cri-inc.com (Roger Burnham) Date: Tue, 29 Sep 1998 11:19:58 -500 Subject: [Image-SIG] Transparent colored overlay effect Message-ID: <199809291518.AA10523@world.std.com> Howdy all, I'm implementing a principal component analysis of multivariate images application (same sample taken at multiple wavelengths) and need help in achieving a desired effect. From various computed images, the user selects regions, each of which identifies certain pixels in another computed image. This later image I'll call the overlay image. I would like to render the overlay image with the identified pixels "shaded" a selected color; i.e. you can still see the gray-scale intensities thru a "tinged" color (I've seen this in other commercial apps...). Currently, all I can achieve is to draw these pixels in opaque colors as follows: The overlay image is a gray scale image scaled so that all pixel values are between 0 and 255 - (max number of possible colored overlays), then converted to an RGB image. Then, given a list of masks (255 at the pixels of interest, 0 everywhere else) and colorLut[3] (the 256 gray scale ramp): lut = copy.copy(colorLut[3]) rlut, glut, blut = lut[:256], lut[256:512], lut[512:] i = 0 for img in self.masks: nV = 255 - i pasteImg = img.point(lambda p,nV=nV: p==255 and nV) overlayImg.paste(pasteImg, mask=img) rlut[nV], glut[nV], blut[nV] = rgb(_overlayColorsUsed[i]) i = i + 1 newImg = overlayImg.point(rlut+glut+blut) newImg now shows the original image with each mask showing in an opaque color. Any ideas on how I can get the overlain masks to be "slightly" transparent so that the underlying gray scale intensities are still discernable? Thanks, Roger Burnham rburnham@cri-inc.com Cambridge Research & Instrumentation www.cri-inc.com From cgw@pgt.com Tue Sep 29 17:50:54 1998 From: cgw@pgt.com (Charles G Waldman) Date: Tue, 29 Sep 1998 12:50:54 -0400 (EDT) Subject: [Image-SIG] Transparent colored overlay effect In-Reply-To: <199809291518.AA10523@world.std.com> References: <199809291518.AA10523@world.std.com> Message-ID: <13841.4078.354830.29464@janus.pgt.com> Roger Burnham writes: > image. I would like to render the overlay image with the identified pixels > "shaded" a selected color; i.e. you can still see the gray-scale intensities > thru a "tinged" color (I've seen this in other commercial apps...). > There's more than one way to do this, I'm sure. One thing you could do is create the overlay as an RGBA image with an alpha (opacity) channel. Here's a (not very optimized) example. It puts up a greyscale testpattern and with an overlaid transparent red square in the middle. The slider allows you to adjust the opacity of the red square. from Tkinter import * import Image from ImageTk import PhotoImage from string import atoi class Demo(Frame): def __init__(self,master=None): Frame.__init__(self, master) self.createWidgets() def createWidgets(self): self.image = Image.new('RGB',(256,256),0) for y in range(0,256): for x in range(0,256): v = (x*4)%256 self.image.putpixel((x,y),(v,v,v)) self.mask = Image.new("RGBA",(256,256)) self.photo = PhotoImage(image=self.image) self.slider = Scale(self, from_=0,to=255, command=self.set_alpha,orient=HORIZONTAL) self.slider.pack() self.label = Label(self, image=self.photo) self.label.pack() self.pack() def set_alpha(self,alpha): alpha = atoi(alpha) for y in range(128-32,128+32): for x in range(128-32,128+32): self.mask.putpixel((x,y),(255,0,0,alpha)) im2 = self.image.copy() im2.paste(self.mask,None,self.mask) self.photo = PhotoImage(image=im2) self.label['image']=self.photo self.update() if __name__=="__main__": Demo().mainloop() From andjr@intekom.co.za Wed Sep 30 08:24:41 1998 From: andjr@intekom.co.za (Robert) Date: Wed, 30 Sep 1998 09:24:41 +0200 Subject: [Image-SIG] PIL Message-ID: <19981130073506.AAA24674@jackal.intekom.com.intekom.co.za@Intekom8102.intekom.co.za> Hi Could you please help me with PIL when ever i try to see the image using eg: a.show() it returns a message to the console: Bad command or file name Please help me. The version I have is 0.3a5, I downloaded it with the PYTHON 15. KIT Please get back to me as soon a possible Thanx Robert From andjr@intekom.co.za Wed Sep 30 14:24:35 1998 From: andjr@intekom.co.za (Robert) Date: Wed, 30 Sep 1998 15:24:35 +0200 Subject: [Image-SIG] PIL Message-ID: <19981130133458.AAA25117@jackal.intekom.com.intekom.co.za@Intekom8102.intekom.co.za> Hi I am running Python on a Windows 95 box Robert ---------- > From: Steinar Knutsen > To: Robert > Cc: Python Imaging > Subject: Re: [Image-SIG] PIL > Date: 30 November 1998 14:17 > > On Wed, 30 Sep 1998, Robert wrote: > > > Could you please help me with PIL > > > > when ever i try to see the image using > > > > eg: > > > > a.show() > > > > it returns a message to the console: > > > > Bad command or file name > > PIL on un*x tries to spawn xv when the show method is invoked. Do you have > this available on your system? > > Steinar