From alopeza@fing.edu.uy Mon Jan 13 07:53:01 1997 From: alopeza@fing.edu.uy (Ing. Antonio Lopez Arredondo - CECAL -) Date: Mon, 13 Jan 1997 10:53:01 +0300 Subject: [PYTHON IMAGE-SIG] problems compiling PIL under Linux... Message-ID: <199701130753.KAA02791@ime16.fing.edu.uy> Hello ! I think that the possibility of doing image processing under Python is a great idea, and I want to do it in my installation here at the University of uruguay. I am running Linux 1.2.13 in a typical installation (nothing strange) but I have installed Python in a non standard location: /home/alopez/python-1.4 (not in /usr/local). In this scheme, I could not recompile Python in order to have PIL statically loaded. I succesfuly compiled de Imaging library, but I cannot add it as a module to the python interpreter; I follow the instructions and I cannot skip step 5: > 5. Go to the Imaging subdirectory in your Extensions directory. Copy > Setup.in to Setup. If you have the IJG JPEG library, or wish to > install Python in a non-standard place, you must edit the file > according to the instructions in it. I always get the same error message from the command "make -f Makefile.pre.in Makefile installdir=/home/internet/Python-1.4" : make: *** No rule to make target `/home/internet/Python-1.4/lib/python/lib/Makefile', needed by `sedscript'. Stop. So my question is: how should I modify the Setup file of the Imaging Library, to add it as a statically linked module to a Python interpreter that was compiled at the directory /home/internet/Python-1.4 ? Also, is there available anywhere a binary distribution for Linux ? Thanks in advance, antonio. ------------------------------------------------------------------------ ------------------------------------------------------------------------ Antonio Lopez Arredondo Centro de Calculo - Facultad de Ingenieria - Universidad de la Republica Julio Herrera y Reissig 565, (11300) Montevideo URUGUAY Phone: +598 2 714229 Email: alopeza@fing.edu.uy FAX : +598 2 715446 URL : http://www.fing.edu.uy/~alopeza ------------------------------------------------------------------------ ------------------------------------------------------------------------ ================= IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org ================= From fredrik_lundh@ivab.se Mon Jan 13 14:33:30 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Mon, 13 Jan 1997 15:33:30 +0100 Subject: [PYTHON IMAGE-SIG] problems compiling PIL under Linux... In-Reply-To: <199701130753.KAA02791@ime16.fing.edu.uy> (alopeza@fing.edu.uy) Message-ID: <9701131433.AA28996@arnold.image.ivab.se> Antonio writes: > So my question is: how should I modify the Setup file of the > Imaging Library, to add it as a statically linked module to > a Python interpreter that was compiled at the directory > /home/internet/Python-1.4 ? > > Also, is there available anywhere a binary distribution for Linux ? I'm clueless. Have anyone else done this under Linux? Regards /F PS. The following header line didn't look very appropriate to me. Might be idea to check your configuration: Cc: alopeza@ferrari.image.ivab.se ================= IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org ================= From fredrik_lundh@ivab.se Mon Jan 13 14:38:35 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Mon, 13 Jan 1997 15:38:35 +0100 Subject: [PYTHON IMAGE-SIG] problems compiling PIL under Linux... In-Reply-To: <199701130753.KAA02791@ime16.fing.edu.uy> (alopeza@fing.edu.uy) Message-ID: <9701131438.AA02528@arnold.image.ivab.se> > I have installed Python in a non > standard location: /home/alopez/python-1.4 (not in /usr/local). The following comments in Makefile.pre.in (which is a file that I didn't write) might be what you need: # Run "make -f Makefile.pre.in boot". This creates Makefile # (producing Makefile.pre and sedscript as intermediate files) and # config.c, incorporating the values for sys.prefix, sys.exec_prefix # and sys.version from the installed Python binary. For this to work, # the python binary must be on your path. If this fails, try # make -f Makefile.pre.in Makefile VERSION=1.4 installdir= # where is the prefix used to install Python for installdir # (and possibly similar for exec_installdir=). /F ================= IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org ================= From fdrake@CNRI.Reston.Va.US Mon Jan 13 14:38:28 1997 From: fdrake@CNRI.Reston.Va.US (Fred L. Drake) Date: Mon, 13 Jan 1997 09:38:28 -0500 (EST) Subject: [PYTHON IMAGE-SIG] problems compiling PIL under Linux... In-Reply-To: <9701131433.AA28996@arnold.image.ivab.se> from "Fredrik Lundh" at Jan 13, 97 03:33:30 pm Message-ID: <199701131438.JAA03465@weyr.CNRI.Reston.Va.US> Fredrik Lundh wrote: > > Antonio writes: > > So my question is: how should I modify the Setup file of the > > Imaging Library, to add it as a statically linked module to > > a Python interpreter that was compiled at the directory > > /home/internet/Python-1.4 ? > > > > Also, is there available anywhere a binary distribution for Linux ? > > I'm clueless. Have anyone else done this under Linux? Not yet, but I do plan to be doing this soon. I will post to this list about anything special I have to do. Statically building extensions is not as trivial as dynamically building them, but usually can be reduced to changes in the Modules/Setup file in the main Python source tree (or Setup.local starting with 1.4). -Fred -- Fred L. Drake, Jr. fdrake@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive Reston, VA 20191-5434 ================= IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org ================= From fredrik_lundh@ivab.se Sat Jan 11 18:09:00 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Sat, 11 Jan 1997 19:09:00 +0100 Subject: [PYTHON IMAGE-SIG] Announcing the Python Imaging Library, release 0.2b4 for Windows Message-ID: <9701111809.AA17248@arnold.image.ivab.se> Gott nytt =E5r, allihopa! A binary distribution of PIL 0.2b4, for Windows 95/NT, is now available at the usual place: http://www.python.org/sigs/image-sig/Imaging.html Lots of new stuff, including: + Plugged a number of serious memory leaks; PIL leaked lots of memory when loading PNG and tiled/striped TIFF images, and even more when saving images in any format. + PIL now reads nearly all formats that previous versions could only identify. This includes FLI/FLC, MSP, PSD, TIFF w. pre- dictor, TGA, and XPM. Decoders for compressed versions of SUN and TGA have also been added, but they are completely untested (samples of these formats would be very appreciated). + PIL now writes BMP, uncompressed GIF, and PNG. It also writes uncompressed MSP files, but that's mainly by accident. + PIL now handles GIF and FLI animations. Use the "player" script to view an animation. The "gifmaker" script can be used to create uncompressed GIF animations. + PIL now allows you to control the quality when writing JPEG files. You can also write progressive JPEG files. + The "image2py" script converts an image to a Python module. And the usual crop of bugfixes and assorted hacks. See the CHANGES file for details. The distributed version is linked with the external libraries required to enable JPEG and PNG support. A version of _tkinter.dll which supports PIL are also included. The source kit will be made available within short. Cheers /F PS. Unisys employees and affiliates may still use this software without charge, subject to the conditions in the software license (see the README for details). But according to modern business practices, this may be "adjusted" at any time, and without notice; and don't expect me to tell you the current conditions even if you ask me ;-) _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fredrik_lundh@ivab.se Tue Jan 14 18:56:10 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Tue, 14 Jan 1997 19:56:10 +0100 Subject: [PYTHON IMAGE-SIG] Announcing the Python Imaging Library, release 0.2b4 Message-ID: <9701141856.AA25112@arnold.image.ivab.se> The source distribution of PIL 0.2b4 is now available from the usual place: http://www.python.org/sigs/image-sig/Imaging.html Lots of new stuff, including: + Plugged a number of serious memory leaks; PIL leaked lots of memory when loading PNG and tiled/striped TIFF images, and even more when saving images in any format. + PIL now reads nearly all formats that previous versions could only identify. This includes FLI/FLC, MSP, PSD, TIFF w. pre- dictor, TGA, and XPM. Decoders for compressed versions of SUN and TGA have also been added, but they are completely untested (samples of these formats would be very appreciated). + PIL now writes BMP, uncompressed GIF, and PNG. It also writes uncompressed MSP files, but that's mainly by accident. + PIL now handles GIF and FLI animations. Use the "player" script to view an animation. The "gifmaker" script can be used to create uncompressed GIF animations. + PIL now allows you to control the quality when writing JPEG files. You can also write progressive JPEG files. + The "image2py" script converts an image to a Python module. And the usual crop of bugfixes and assorted hacks. See the CHANGES file for details. As so often before, there's been a few minor fixes to 0.2b4 after the Windows binary kit was releases. I'll update that one as soon as possible. Cheers /F _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fredrik_lundh@ivab.se Thu Jan 16 13:50:03 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 16 Jan 1997 14:50:03 +0100 Subject: [PYTHON IMAGE-SIG] viewer.py gives TclError on Unix (includes patch) Message-ID: <9701161350.AA30211@arnold.image.ivab.se> The Script/viewer.py file only runs fine under Windows. On a Unix box, it gives the following error: TclError: unknown color name "systembuttonface" See the attached patch for a quick workaround. Regards /F -------------------------------------------------------------------- *** viewer.py.bak Thu Jan 16 14:44:58 1997 --- viewer.py Thu Jan 16 14:46:14 1997 *************** *** 38,45 **** # # handle transparent images ! r, g, b = root.winfo_rgb("systembuttonface") ! rgb = r / 256, g / 256, b / 256 if im.mode == "P" and im.info.has_key("transparency"): --- 38,48 ---- # # handle transparent images ! try: ! r, g, b = root.winfo_rgb("systembuttonface") ! rgb = r / 256, g / 256, b / 256 ! except TclError: ! r = g = b = 0 # superimpose on black if im.mode == "P" and im.info.has_key("transparency"): _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fdrake@CNRI.Reston.Va.US Thu Jan 16 14:32:14 1997 From: fdrake@CNRI.Reston.Va.US (Fred L. Drake) Date: Thu, 16 Jan 1997 09:32:14 -0500 (EST) Subject: [PYTHON IMAGE-SIG] viewer.py gives TclError on Unix (includes patch) In-Reply-To: <9701161350.AA30211@arnold.image.ivab.se> from "Fredrik Lundh" at Jan 16, 97 02:50:03 pm Message-ID: <199701161432.JAA16240@weyr.CNRI.Reston.Va.US> Fredrik Lundh wrote: > The Script/viewer.py file only runs fine under Windows. On a Unix > box, it gives the following error: > > TclError: unknown color name "systembuttonface" How about: label = Label() r, g, b = root.winfo_rgb(label['background']) rgb = r / 256, g / 256, b / 256 label.destroy() This should work under NT as well; testing this is a long way from convenient for me here. The disadvantage is the creation of an intermediate widget, but a suitable existing widget is likely to be available in real applications. -Fred -- Fred L. Drake, Jr. fdrake@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive Reston, VA 20191-5434 _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fredrik_lundh@ivab.se Thu Jan 16 14:43:35 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 16 Jan 1997 15:43:35 +0100 Subject: [PYTHON IMAGE-SIG] viewer.py gives TclError on Unix (includes patch) In-Reply-To: <199701161432.JAA16240@weyr.CNRI.Reston.Va.US> (fdrake@CNRI.Reston.VA.US) Message-ID: <9701161443.AA11229@arnold.image.ivab.se> > This should work under NT as well; testing this is a long way from > convenient for me here. The disadvantage is the creation of an > intermediate widget, but a suitable existing widget is likely to be > available in real applications. Fred's right, as usual. Expect something along those lines in PIL 0.2b5. Cheers /F _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fredrik_lundh@ivab.se Thu Jan 16 15:15:23 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 16 Jan 1997 16:15:23 +0100 Subject: [PYTHON IMAGE-SIG] PDF files written by PIL is considered broken by Acrobat (includes fix) Message-ID: <9701161515.AA18004@arnold.image.ivab.se> Acrobat complains on PDF files written by PIL 0.2b4 (and earlier), but still renders them correctly. To get rid of the complaint, change the following line in PdfImagePlugin.py: fp.write("%%PDF-1.1\n") to fp.write("%PDF-1.1\n") # note! only one (1) percent here Also noticed that xpdf 0.6 fails to display PDF files created by PIL, but that's probably because the xpdf author has hacked his own JPEG code... Regards /F _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From ivantk@hotmail.com Thu Jan 16 19:00:28 1997 From: ivantk@hotmail.com (Ivan Tkatchev) Date: 16 Jan 1997 19:00:28 -0000 Subject: [PYTHON IMAGE-SIG] XPM support missing! Message-ID: <19970116190028.19835.qmail@hotmail.com> I can't load XPM images -- PIL complains that it was "unable to identify format". However, there is no "XpmImagePlugin.py" file!! This file was missing from the distribution. --------------------------------------------------------- Get Your *Web-Based* Free Email at http://www.hotmail.com --------------------------------------------------------- _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fredrik_lundh@ivab.se Thu Jan 16 19:08:59 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 16 Jan 1997 20:08:59 +0100 Subject: [PYTHON IMAGE-SIG] XPM support missing! In-Reply-To: <19970116190028.19835.qmail@hotmail.com> (ivantk@hotmail.com) Message-ID: <9701161908.AA14325@arnold.image.ivab.se> > However, there is no "XpmImagePlugin.py" file!! > This file was missing from the distribution. Ahem. The list of files to include in the distribution contains two XbmImagePlugin, but no Xpm-ditto. You could try the following plugin... /F # # The Python Imaging Library. # $Id: XpmImagePlugin.py,v 1.1 1997/01/14 16:38:36 fl Exp $ # # XPM File handling # # History: # 96-12-29 fl Created # # Copyright (c) Fredrik Lundh 1996. All rights reserved. # __version__ = "0.1" import regex, string import Image, ImageFile, ImagePalette # XPM header xpm_head = regex.compile("\"\([0-9]*\) \([0-9]*\) \([0-9]*\) \([0-9]*\)") def _accept(prefix): return prefix[:9] == "/* XPM */" class XpmImageFile(ImageFile.ImageFile): format = "XPM" format_description = "X11 Pixel Map" def _open(self): if not _accept(self.fp.read(9)): raise SyntaxError, "not an XPM file" # skip forward to next string while 1: s = self.fp.readline() if not s: raise SyntaxError, "broken XPM file" if xpm_head.match(s) > 0: break self.size = (string.atoi(xpm_head.group(1)), string.atoi(xpm_head.group(2))) pal = string.atoi(xpm_head.group(3)) bpp = string.atoi(xpm_head.group(4)) if pal > 256 or bpp != 1: raise ValueError, "cannot read this XPM file" # # load palette description palette = ["\0\0\0"] * 256 for i in range(pal): s = self.fp.readline() if s[-2:] == '\r\n': s = s[:-2] elif s[-1:] in '\r\n': s = s[:-1] c = ord(s[1]) s = string.split(s[2:-2]) for i in range(0, len(s), 2): if s[i] == "c": # process colour key rgb = s[i+1] if rgb == "None": self.info["transparency"] = c elif rgb[0] == "#": # FIXME: handle colour names (see ImagePalette.py) rgb = string.atoi(rgb[1:], 16) palette[c] = chr((rgb >> 16) & 255) +\ chr((rgb >> 8) & 255) +\ chr(rgb & 255) else: # unknown colour raise ValueError, "cannot read this XPM file" break else: # missing colour key raise ValueError, "cannot read this XPM file" self.mode = "P" self.palette = ImagePalette.raw("RGB", string.join(palette, "")) self.tile = [("raw", (0, 0)+self.size, self.fp.tell(), ("P", 0, 1))] def load_read(self, bytes): # # load all image data in one chunk xsize, ysize = self.size s = [None] * ysize for i in range(ysize): s[i] = string.ljust(self.fp.readline()[1:xsize+1], xsize) self.fp = None return string.join(s, "") # # Registry Image.register_open("XPM", XpmImageFile, _accept) Image.register_extension("XPM", ".xpm") Image.register_mime("XPM", "image/xpm") _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fredrik_lundh@ivab.se Fri Jan 17 11:16:45 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Fri, 17 Jan 1997 12:16:45 +0100 Subject: [PYTHON IMAGE-SIG] The Image.new() function doesn't initialize the new image Message-ID: <9701171116.AA23025@arnold.image.ivab.se> On page 15 in the PIL handbook, the following is said about the Image.new function: new( mode, size ) or new( mode, size, colour ) creates a new image with the given mode and size. Size is given as a 2-tuple. If colour is not given, the image is initialised to solid black. The last sentence is not true; if the colour is not given, the image is not initialised at all. Now, the only problem is whether I should change the documentation or the implementation. Opinions? Regards /F _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fdrake@CNRI.Reston.Va.US Fri Jan 17 13:43:38 1997 From: fdrake@CNRI.Reston.Va.US (Fred L. Drake) Date: Fri, 17 Jan 1997 08:43:38 -0500 (EST) Subject: [PYTHON IMAGE-SIG] The Image.new() function doesn't initialize the new image In-Reply-To: <9701171116.AA23025@arnold.image.ivab.se> from "Fredrik Lundh" at Jan 17, 97 12:16:45 pm Message-ID: <199701171343.IAA19643@weyr.CNRI.Reston.Va.US> Fredrik Lundh wrote: > Now, the only problem is whether I should change the documentation or > the implementation. Opinions? I have slightly mixed feelings on this one. I like the idea of it being initialized to something known, but a new implementation of Image.new() can be provided by applications that want that interface. The current implementation has a performance advantage which is probably small most of the time, but hard to regain once lost. I'd revise the documentation for this one, and interested applications could do something like: import Image def newImage(mode, size, color=None): if color is None: color = DEFAULT_COLORS[mode] return Image.new(mode, size, color) -Fred -- Fred L. Drake, Jr. fdrake@cnri.reston.va.us Corporation for National Research Initiatives 1895 Preston White Drive Reston, VA 20191-5434 _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fredrik_lundh@ivab.se Fri Jan 17 14:00:48 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Fri, 17 Jan 1997 15:00:48 +0100 Subject: [PYTHON IMAGE-SIG] The Image.new() function doesn't initialize the new image In-Reply-To: <199701171343.IAA19643@weyr.CNRI.Reston.Va.US> (fdrake@CNRI.Reston.VA.US) Message-ID: <9701171400.AA03556@arnold.image.ivab.se> Fred writes: > I have slightly mixed feelings on this one. I like the idea of it > being initialized to something known, but a new implementation of > Image.new() can be provided by applications that want that > interface. I'm currently leaning towards the following solution: Image.new(mode, size) => black, as described in the handbook Image.new(mode, size, None) => uninitialized, for speed freaks :-) Image.new(mode, size, ink) => user-defined I only need to change the default argument to make this work; it won't surprise people (as the current implementation seems to do, even when they haven't read the handbook), and it will not break any existing code. Cheers /F _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From guido@CNRI.Reston.Va.US Fri Jan 17 15:38:49 1997 From: guido@CNRI.Reston.Va.US (Guido van Rossum) Date: Fri, 17 Jan 1997 10:38:49 -0500 Subject: [PYTHON IMAGE-SIG] The Image.new() function doesn't initialize the new image In-Reply-To: Your message of "Fri, 17 Jan 1997 12:16:45 +0100." <9701171116.AA23025@arnold.image.ivab.se> References: <9701171116.AA23025@arnold.image.ivab.se> Message-ID: <199701171538.KAA18433@monty> > On page 15 in the PIL handbook, the following is said about the > Image.new function: > > new( mode, size ) or new( mode, size, colour ) creates a new image > with the given mode and size. Size is given as a 2-tuple. If colour is > not given, the image is initialised to solid black. > > The last sentence is not true; if the colour is not given, the image > is not initialised at all. > > Now, the only problem is whether I should change the documentation or > the implementation. Opinions? I assume that initializing the image takes a reasonable amount of time. It is useful to have a way to avoid wasting this time (often while the user is waiting!) for applications that know they are going to set every pixel anyway. So unless you are prepared to provide a different interface for creating an uninitialized image, I'd say, fix the documentation. --Guido van Rossum (home page: http://www.python.org/~guido/) _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fredrik_lundh@ivab.se Fri Jan 17 20:27:00 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Fri, 17 Jan 1997 21:27:00 +0100 Subject: [PYTHON IMAGE-SIG] The crop method doesn't work properly for palette images Message-ID: <9701172027.AA31946@arnold.image.ivab.se> A last-minute workaround to stop "crop" from crashing if the box extended outside the source image, messed things up when working with palette images. To fix this, replace the "crop" method in Image.py with the following code: def crop(self, box = None): "Crop region from image" self.load() if box == None: return self.copy() # the C implementation of crop is broken, so we implement # it by pasting into empty image instead. # im = self.im.crop(box) size = box[2]-box[0], box[3]-box[1] im = core.new(self.mode, size) im.paste(self.im, (-box[0], -box[1], self.size[0]-box[0], self.size[1]-box[1])) imOut = self._makeself(im) if imOut.mode == "P": imOut.im.putpalette("RGB", self.im.getpalette("RGB")) return imOut In future versions, this will be fixed in the C implementation, reducing the above code to a simple call to self.im.crop() instead. Regards /F _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fredrik_lundh@ivab.se Sat Jan 18 15:29:07 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Sat, 18 Jan 1997 16:29:07 +0100 Subject: [PYTHON IMAGE-SIG] PIL 0.2b4 doesn't handle FLC animations Message-ID: <9701181529.AA32177@arnold.image.ivab.se> As mentioned in the distribution files, the FLI/FLC decoder was only tested on a very small number of samples. The resulting code worked fine on FLI files, but not on the FLC version of the format. This has been fixed, and will be included in the next release. Regards /F PS. I still need compressed SUN, SGI, and TGA samples! _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From pas@xis.xerox.com Fri Jan 24 19:00:40 1997 From: pas@xis.xerox.com (Perry Stoll) Date: Fri, 24 Jan 1997 11:00:40 PST Subject: [PYTHON IMAGE-SIG] new decoders? Message-ID: <199701241900.OAA21875@fantod.xis.xerox.com> I'm curious to know the prognosis for new decoders in PIL. In my case, it would be helpful to have a wider range of tiff decoders, such as Group 3 or 4 Fax. How would something like this get added? Patches, shareware, freeware versions, /F writes it himself? I realize there was a specific decision not to use the tiff library, but can we "borrow" their codecs? -Perry _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fredrik_lundh@ivab.se Sat Jan 25 14:59:09 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Sat, 25 Jan 1997 15:59:09 +0100 Subject: [PYTHON IMAGE-SIG] new decoders? In-Reply-To: <199701241900.OAA21875@fantod.xis.xerox.com> (message from Perry Stoll on Fri, 24 Jan 1997 11:00:40 PST) Message-ID: <9701251459.AA29185@arnold.image.ivab.se> > I'm curious to know the prognosis for new decoders in PIL. In my > case, it would be helpful to have a wider range of tiff decoders, > such as Group 3 or 4 Fax. How would something like this get added? > Patches, shareware, freeware versions, /F writes it himself? I > realize there was a specific decision not to use the tiff library, > but can we "borrow" their codecs? I plan to provide a standard way to hook libtiff and other file based extension libraries into PIL, in order to make things easier for those working with TIFF G3/G4. A native Huffman/G3/G4 decoder is on the list, but not before 0.2 final. Cheers /F PS. FWIW, the various CCITT flavours are the only TIFF 6.0 codecs that PIL doesn't yet support. (TIFF/ZIP will be supported by 0.2 final) _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fredrik_lundh@ivab.se Sat Jan 25 14:59:09 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Sat, 25 Jan 1997 15:59:09 +0100 Subject: [PYTHON IMAGE-SIG] new decoders? In-Reply-To: <199701241900.OAA21875@fantod.xis.xerox.com> (message from Perry Stoll on Fri, 24 Jan 1997 11:00:40 PST) Message-ID: <9701251459.AA29185@arnold.image.ivab.se> > I'm curious to know the prognosis for new decoders in PIL. In my > case, it would be helpful to have a wider range of tiff decoders, > such as Group 3 or 4 Fax. How would something like this get added? > Patches, shareware, freeware versions, /F writes it himself? I > realize there was a specific decision not to use the tiff library, > but can we "borrow" their codecs? I plan to provide a standard way to hook libtiff and other file based extension libraries into PIL, in order to make things easier for those working with TIFF G3/G4. A native Huffman/G3/G4 decoder is on the list, but not before 0.2 final. Cheers /F PS. FWIW, the various CCITT flavours are the only TIFF 6.0 codecs that PIL doesn't yet support. (TIFF/ZIP will be supported by 0.2 final) _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From Jack.Jansen@cwi.nl Sat Jan 25 15:48:15 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Sat, 25 Jan 1997 16:48:15 +0100 Subject: [PYTHON IMAGE-SIG] new decoders? In-Reply-To: Message by Perry Stoll , Fri, 24 Jan 1997 11:00:40 PST , <199701241900.OAA21875@fantod.xis.xerox.com> Message-ID: <9701251548.AA13464=jack@snelboot.cwi.nl> Recently, Perry Stoll said: > > I'm curious to know the prognosis for new decoders in PIL. In my case, > it would be helpful to have a wider range of tiff decoders, such as > Group 3 or 4 Fax. How would something like this get added? Patches, > shareware, freeware versions, /F writes it himself? I realize there was > a specific decision not to use the tiff library, but can we "borrow" > their codecs? img can read tiff files, so with the img-to-pil bridge you should be able to process them in pil (although I haven't used the bridge recently). -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From C9503435@hud.ac.uk Tue Jan 28 08:41:15 1997 From: C9503435@hud.ac.uk (D.G.FIELDSEND) Date: Tue, 28 Jan 1997 08:41:15 +0000 Subject: [PYTHON IMAGE-SIG] University Project Message-ID: <47A7C9C5CC9@pegasus.hud.ac.uk> I am currently doing a project for Huddersfield University, England involving the interaction between 3D Graphics libraries and Python. Do you know of any shareware graphics libraries that can be wrapped (using SWIG, or other method) to Pyhton. I currently have a copy of ALICE on the PC, but I don't seem to be able to use this, can you suggest why. I also have access to PHIGS on the SUN system, so o you know of any pre-written wrappers for it. I hope you can help me in this request, but if not, could you let me know anyone, or anywhere else that might be able to aid me in this request. Thank you, David Fieldsend C9503435@pegasus.hud.ac.uk dfieldsend@geocities.com _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From tom.schwaller@linux-magazin.de Tue Jan 28 11:47:57 1997 From: tom.schwaller@linux-magazin.de (Tom Schwaller) Date: Tue, 28 Jan 1997 12:47:57 +0100 Subject: [PYTHON IMAGE-SIG] University Project References: <47A7C9C5CC9@pegasus.hud.ac.uk> Message-ID: <32EDE76D.725AE3B0@linux-magazin.de> D.G.FIELDSEND wrote: > > I am currently doing a project for Huddersfield University, England > involving the interaction between 3D Graphics libraries and Python. > > Do you know of any shareware graphics libraries that can be wrapped > (using SWIG, or other method) to Pyhton. > > I currently have a copy of ALICE on the PC, but I don't seem to be > able to use this, can you suggest why. > > I also have access to PHIGS on the SUN system, so o you know of any > pre-written wrappers for it. > > I hope you can help me in this request, but if not, could you let me > know anyone, or anywhere else that might be able to aid me in this > request.  Maybe the visualisation toolkit is what you are looking for. I once began with a Python wrapper, but changed my job and could not continue it the way I would have liked. There where other people working on it, but I never saw anything done. Here's the link http://www.cs.rpi.edu/~martink/ Wrapping it with SWIG might work on day, because Dave Beazley is certainly interested in that too... -- Tom Linux-Magazin (http://www.linux-magazin.de) _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From arb@connect.com.au Wed Jan 29 08:38:28 1997 From: arb@connect.com.au (Anthony Baxter) Date: Wed, 29 Jan 1997 19:38:28 +1100 Subject: [PYTHON IMAGE-SIG] writing windows icon files? Message-ID: <199701290838.TAA16194@jambu.off.connect.com.au> Anyone know what the format for Windows icon files is? We're generating icons for the mac, and the PC, and it'd be way cool to be able to use the same source for both. (can't see it in PIL 0.2b3, or mentioned in changes for b4) Ta, Anthony _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From Anthony Baxter Wed Jan 29 08:41:01 1997 From: Anthony Baxter (Anthony Baxter) Date: Wed, 29 Jan 1997 19:41:01 +1100 Subject: [PYTHON IMAGE-SIG] Re: writing windows icon files? In-Reply-To: Your message of "Wed, 29 Jan 1997 19:38:28 +1100." Message-ID: <199701290841.TAA16250@jambu.off.connect.com.au> Never mind. I just spotted pbmtoicon. I'll just crawl back into a box now. Anthony >>> Anthony Baxter wrote > > Anyone know what the format for Windows icon files is? We're generating > icons for the mac, and the PC, and it'd be way cool to be able to use the > same source for both. > > (can't see it in PIL 0.2b3, or mentioned in changes for b4) > > Ta, > Anthony _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From fredrik_lundh@ivab.se Wed Jan 29 12:56:31 1997 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Wed, 29 Jan 1997 13:56:31 +0100 Subject: [PYTHON IMAGE-SIG] writing windows icon files? In-Reply-To: <199701290838.TAA16194@jambu.off.connect.com.au> (message from Anthony Baxter on Wed, 29 Jan 1997 19:38:28 +1100) Message-ID: <9701291256.AA28896@arnold.image.ivab.se> > Anyone know what the format for Windows icon files is? Well, PIL can read them, so I guess we could teach PIL to write them too. But not today, please... Cheers /F _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From MHammond@skippinet.com.au Thu Jan 30 13:34:00 1997 From: MHammond@skippinet.com.au (Mark Hammond) Date: Thu, 30 Jan 1997 23:34:00 +1000 Subject: [PYTHON IMAGE-SIG] writing windows icon files? Message-ID: <199701301236.XAA20573@minotaur.labyrinth.net.au> I can send the relevent bits from the SDK(in RTF) - it defines the structures used. Mark. ---------------------------------------------------------------------- Mark Hammond - MHammond@skippinet.com.au Check out Python - _the_ language for the Web/CGI/Windows/MFC/Unix/etc & _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________ From Jack.Jansen@cwi.nl Thu Jan 30 16:01:45 1997 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 30 Jan 1997 17:01:45 +0100 Subject: [PYTHON IMAGE-SIG] PIL 0.2b4 for Mac available Message-ID: <9701301601.AA28433=jack@snelboot.cwi.nl> I've made a binary distribution for PIL 0.2b4 for Mac available, see http://www.cwi.nl/~jack/macpython.html or ftp://ftp.cwi.nl/pub/jack/python/mac for downloading. As usual: for Python 1.4 CFM68K or PPC, and the CFM68K version hasn't been tested. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen@cwi.nl | ++++ if you agree copy these lines to your sig ++++ http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm _______________ IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org _______________