From spillar@uwyo.edu Thu Mar 7 16:22:21 1996 From: spillar@uwyo.edu (Earl J Spillar) Date: Thu, 07 Mar 1996 09:22:21 -0700 (MST) Subject: [PYTHON IMAGE-SIG] FITS images place in Module Space Message-ID: Fredrik Lundh said- On the other hand, a FITS reader should probably be part of PIL rather than some other module. I've already hacked a simple version, but haven't tested it much. Maybe your module could be plugged in instead? This makes sense. I wasn't aware of PIL until these posts. I'm not sure my module is all that useful yet- it mostly deals with the header parts so far, and calls some legacy free standing executables for data operations. The Python Imaging Library, release 0.1, is nearly completed, and I hope to release it within a few weeks. I've even written a handbook for it... I'ld be very interested in seeing how the handbook! Earl Spillar spillar@uwyo.edu http://plains.uwyo.edu/~spillar/ ================= IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org ================= From mclay@eeel.nist.gov Thu Mar 7 18:00:27 1996 From: mclay@eeel.nist.gov (Michael McLay) Date: Thu, 7 Mar 96 13:00:27 EST Subject: [PYTHON IMAGE-SIG] Gimp as a starting point Message-ID: <9603071800.AA00974@acdc.eeel.nist.gov> Is anyone considering wrapping GIMP (General Image Manipulation Program) into a Python module? http://www.XCF.Berkeley.EDU/~gimp/gimp.html I couldn't get it to run on my system because I don't have Motif. I did look at a screen shot. GIMP looks like a PD version of Adobe Photoshop. The Motif library should be replaced with Tkinter and the plug-in concept that GIMP lifted from Adobe Photoshop should also be replace with Python import mechanism. This would be kind of a nifty Grail applet:-) Michael ================= 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 Mon Mar 11 21:04:39 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Mon, 11 Mar 1996 22:04:39 +0100 Subject: [PYTHON IMAGE-SIG] The img library Message-ID: <9603112104.AA10124=jack@schelvis.cwi.nl> Hi, I've just subscribed and I didn't check the archive yet (so I don't know whether anyone else already mentioned it), but I guess I should start with a plug for my set of image modules, "img". The current distribution, in , is version 1.2 (despite the directory name:-). There are modules there to read and write a number of image formats (gif, tiff, pbm, sgi) and automatically convert them to a format that is suitable for your program. I haven't put much work into it recently, and there's some stuff I'd like to redesign, but it may be a starting point. -- 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 Jack.Jansen@cwi.nl Wed Mar 20 13:30:33 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Wed, 20 Mar 1996 14:30:33 +0100 Subject: [PYTHON IMAGE-SIG] Anybody here? Message-ID: <9603201330.AA14737=jack@schelvis.cwi.nl> Is there anybody except myself actually on this mailing list? I posted a message last week, and not only did no-one react to it but I didn't see any messages come by here... -- 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 fredrik_lundh@ivab.se Wed Mar 20 13:42:22 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Wed, 20 Mar 1996 14:42:22 +0100 Subject: [PYTHON IMAGE-SIG] The PIL library -- specification for release 0.1 Message-ID: <9603201342.AA03736@arnold.image.ivab.se> Hi everyone, Thought it's about time I distributed some more information on the Python Imaging Library I've been hacking on recently. I've attached a specification that attempts to describe what's in the first public release. All comments are welcome. If everything goes according to the plans, I'll spend the weekend putting together a release. Stay tuned/F -------------------------------------------------------------------- Python Imaging Library (PIL), release 0.1 *** Module Image class Image: "A raster image" mode -- number of bands, pixel type ["L", "P", "RGB", "RGBA", "CMYK"] palette -- colour table, for "P" type images size -- image size in pixels info -- associated data (dictionary) def convert(mode) def copy() def crop(box) def dither(palette) def filter(kernel) -- user-defined 3x3, 5x5 convolutions, integer kernels def histogram() def load() def paste(image, box, [alpha]) def resize(size) def rotate(angle) def save(filename, [format]) def show() -- currently for unix only def split() def transpose(operation) def transform(size, AFFINE, matrix) def new(mode, size): return def open(filename): return def blend(image, image, ratio): return def join(mode, band, band...): return *** Module ImageFile class ImageFile(Image): "A raster image read from file or stream" def load(file) class XxxImageFile(ImageFile): "Read/write XXX file" (see below) *** Module ImagePalette class ImagePalette(): "A colour lookup table for palette images" mode palette def negative(): return def random(): return def wedge(): return *** Module ImageFilter class ImageFilter(): "Represents an environment filter operation" class ImageFilterKernel(ImageFilter): "Simple 3x3 and 5x5 integer convolutions" *** File format support (in release 0.1) format supported operations ------ -------------------- BMP open/read/write EPS open (1) FLI (FLC) open (1) GBR open/read GIF open/read IIF open/read (2) JPEG (JFIF) open/read/write (3) MSP open (1) PBM (PGM/PPM) open/read/write PCX open/read PSD open (1) TIFF open/read (2) (1) file is identified (mode, size), but not decoded. (2) restricted, not full baseline support. (3) requires IJG JPEG support library (libjpeg) ================= 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 Mar 20 13:55:20 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Wed, 20 Mar 1996 14:55:20 +0100 Subject: [PYTHON IMAGE-SIG] Anybody here? In-Reply-To: <9603201330.AA14737=jack@schelvis.cwi.nl> (message from Jack Jansen on Wed, 20 Mar 1996 14:30:33 +0100) Message-ID: <9603201355.AA02913@arnold.image.ivab.se> Jack Jansen wrote: > Is there anybody except myself actually on this mailing list? Since I see all the subscription messages, there's obviously quite a lot of people lurking around here... Hopefully, the PIL proposal could get some discussion going (and I promise to delay the release even further if enough good ideas pops up in the process :-) BTW, are there any GIS folks here? If so, what would you think about adding GeoTIFF support to PIL? /F ================= IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org ================= From mclay@eeel.nist.gov Wed Mar 20 14:37:42 1996 From: mclay@eeel.nist.gov (Michael McLay) Date: Wed, 20 Mar 96 09:37:42 EST Subject: [PYTHON IMAGE-SIG] Anybody here? In-Reply-To: <9603201330.AA14737=jack@schelvis.cwi.nl> References: <9603201330.AA14737=jack@schelvis.cwi.nl> Message-ID: <9603201437.AA22770@acdc.eeel.nist.gov> Jack Jansen writes: > Is there anybody except myself actually on this mailing list? I posted > a message last week, and not only did no-one react to it but I didn't > see any messages come by here... I'm lurking on the list. Seems to be kind of quiet here. I suspect it would pick up a bit if there were a Python based image library or better yet an application that ran on multiple platforms. I recall seeing anouncements of a soon to be released library, but so far nothing has surfaced. Michael ================= 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 Wed Mar 20 15:15:21 1996 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 20 Mar 1996 10:15:21 -0500 Subject: [PYTHON IMAGE-SIG] The PIL library -- specification for release 0.1 In-Reply-To: Your message of "Wed, 20 Mar 1996 14:42:22 +0100." <9603201342.AA03736@arnold.image.ivab.se> References: <9603201342.AA03736@arnold.image.ivab.se> Message-ID: <199603201515.KAA07904@monty> Interesting. Will this interact with Tk? I'd love to be able to stuff images in a Tk "photo image" object without having to write it to a file in GIF or PPM format first... --Guido van Rossum URL: ================= 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 Wed Mar 20 15:15:21 1996 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Wed, 20 Mar 1996 10:15:21 -0500 Subject: [PYTHON IMAGE-SIG] The PIL library -- specification for release 0.1 In-Reply-To: Your message of "Wed, 20 Mar 1996 14:42:22 +0100." <9603201342.AA03736@arnold.image.ivab.se> References: <9603201342.AA03736@arnold.image.ivab.se> Message-ID: <199603201515.KAA07904@monty> Interesting. Will this interact with Tk? I'd love to be able to stuff images in a Tk "photo image" object without having to write it to a file in GIF or PPM format first... --Guido van Rossum URL: ================= 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 Mar 21 08:06:19 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 21 Mar 1996 09:06:19 +0100 Subject: [PYTHON IMAGE-SIG] The PIL library -- specification for release 0.1 In-Reply-To: <199603201515.KAA07904@monty> (message from Guido van Rossum on Wed, 20 Mar 1996 10:15:21 -0500) Message-ID: <9603210806.AA09433@arnold.image.ivab.se> Guido writes: > Interesting. Will this interact with Tk? I'd love to be able to > stuff images in a Tk "photo image" object without having to write it > to a file in GIF or PPM format first... Of course. I had Grail in mind when I designed some of the PIL features (more on this below). I mean, imagine what you can do if you stuff image processing support into a web-browser! Anyway, I have a Tk photo image interface that seems to be working, but I haven't had the time to figure out how add it to Tk in a clean way (the current version is boldly patched into Tk. Are there any Tk experts out there that have done similar things, drop me a line!). Anyway, this interface allows you to create a photo image out of a PIL Image object. Even more interesting for Grail, PIL allows you to decode data incrementally (including TIFF). Each raster data decoders has an "expose" method that takes a string of bytes, and returning the amount of data it was able to use. If we boldly ignore the code required to identify and read the file header (some clever use of StringIO is required here), and bind the decoder to the image memory, you can do something like: buf = sio.getvalue()[headersize:] while 1: s, e = decoder.expose(buf) if s < 0: break # e is error code, 0 if completed buf = buf[s:] s = io.read(bufsize) if not s: break # file is truncated buf = buf + s if time_to_update(): update_screen() Just add some code to set the bufsize based on the connection speed, and to determine when its appropriate to update the screen, and you have a nice, progressive image display... Maybe in Grail 0.4? /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 Mar 21 07:38:40 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 21 Mar 1996 08:38:40 +0100 Subject: [PYTHON IMAGE-SIG] The PIL library -- specification for release 0.1 In-Reply-To: <199603202202.QAA00453@wellington.friday.com> (message from Bill Bumgarner on Wed, 20 Mar 96 16:02:10 -0600) Message-ID: <9603210738.AA21132@arnold.image.ivab.se> Bill Bumgarner have a lot of good points: > Sam Leffler's [sp.] libTIFF package reads and writes basically any > format of TIFF file imaginable-- including TIFF with JPEG compression > through the use of the IJG code. Yep, I'm well aware of this library, but the current plans for PIL are definitely a bit more radical: The current PIL file drivers parses all headers and metadata in Python code, leaving only the actual raster data to tiny codecs written in C. Since parsing TIFF is trivial, its more a matter of providing codecs for the various compression variants. PIL contains quite a few in 0.1, libTIFF even more, so maybe snatching the remaining libTIFF codecs might be wiser than integrating the library itself. (In addition, I don't really trust a library that claims there's such a thing as native bit order :-) > The gd library by Tom Boutell provides a relatively complete ANSI > interface for manipulating GIF files. If I remember correctly, some > kind soul has already built a python module that wraps gd's > functionality. Have anyone looked into how this library is designed? Creating a graphics interface on top of the internal PIL raster storage format would be a great idea (okay, hacking graphics is fun and not very difficult, so I guess could I do most of it from scratch, if someone finds me a good text package...). Maybe Boutell's code could be used as a base. > Decoding and encoding the various image formats can be rather > expensive. For example, web sites that compose GIF images comprised > of other GIF on the fly incur a massive penalty; every original > image must be decompressed, and the resulting image must then be > compressed. Hmm. When it comes to relatively straightforward compression formats like LZW, the above is not always true, depending on your CPU and disk speeds (and the PIL code contains a brand new decoder implementation that seems to be _very_ fast compared to most stuff out there). On the other hand, a well written server should of course be written in Python, and cache PIL Image objects internally! > Lib gd defines an interim file format that is basically a pure 24/32 > RGB bitmap with height/width information-- the file format is used > to greatly accelerate all operations by storing all of the interim > files in the generic format. One advantage of PIL is that you get a lot of file formats wrapped in a single architecture. So we don't need to invent a new file format, just use an appropriate existing one. For this purpose, I guess PPM would be a good candidate (and okay, PIL actually supports a distorted version of of Pbmplus to handle RGBA, CMYK, YCC, LAB, and whatever)... > It would be a horrible crime against the usability of the PIL to > have any aspect of the PIL depend on any piece of the Tk stuff... I wouldn't dare suggesting such a thing :-) Display support (currently not in 0.1) include Tk "photo image" and Windows DIB. General X support requires a good deal more hacking, but is far from impossible. And isn't there some X stuff in Jack's img library? > Has anyone checked out the San Diego SuperComputing Center's Image > Processing Library? It ROCKS! > > Seriously, it implements *all kinds* of really useful image processing > features-- including the ability to filter individual channels of > various colorspaces... a great tool. Interesting. For PIL, the current plan is to rely on the Numerical Python extension to provide stuff like FFT, convolutions, and lots of other things. Check the Matlab Image Toolkit for a good role model here. But simple, possibly file-based interfaces to stuff like the above library, imgStar, Khoros, XITE, and others, could be really useful. Thanks /F (Hey? Still no GIS/RS folks here?) ================= IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org ================= From bbum@friday.com Wed Mar 20 22:02:10 1996 From: bbum@friday.com (Bill Bumgarner) Date: Wed, 20 Mar 96 16:02:10 -0600 Subject: [PYTHON IMAGE-SIG] The PIL library -- specification for release 0.1 References: <9603201342.AA03736@arnold.image.ivab.se> Message-ID: <199603202202.QAA00453@wellington.friday.com> Looks awesome; a couple of pionts I would like to raise-- obviously, a = lot of this is certainly outside of the scope of the 0.1 release and is = not intended to be a complaint about lack of features. for TIFF: Sam Leffler's [sp.] libTIFF package reads and writes basically any format = of TIFF file imaginable-- including TIFF with JPEG compression through the = use of the IJG code. The licensing restrictions should be loose enough = for the purposes of the PIL and the library builds on basically anything = (as far as I know). =09 Complete information can be found here: =09 ftp://ftp.sgi.com/graphics/tiff =09 for GIF: The gd library by Tom Boutell provides a relatively complete ANSI = interface for manipulating GIF files. If I remember correctly, some kind = soul has already built a python module that wraps gd's functionality. = Regardless of how much code can be recycled from said module, the gd = library provides an excellent starting point for reading/writing GIF = images-- and it also includes the ability to manipulate the images in = interesting ways (which may be completely useless within PIL-- the API may = be such that it violates the ongoing feature set of the PIL. =09 Complete gd information can be found here (the server was down when I = tried to connect at about 3pm central standard time): =09 http://www.boutell.com/gd/ =09 interesting aside: Decoding and encoding the various image formats can be rather expensive. = For example, web sites that compose GIF images comprised of other GIF = images on the fly incur a massive penalty; every original image must be = decompressed, and the resulting image must then be compressed. Lib gd = defines an interim file format that is basically a pure 24/32 RGB bitmap = with height/width information-- the file format is used to greatly = accelerate all operations by storing all of the interim files in the = generic format. It is then very easy for the library to load and = manipulate these files without incurring the additional cost of = decompression.=20 =09 Sounds like something that might be very useful within the PIL. =09 windowing stuff: It would be a horrible crime against the usability of the PIL to have any = aspect of the PIL depend on any piece of the Tk stuff... hopefully, that = *fact* is obvious to everyone involved. If not, I will happily explain = *exactly* why this is true [in private email-- no need to trash the list] = to anyone who disagrees... =09 Yes, i'm a bit religious about this issue-- but that's because I wish to = ensure that I can use the image processing module on *any* of the = multitude of platforms I regularly use. =09 other image processing libraries: Has anyone checked out the San Diego SuperComputing Center's Image = Processing Library? It ROCKS! =09 Seriously, it implements *all kinds* of really useful image processing = features-- including the ability to filter individual channels of various = colorspaces... a great tool. =09 ftp://ftp.sdsc.edu/pub/sdsc/graphics/imtools hope SOME of this information is useful to SOMEONE,=09 b.bum= ================= 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 Mar 21 15:30:22 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 21 Mar 1996 16:30:22 +0100 Subject: [PYTHON IMAGE-SIG] The PIL library -- specification for release 0.1 In-Reply-To: Message by Fredrik Lundh , Thu, 21 Mar 1996 08:38:40 +0100 , <9603210738.AA21132@arnold.image.ivab.se> Message-ID: <9603211530.AA21364=jack@schelvis.cwi.nl> I think we should try to integrate the functionality of img and the functionality of pil. The parts of img that I am rather fond of are: - the imgformat specifiers, which tell you everything about the incore image and pixel format (pixel type, #components, bits/component, row stride, orientation, etc) in a handy form - the stackability of readers/converters, which allows the package to automatically convert an image to a format that is handy to your program for displaying or manipulating. -- 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 bbum@friday.com Thu Mar 21 18:15:18 1996 From: bbum@friday.com (Bill Bumgarner) Date: Thu, 21 Mar 96 12:15:18 -0600 Subject: [PYTHON IMAGE-SIG] The PIL library -- specification for release 0.1 In-Reply-To: <9603210806.AA09433@arnold.image.ivab.se> References: <9603210806.AA09433@arnold.image.ivab.se> Message-ID: <199603211815.MAA03783@wellington.friday.com> two more points: 1) Because, obviously, fully optimized ANSI C will always be faster than = python for execution of tight calculation loops and such-- and, of course, = tight calculation loops are the nuts and bolts of image processing, it = would be *extremely useful* to have a C API that is *even easier to use* = than the pre-existing python C API for building image processing modules. I'm thinking of something that allows one to basically build filter = function of a given API-- that API would include the buffer to be = processed [and, potentially, an output buffer if the image is to NOT be = processed in place] and some kind of a structure containing any = configuration information as propagated by the python object set. Now-- why would it be desirable to create Yet Another API? Well; two = reasons-- the first is that image processing [actually, data processing = in general-- there is little reason why a similar framework could not be = used for, say, video processing or audio processing] is a specialized set = of problems that require a relatively specialized set of tools. By = creating a Highly Refined API for building data processing tools, we yield = an environment in which the developer with lots of experience creating = image processing tools-- but little experience with general programming-- = can effectively utilize the environment to greatly augment their toolbox. The second reason is that the existing Python API-- while relatively easy = to use for the EXPERIENCED developer-- is too large and confusing for most = developer's to effectively use. Seriously; I have had *lots* of = experience developing OO software (over 10 years now) and there are two = basic development paths [wow, the quantity 2 seems to recurr throughout = this message]; the first is the easy path-- using existing Objects to = create whole new frameworks for doing useful things (typically, by = creating a class that inherits from the root class-- this class acts as a = framework controller). The second is much more difficult-- it involves = creating new classes and extending exisiting classes to provide an object = framework that is *designed for the use of a developer*... the second is = more difficult because the behaviour has to be well defined at the object = level, not just at the UI level (yes, yes, I know-- UI level behaviour CAN = be difficult; but minor problems don't necessarily mean catastrophic = failure...). Python's existing extension API, while being relatively well written and = designed, is definitely an API for *use by other hardcore developer's* and = not for consumption by the inexperienced masses. =20 If we were to create a PIL ANSI Extension API, there is no reason why the = developer cannot continue to use the existing Python API-- if so = inclined-- but I see *a lot* of advantages to providing the lay-developer = with an easy to use ANSI API that allows them to develop powerful data = processing tools while removing *a large quantity* of rope with which to = hang themselves. 2) in regards to Leffler's libTIFF; i strongly disagree that a desirable = solution would be to pull the useful decoding bits from Leffler's library = and just use those. This would incur MASSIVE down-the-road maintenance = penalties-- every time Leffler releases a new version, the bits and pieces = would have to be sucked from his code and integrated into the PIL... = potentially hours of tedium per release with no real gain in the feature = set (beyond the bug fixes provided by leffler). By using his library directly-- ie; by linking (either dynamically or not) = the python binary against libtiff and then implementing PIL on top of the = additional API, we garner an environment that leverages all of the power = of libtiff without reworking it. =20 Same goes for libjpeg [and libpng, if the png folks ever achieve a level = of refinenment that doesn't require one to replace pieces of their code = with per-platform code-- i think they have]. --- BTW: I am Master of Data Decoding [mostly images, though it looks like = sound and video will fall in my lap, as well] for a web browser targeted = at the NEXTSTEP/OPENSTEP markets. I have been down all three paths of = using third party image processing software; roll my own [GIF], integrate = the useful bits of other's work [PNG], and simply leveraging off existing = packages [TIFF, JPEG] -- the leveraging off of other's has really paid off = [jpeg recently moved from version 5 to version 6-- my image decoder = magically recognized all the new features of JPEG by simply re-linking; i = didn't have to change *any* of my code!]. b.bum= ================= 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 Mar 21 21:18:05 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 21 Mar 1996 22:18:05 +0100 Subject: [PYTHON IMAGE-SIG] The PIL library -- specification for release 0.1 In-Reply-To: <199603211815.MAA03783@wellington.friday.com> (message from Bill Bumgarner on Thu, 21 Mar 96 12:15:18 -0600) Message-ID: <9603212118.AA21325@arnold.image.ivab.se> Bill Bumgarner wrote: > 2) in regards to Leffler's libTIFF; i strongly disagree that a > desirable solution would be to pull the useful decoding bits from > Leffler's library and just use those. This would incur MASSIVE > down-the-road maintenance penalties-- every time Leffler releases a > new version, the bits and pieces would have to be sucked from his > code and integrated into the PIL... potentially hours of tedium per > release with no real gain in the feature set (beyond the bug fixes > provided by leffler). Hmm. I don't really agree here... Just a few comments: 1. PIL 0.1 already include TIFF/LZW, Packbits, and JPEG decoders. I have a Huffman decoder up my sleave, so what's left is Group 3/4 and ZIP/Deflate (for which the specs are still changing). 2. We'll need good Group 3/4 codecs anyway to handle formats like SPIFF, CALS, IIF, BIIF, NITF, etc... 3. A lean and mean distribution is worth a lot. If I can replace 4000 lines of C with 200 lines of Python, I'll do it... This is not to say that someone else couldn't provide a libtiff interface for PIL, just that I will not place it too high on _my_ list. There's simply to much else to do, like getting the first release out of the door (I'm working on it right now :-) /F ================= IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org ================= From image-sig@python.org Thu Mar 28 07:27:35 1996 From: image-sig@python.org (Fredrik Lundh) Date: Thu, 28 Mar 1996 08:27:35 +0100 Subject: [PYTHON IMAGE-SIG] Announcing the Python Imaging Library, release 0.0 Message-ID: <9603280727.AA19093@arnold.image.ivab.se> Hi, Suddently became more busy than usual, so I wasn't able to put the full 0.1 release together last weekend as promised. However, by leaving out some portions of the library, I did prepare an even smaller release last Sunday. Unfortunately, the python.org server is currently being reorganized, so it took quite a while to sort things out and upload the stuff safely. Anyway, you can now download this first experimental release from: http://www.python.org/sigs/imaging-sig/Imaging-0.0.tar.gz A few notes and caveats: + The main idea behind this release is to test portability and the build procedure. But all comments are of course welcome. + There's no documentation, except for a README in the distribution (which is attached, see below before you try to unpack the release). To get a grip on the Image class, see the method doc strings and the sample code in the test scripts. + The ImageIO module is not included; you can only read and write PPM files with this release. + There's no built-in display support. There's a mechanism that may allow you to use Jack Jansen's 'img' library for display purposes, but that has not been tested yet. + To run the test scripts, you need 'xv'. + Don't miss the ImageEnhance module (run the test_enhance.py script) Send any comments, bug reports, or flames to 'image-sig@python.org'. /F -------------------------------------------------------------------- $Id: README,v 1.1 1996/03/25 08:46:34 fredrik Exp $ Release 0.0 (March 24, 1996) *** The Python Imaging Library *** This prerelease is made mainly to check installation on different platforms, and to give developers and other interested parties access to the Imaging core library. This release contains most of the stuff planned for release 0.1, with the exception of the ImageIO codecs, documentation, and some minor functionality. For installation and licensing details, see below. For questions, comments and bug reports, send mail to 'image-sig@python.org'. *** Build instructions (Unix) 1. Unpack the PIL distribution (the file Imaging-0.0.tar.gz) in your Python directory. $ cd Python-1.3 (example) $ gunzip Imaging-0.0.tar.gz $ tar xvf Imaging-0.0.tar 2. Go to the Imaging subdirectory that was created in your Python directory when you unpacked the distribution. Type: $ ./configure $ make 3. To check that this library works as it should, type: $ make check 4. Go to the Modules subdirectory in your Python directory. Copy the following text to the end of the Setup file (or Setup.in, if you haven't already built the interpreter): _imaging _imagingmodule.c -I../Imaging -L../Imaging -lImaging 5. Build the Python interpreter as usual. 6. In the Imaging subdirectory, type (assuming you linked the module statically): $ ../python >>> import Image If this works, you've successfully added PIL to your Python environment. There's a few test/demo scripts in the Imaging directory that you can use to test the library. 7. To install the PIL Python library modules, copy the files named "Image*.py" and "*ImagePlugin.py" from the Imaging library to your Python library directory. The following command will do: $ cp Imaging/*Image*.py /usr/local/lib/python *** Software License (The following is a slightly modified version of the standard Python license. The exception is that you cannot use the C portions of the library outside a Python environment without my permission. But as long as you use with a Python interpreter, you can do anything with the library, except blaming me if it doesn't work as you expect :-) The Python Imaging Library is copyright (c) 1995-96 Fredrik Lundh. All rights reserved. Permission to use, copy, modify, and distribute this Python software and its associated documentation for any purpose (subject to the restriction in the following sentence) without fee is hereby granted, provided that the above copyright notice appears in all copies, and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of the author not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. This permission is explicitly restricted to the copying and modification of the software to be exclusively used with a Python interpreter. THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -------------------------------------------------------------------- ================= IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org ================= From image-sig@python.org Thu Mar 28 07:27:35 1996 From: image-sig@python.org (Fredrik Lundh) Date: Thu, 28 Mar 1996 08:27:35 +0100 Subject: [PYTHON IMAGE-SIG] Announcing the Python Imaging Library, release 0.0 Message-ID: <9603280727.AA19093@arnold.image.ivab.se> Hi, Suddently became more busy than usual, so I wasn't able to put the full 0.1 release together last weekend as promised. However, by leaving out some portions of the library, I did prepare an even smaller release last Sunday. Unfortunately, the python.org server is currently being reorganized, so it took quite a while to sort things out and upload the stuff safely. Anyway, you can now download this first experimental release from: http://www.python.org/sigs/imaging-sig/Imaging-0.0.tar.gz A few notes and caveats: + The main idea behind this release is to test portability and the build procedure. But all comments are of course welcome. + There's no documentation, except for a README in the distribution (which is attached, see below before you try to unpack the release). To get a grip on the Image class, see the method doc strings and the sample code in the test scripts. + The ImageIO module is not included; you can only read and write PPM files with this release. + There's no built-in display support. There's a mechanism that may allow you to use Jack Jansen's 'img' library for display purposes, but that has not been tested yet. + To run the test scripts, you need 'xv'. + Don't miss the ImageEnhance module (run the test_enhance.py script) Send any comments, bug reports, or flames to 'image-sig@python.org'. /F -------------------------------------------------------------------- $Id: README,v 1.1 1996/03/25 08:46:34 fredrik Exp $ Release 0.0 (March 24, 1996) *** The Python Imaging Library *** This prerelease is made mainly to check installation on different platforms, and to give developers and other interested parties access to the Imaging core library. This release contains most of the stuff planned for release 0.1, with the exception of the ImageIO codecs, documentation, and some minor functionality. For installation and licensing details, see below. For questions, comments and bug reports, send mail to 'image-sig@python.org'. *** Build instructions (Unix) 1. Unpack the PIL distribution (the file Imaging-0.0.tar.gz) in your Python directory. $ cd Python-1.3 (example) $ gunzip Imaging-0.0.tar.gz $ tar xvf Imaging-0.0.tar 2. Go to the Imaging subdirectory that was created in your Python directory when you unpacked the distribution. Type: $ ./configure $ make 3. To check that this library works as it should, type: $ make check 4. Go to the Modules subdirectory in your Python directory. Copy the following text to the end of the Setup file (or Setup.in, if you haven't already built the interpreter): _imaging _imagingmodule.c -I../Imaging -L../Imaging -lImaging 5. Build the Python interpreter as usual. 6. In the Imaging subdirectory, type (assuming you linked the module statically): $ ../python >>> import Image If this works, you've successfully added PIL to your Python environment. There's a few test/demo scripts in the Imaging directory that you can use to test the library. 7. To install the PIL Python library modules, copy the files named "Image*.py" and "*ImagePlugin.py" from the Imaging library to your Python library directory. The following command will do: $ cp Imaging/*Image*.py /usr/local/lib/python *** Software License (The following is a slightly modified version of the standard Python license. The exception is that you cannot use the C portions of the library outside a Python environment without my permission. But as long as you use with a Python interpreter, you can do anything with the library, except blaming me if it doesn't work as you expect :-) The Python Imaging Library is copyright (c) 1995-96 Fredrik Lundh. All rights reserved. Permission to use, copy, modify, and distribute this Python software and its associated documentation for any purpose (subject to the restriction in the following sentence) without fee is hereby granted, provided that the above copyright notice appears in all copies, and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of the author not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. This permission is explicitly restricted to the copying and modification of the software to be exclusively used with a Python interpreter. THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. -------------------------------------------------------------------- ================= 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 Mar 28 12:18:44 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 28 Mar 1996 13:18:44 +0100 Subject: [PYTHON IMAGE-SIG] Announcing the Python Imaging Library, release 0.0 In-Reply-To: Message by Fredrik Lundh , Thu, 28 Mar 1996 08:27:35 +0100 , <9603280727.AA19093@arnold.image.ivab.se> Message-ID: <9603281218.AA03249=jack@schelvis.cwi.nl> Fredrik, wonderful, it builds out of the box! I've reorganized the stuff a little, to conform the Guido's Extension architecture (which makes it a lot easier to keep multi-platform pythons, and keeps extensions separate from the core python), shall I pack it up and send it back? Off to try and make it work together with img, -- 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 fredrik_lundh@ivab.se Thu Mar 28 13:31:08 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 28 Mar 1996 14:31:08 +0100 Subject: [PYTHON IMAGE-SIG] Announcing the Python Imaging Library Handbook! Message-ID: <9603281331.AA29934@arnold.image.ivab.se> To keep you folks busy, I've uploaded a draft version of the PIL Handbook (written for the forthcoming 0.1 release) to python.org. As soon as their ftpmaster has checked it and moved it to the appropriate place, you should be able to download it from: http://www.python.org/sigs/imaging-sig/Imaging-0.1-handbook-draft.ps.gz It's some 25 pages, formatted for A4, but hopefully prints fine on letter paper as well. Text and/or HTML versions will be made available later. As always, all comments are welcome. /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 Mar 28 14:21:42 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 28 Mar 1996 15:21:42 +0100 Subject: [PYTHON IMAGE-SIG] Announcing the Python Imaging Library and Handbook. New URL!(?) In-Reply-To: <9603281331.AA29934@arnold.image.ivab.se> (message from Fredrik Lundh on Thu, 28 Mar 1996 14:31:08 +0100) Message-ID: <9603281421.AA26824@arnold.image.ivab.se> Look like I messed things up in my earlier postings. The correct URLs should be: http://www.python.org/sigs/image-sig/Imaging-0.0.tar.gz http://www.python.org/sigs/image-sig/Imaging-0.1-handbook-draft.ps.gz ^^^^^ and nothing else. Sorry for the inconvenience. Wonder where Jack found his copy? /F ================= 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 Mar 28 15:05:38 1996 From: Jack.Jansen@cwi.nl (Jack Jansen) Date: Thu, 28 Mar 1996 16:05:38 +0100 Subject: [PYTHON IMAGE-SIG] Announcing an img<->PIL bridge. In-Reply-To: Message by Fredrik Lundh , Thu, 28 Mar 1996 14:31:08 +0100 , <9603281331.AA29934@arnold.image.ivab.se> Message-ID: <9603281505.AA04437=jack@schelvis.cwi.nl> Hmm, I guess that I can pat both Fredrik and myself on the shoulder for writing Well Designed Extensions: despite the pretty different architecture of PIL and img I've written a bridge module in just a few hours. This module, in the form of a PIL plugin, will allow you to use PIL with files in any format supported by img: GIF, TIFF, JPEG, SGI and the Pbm formats currently. For the time being the module will only read files (since I didn't understand how the plugin architecture works for writing. Fredrik?). Also, GIF files are converted to RGB, not colormapped PIL images (since I didn't understand what a PIL colormap looks like. Fredrik?). You can download it from directory . One caveat: I've tested it only with my current img, which should be almost identical to the img12fc1 distribution in that directory (the old img distribution won't work). Let me know if it doesn't work for you and I'll put together a new one. -- 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 guido@CNRI.Reston.VA.US Thu Mar 28 15:24:14 1996 From: guido@CNRI.Reston.VA.US (Guido van Rossum) Date: Thu, 28 Mar 1996 10:24:14 -0500 Subject: [PYTHON IMAGE-SIG] Announcing the Python Imaging Library Handbook! In-Reply-To: Your message of "Thu, 28 Mar 1996 14:31:08 +0100." <9603281331.AA29934@arnold.image.ivab.se> References: <9603281331.AA29934@arnold.image.ivab.se> Message-ID: <199603281524.KAA22231@monty> > http://www.python.org/sigs/imaging-sig/Imaging-0.1-handbook-draft.ps.gz Surely you meant http://www.python.org/sigs/image-sig/Imaging-0.1-handbook-draft.ps.gz I've put it there now. I can't edit the index.html file so Ken will have to do that. --Guido van Rossum URL: ================= 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 Mar 28 21:08:31 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 28 Mar 1996 22:08:31 +0100 Subject: [PYTHON IMAGE-SIG] How to write image files from an ImagePlugin In-Reply-To: <9603281505.AA04437=jack@schelvis.cwi.nl> (message from Jack Jansen on Thu, 28 Mar 1996 16:05:38 +0100) Message-ID: <9603282108.AA27070@arnold.image.ivab.se> > For the time being the module will only read files (since I didn't > understand how the plugin architecture works for writing. Fredrik?). Quite simple, actually. The _save function is called with an Image object, an opened file handle, and a filename. Your plugin should write the image to the file indicated by filename (or to the file handle, if that suits you better). But to make this work with the save method in the Image class, you need to register your driver. The following does this for the PPM driver: Image.register_save("PBM", _save) Image.register_extension("PBM", ".pbm") Image.register_extension("PBM", ".pgm") Image.register_extension("PBM", ".ppm") This means that we register a save handler named "PBM", and associates the extensions pbm, pgm, and ppm with this driver. Since you can handle multiple file formats with the Img driver, you have to extend this scheme to be able to figure out what the user really wants. 1. Create one save handler for each file format you can handle. It may be practical to let all these call a common routine that does the actual work. def _save_tiff(im, fp, filename): _save(im, fp, filename, "TIFF") def _save_sgi(im, fp, filename): _save(im, fp, filename, "SGI") 2. Register these handlers under unique names: Image.register_save("TIFF", _save_tiff) Image.register_save("SGI", _save_sgi) 3. Register the appropriate extensions (see the handbook for the full set of extensions for tiff and jpeg files), to allow a user to give only a filename when saving a file: Image.register_extension("TIFF", ".tif") Image.register_extension("TIFF", ".tiff") Image.register_extension("SGI", ".sgi") Image.register_extension("SGI", ".rgb") If a format is not explicitly given to the save method, PIL uses the extension table to determine which format to use. There's currently no mechanism to mediate between different drivers that claims to be handling the same file format. Last one loaded will override the others. Not really sure how to address this... BTW, I've renamed the ImgImagePlugin.py to ImgExtImagePlugin.py since there happens to be a file format named img as well... Might need to add some additional naming conventions for extensions other than file formats, but let's leave that for another day. /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 Mar 28 21:15:13 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 28 Mar 1996 22:15:13 +0100 Subject: [PYTHON IMAGE-SIG] How to write image files from an ImagePlugin (part 2) In-Reply-To: <9603281505.AA04437=jack@schelvis.cwi.nl> (message from Jack Jansen on Thu, 28 Mar 1996 16:05:38 +0100) Message-ID: <9603282115.AA04424@arnold.image.ivab.se> And as a demonstration, here's an alternative JPEG driver that uses the command line utilities provided with the IJG JPEG library to read and write files, using the built-in PPM support. Also note that this driver delays the loading of images by defining its own load method. Similar techniques (possibly with a less complex parser :-) could be used to quickly interface whatever file format you happen to have PPM converters for. And of course, the hack portions of this driver will be replaced with a call to a builtin codec in forthcoming releases. /F -------------------------------------------------------------------- # $Id: JpegImagePlugin.py,v 1.1 1996/03/26 07:22:40 fredrik Exp $ # # The Python Imaging Library. # # File: # JpegImagePlugin.py -- JPEG (JFIF) file handling # # History: # 95-09-09 fl Created # 95-09-13 fl Added full parser # 96-03-25 fl Added hack to use the IJG command line utilities # # Literature: # "Digital Compression and Coding of Continous-Tone # Still Images, Part 1, Requirements and Guidelines" # (CCITT T.81 / ISO 10918-1) # # Copyright (c) Fredrik Lundh 1995-96. All rights reserved. # __version__ = "0.1" import array, string import Image, ImageFile def i16(c): return ord(c[1]) + (ord(c[0])<<8) def i32(c): return ord(c[3]) + (ord(c[2])<<8) + (ord(c[1])<<16) + (ord(c[0])<<24) # # Parser def Skip(self, marker): self.fp.read(i16(self.fp.read(2))-2) def APP(self, marker): # # Application marker. Store these in the APP dictionary. # Also look for well-known application markers. s = self.fp.read(i16(self.fp.read(2))-2) self.app["APP%d" % (marker&15)] = s if marker == 0xFFE0 and s[:4] == "JFIF": self.info["jfif"] = 1 def SOF(self, marker): # # Start of frame marker. Defines the size and mode of the # image. JPEG is colour blind, so we use some simple # heuristics to map the number of layers to an appropriate # mode. Note that this could be made a bit brighter, by # looking for JFIF and Adobe APP markers. s = self.fp.read(i16(self.fp.read(2))-2) self.size = i16(s[3:]), i16(s[1:]) self.bits = ord(s[0]) if self.bits != 8: raise SyntaxError, "cannot handle %d-bit layers" % self.bits self.layers = ord(s[5]) if self.layers == 1: self.mode = "L" elif self.layers == 3: self.mode = "RGB" elif self.layers == 4: self.mode = "CMYK" else: raise SyntaxError, "cannot handle %d-layer images" % self.layers for i in range(6, len(s), 3): t = s[i:i+3] # 4-tuples: id, vsamp, hsamp, qtable self.layer.append(t[0], ord(t[1])/16, ord(t[1])&15, ord(t[2])) def DQT(self, marker): # # Define quantization table. Support baseline 8-bit tables # only. Note that there might be more than one table in # each marker. # The quantization tables can be used to estimate the # compression quality. s = self.fp.read(i16(self.fp.read(2))-2) while len(s): if len(s) < 65: raise SyntaxError, "bad quantization table marker" v = ord(s[0]) if v/16 == 0: self.quantization[v&15] = array.array("b", s[1:65]) s = s[65:] else: pass # raise SyntaxError, "bad quantization table element size" # # JPEG marker table MARKER = { 0xFFC0: ("SOF0", "Baseline DCT", SOF), 0xFFC1: ("SOF1", "Extended Sequential DCT", SOF), 0xFFC2: ("SOF2", "Progressive DCT", SOF), 0xFFC3: ("SOF3", "Spatial lossless", SOF), 0xFFC4: ("DHT", "Define Huffman table", Skip), 0xFFC5: ("SOF5", "Differential sequential DCT", SOF), 0xFFC6: ("SOF6", "Differential progressive DCT", SOF), 0xFFC7: ("SOF7", "Differential spatial", SOF), 0xFFC8: ("JPG", "Extension", None), 0xFFC9: ("SOF9", "Extended sequential DCT (AC)", SOF), 0xFFCA: ("SOF10", "Progressive DCT (AC)", SOF), 0xFFCB: ("SOF11", "Spatial lossless DCT (AC)", SOF), 0xFFCC: ("DAC", "Define arithmetic coding conditioning", Skip), 0xFFCD: ("SOF13", "Differential sequential DCT (AC)", SOF), 0xFFCE: ("SOF14", "Differential progressive DCT (AC)", SOF), 0xFFCF: ("SOF15", "Differential spatial (AC)", SOF), 0xFFD0: ("RST0", "Restart 0", None), 0xFFD1: ("RST1", "Restart 1", None), 0xFFD2: ("RST2", "Restart 2", None), 0xFFD3: ("RST3", "Restart 3", None), 0xFFD4: ("RST4", "Restart 4", None), 0xFFD5: ("RST5", "Restart 5", None), 0xFFD6: ("RST6", "Restart 6", None), 0xFFD7: ("RST7", "Restart 7", None), 0xFFD8: ("SOI", "Start of image", None), 0xFFD9: ("EOI", "End of image", None), 0xFFDA: ("SOS", "Start of scan", Skip), 0xFFDB: ("DQT", "Define quantization table", DQT), 0xFFDC: ("DNL", "Define number of lines", Skip), 0xFFDD: ("DRI", "Define restart interval", Skip), 0xFFDE: ("DHP", "Define hierarchical progression", SOF), 0xFFDF: ("EXP", "Expand reference component", Skip), 0xFFE0: ("APP0", "Application segment 0", APP), 0xFFE1: ("APP1", "Application segment 1", APP), 0xFFE2: ("APP2", "Application segment 2", APP), 0xFFE3: ("APP3", "Application segment 3", APP), 0xFFE4: ("APP4", "Application segment 4", APP), 0xFFE5: ("APP5", "Application segment 5", APP), 0xFFE6: ("APP6", "Application segment 6", APP), 0xFFE7: ("APP7", "Application segment 7", APP), 0xFFE8: ("APP8", "Application segment 8", APP), 0xFFE9: ("APP9", "Application segment 9", APP), 0xFFEA: ("APP10", "Application segment 10", APP), 0xFFEB: ("APP11", "Application segment 11", APP), 0xFFEC: ("APP12", "Application segment 12", APP), 0xFFED: ("APP13", "Application segment 13", APP), 0xFFEE: ("APP14", "Application segment 14", APP), 0xFFEF: ("APP15", "Application segment 15", APP), 0xFFF0: ("JPG0", "Extension 0", None), 0xFFF1: ("JPG1", "Extension 1", None), 0xFFF2: ("JPG2", "Extension 2", None), 0xFFF3: ("JPG3", "Extension 3", None), 0xFFF4: ("JPG4", "Extension 4", None), 0xFFF5: ("JPG5", "Extension 5", None), 0xFFF6: ("JPG6", "Extension 6", None), 0xFFF7: ("JPG7", "Extension 7", None), 0xFFF8: ("JPG8", "Extension 8", None), 0xFFF9: ("JPG9", "Extension 9", None), 0xFFFA: ("JPG10", "Extension 10", None), 0xFFFB: ("JPG11", "Extension 11", None), 0xFFFC: ("JPG12", "Extension 12", None), 0xFFFD: ("JPG13", "Extension 13", None), 0xFFFE: ("COM", "Comment", Skip) } class JpegImageFile(ImageFile.ImageFile): format = "JPEG" format_description = "JPEG (ISO 10918)" def _open(self): s = self.fp.read(1) if ord(s[0]) != 255: raise SyntaxError, "not an JPEG file" # Create attributes self.bits = self.layers = 0 # JPEG specifics (internal) self.layer = [] self.huffman_dc = {} self.huffman_ac = {} self.quantization = {} self.app = {} while 1: s = s + self.fp.read(1) i = i16(s) if MARKER.has_key(i): name, description, handler = MARKER[i] # print hex(i), name, description if handler != None: handler(self, i) if i == 0xFFDA: self.tile = [("jpeg", (0,0) + self.size, 0, None)] # self.offset = self.fp.tell() break s = self.fp.read(1) else: raise SyntaxError, "no marker found" def load(self): # ------------------------------------------------------------ # Hack to handle JPEGs via the IJG command line utilities by # overloading the default load handler. import tempfile, os, _imaging file = tempfile.mktemp() os.system("djpeg %s >%s" % (self.filename, file)) try: self.im = _imaging.open_ppm(file) finally: try: os.unlink(file) except: pass self.mode = self.im.mode self.size = self.im.size self.tile = [] def _save(im, fp, filename): import os file = im._dump() os.system("cjpeg %s >%s" % (file, filename)) try: os.unlink(file) except: pass # End of JPEG hack # -------------------------------------------------------------------- Image.register_open(JpegImageFile.format, JpegImageFile) Image.register_save(JpegImageFile.format, _save) Image.register_extension(JpegImageFile.format, ".jfif") Image.register_extension(JpegImageFile.format, ".jpe") Image.register_extension(JpegImageFile.format, ".jpg") Image.register_extension(JpegImageFile.format, ".jpeg") ================= 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 Mar 28 21:18:00 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 28 Mar 1996 22:18:00 +0100 Subject: [PYTHON IMAGE-SIG] Announcing an img<->PIL bridge. In-Reply-To: <9603281505.AA04437=jack@schelvis.cwi.nl> (message from Jack Jansen on Thu, 28 Mar 1996 16:05:38 +0100) Message-ID: <9603282118.AA32684@arnold.image.ivab.se> Jack wrote: > Also, GIF files are converted to RGB, not colormapped PIL images > (since I didn't understand what a PIL colormap looks > like. Fredrik?). Neither do I :-) Palette support was one of the things I boldly ripped out of the library in order to create the 0.0 release. Since I only intended to support PGM/PPM files, I didn't see this as much of a problem... I'll address this in the next release, I promise. /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 Mar 28 23:50:21 1996 From: MHammond@skippinet.com.au (Mark Hammond) Date: Fri, 29 Mar 1996 09:50:21 +1000 Subject: [PYTHON IMAGE-SIG] Announcing the Python Imaging Library, r Message-ID: <199603282249.IAA22537@minotaur.labyrinth.net.au> > + To run the test scripts, you need 'xv'. I realise we are talking 0.1, but is it worth me looking at this for Pythonwin support yet? Mark. ---------------------------------------- Mark Hammond - MHammond@skippinet.com.au ================= 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 Mar 28 22:57:56 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 28 Mar 1996 23:57:56 +0100 Subject: [PYTHON IMAGE-SIG] Announcing the Python Imaging Library, r In-Reply-To: <199603282249.IAA22537@minotaur.labyrinth.net.au> (MHammond@skippinet.com.au) Message-ID: <9603282257.AA07474@arnold.image.ivab.se> > I realise we are talking 0.1, but is it worth me looking at this for > Pythonwin support yet? It's 0.0, actually :-) You can always take a peek at it to see if it would be any problems building a PYD. However, the DIB stuff is not yet included (I can mail it to you if you wish; was a while since I tested it though). What's left is some proper way to get hold of an HDC, and also some way to handle the palette issues on 8-bit displays. /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 Mar 28 22:57:56 1996 From: fredrik_lundh@ivab.se (Fredrik Lundh) Date: Thu, 28 Mar 1996 23:57:56 +0100 Subject: [PYTHON IMAGE-SIG] Announcing the Python Imaging Library, r In-Reply-To: <199603282249.IAA22537@minotaur.labyrinth.net.au> (MHammond@skippinet.com.au) Message-ID: <9603282257.AA07474@arnold.image.ivab.se> > I realise we are talking 0.1, but is it worth me looking at this for > Pythonwin support yet? It's 0.0, actually :-) You can always take a peek at it to see if it would be any problems building a PYD. However, the DIB stuff is not yet included (I can mail it to you if you wish; was a while since I tested it though). What's left is some proper way to get hold of an HDC, and also some way to handle the palette issues on 8-bit displays. /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 Fri Mar 29 00:12:23 1996 From: MHammond@skippinet.com.au (Mark Hammond) Date: Fri, 29 Mar 1996 10:12:23 +1000 Subject: [PYTHON IMAGE-SIG] Announcing the Python Imaging Librar Message-ID: <199603282311.JAA22976@minotaur.labyrinth.net.au> > However, the DIB stuff is not yet included (I can mail it to you if > you wish; was a while since I tested it though). What's left is some > proper way to get hold of an HDC, and also some way to handle the > palette issues on 8-bit displays. HDC is no problem. Will there be any palette support in the toolkit? If not, I may be able to chase some up... But I can run 16mil colors, so I may have a play... Mark. ---------------------------------------- Mark Hammond - MHammond@skippinet.com.au ================= IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org ================= From carlosm@anchor.cs.colorado.edu Sun Mar 31 23:59:32 1996 From: carlosm@anchor.cs.colorado.edu (Carlos Maltzahn) Date: Sun, 31 Mar 1996 16:59:32 -0700 (MST) Subject: [PYTHON IMAGE-SIG] image streams? Message-ID: <199603312359.QAA05765@anchor.cs.colorado.edu> I wonder whether anybody is writing Python library routines for image streams. This could be useful for bandwidth efficient realtime animation over the Web, for example. Carlos ================= IMAGE-SIG - SIG on Image Processing with Python send messages to: image-sig@python.org administrivia to: image-sig-request@python.org =================