From Dirk.Engelmann@IWR.Uni-Heidelberg.De Sat May 1 10:44:16 1999 From: Dirk.Engelmann@IWR.Uni-Heidelberg.De (Dirk Engelmann) Date: Sat, 1 May 1999 11:44:16 +0200 (CEST) Subject: [Image-SIG] graphics for Python 1.2 In-Reply-To: <3.0.32.19990430101446.00698768@tin2.cad.ornl.gov> Message-ID: On Fri, 30 Apr 1999, Juan Ferrada wrote: > The only problem we have is that when we go from the FLOW graphic interface > and want to interact with the user and ask them some question, for example > what is the input pressure of your bomb? or what is the diameter of your > tank? we go to the traditional black screen of the DOS environment. We > would like to improve this by putting, for example, the figure of a pump > and show the user the question directly on the graphic. Are you talking about dialog boxes and simliar things ? Tkinter is a python module and does things like this - more sophisticated and well structured is the pmw package based on tkinter (runs on Linux, Windows and Mac I think). Anyway I propose to upgrade python - meanwhile Version 1.5 is stabel and many addons rely on newer version. Regards, Dirk Engelmann From fredrik@pythonware.com Sat May 1 13:52:15 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Sat, 1 May 1999 14:52:15 +0200 Subject: [Image-SIG] When will the next PIL beta be released? References: <001a01be8fbf$1f9ab270$060110ac@private> Message-ID: <005701be93d1$712f3640$f29b12c2@pythonware.com> > What progress has been made to release another kit? new faster font code, lots of minor bug fixes, easier Tk integration, and more. > What is are your current plans for PIL? final 1.0 release around may 15, most likely a last release candidate a few days before that. assuming everything goes according to plans, that is. Cheers /F From herzog@online.de Tue May 4 12:57:03 1999 From: herzog@online.de (Bernhard Herzog) Date: 04 May 1999 13:57:03 +0200 Subject: [Image-SIG] PIL Installation Instructions and end-users Message-ID: In the May issue of the Linux Gazette, the Graphics Muse examines vector drawing programs for Linux. Unfortunately the author wasn't able to install Sketch because he had problems with intalling PIL and finally gave up: Sketch requires Python v1.5.1 or later, the Python Imaging Library, v1.0b1 and Tcl/TK, version 8.0 or later. To build the Python Imaging Library (aka PIL) you can't use the RPM version of Python - you have to build the python distribution from source and install it. This is because you have to build PIL under the "Extensions" directory of the Python 1.5 directories. Although I have Python 1.5 installed on my stock RH 5.2 box, there is no Extensions directory. Plus, if I just made the directory where 1.5 is installed (/usr/lib/python1.5), I'd have to build the PIL as the root user. Not a good thing. So I downloaded the Python 1.5 source, built it, then tried the PIL buid. It didn't work - something about missing a config directory. And all this before I could even try to build sketch. An experienced Python/PIL user knows that you don't have build PIL in the Python source directory and that the missing config files are probably in the python-devel rpm, but an end user who just wants to install a drawing program and doesn't care about Python or programming in general (yet, wait till they discover user scripting... :) ) will have problems similar to this, I think. It seems to me that these problems are mostly due to misleading statements in PIL's README, e.g.: 2. Unpack the PIL distribution (the file Imaging-1.0b1.tar.gz) in your Python/Extensions directory. I therefore propose these changes to the README to make installing PIL easier: --- README.~1~ Sat Jan 9 20:58:34 1999 +++ README Tue May 4 13:31:09 1999 @@ -131,8 +131,9 @@ the operating system should work just fine. -2. Unpack the PIL distribution (the file Imaging-1.0b1.tar.gz) in your - Python/Extensions directory. +2. Unpack the PIL distribution (the file Imaging-1.0b1.tar.gz). If you + have the Python sources, your Python/Extensions directory may be a + good place, but you can build PIL anywhere you like. $ cd Python-1.5/Extensions # example $ gunzip Imaging-1.0b1.tar.gz @@ -196,13 +197,17 @@ If you're using Python 1.5 or later, the preferred way is to create a "PIL" subdirectory under "site-packages", copy the "PIL.pth" file to "site-packages", and the rest of the files to the new subdirectory. + If the "site-packages" directory doesn't exist yet create it under + Python's lib directory (usually /usr/local/lib/python1.5 or + /usr/lib/python1.5) Example: - $ cp PIL.pth /usr/local/lib/Python1.5/site-packages - $ mkdir /usr/local/lib/Python1.5/site-packages/PIL - $ cp _imaging.so PIL/* /usr/local/lib/Python1.5/site-packages/PIL - + $ cp PIL.pth /usr/local/lib/python1.5/site-packages + $ mkdir /usr/local/lib/python1.5/site-packages/PIL + $ cp _imaging.so PIL/* /usr/local/lib/python1.5/site-packages/PIL + $ cd /usr/local/lib/python1.5/ + $ python compileall.py site-packages/PIL * Adding Tkinter support -- Bernhard Herzog | Sketch, a python based drawing program herzog@online.de | http://www.online.de/home/sketch/ From abmokhta@vub.ac.be Tue May 4 20:55:05 1999 From: abmokhta@vub.ac.be (Abdellatif Mokhtaren) Date: Tue, 4 May 1999 21:55:05 +0200 (MET DST) Subject: [Image-SIG] Asking Informations about Coral reef - Remote sensing Message-ID: <199905041955.VAA23729@mach.vub.ac.be> Dear, I' am a new member in your group, i' m interesting to Ecological Marine Management, specially Monitoring the marine environment via Remote sensing, Now i am looking for the most relevant general information sources published or distributed after 1990 about global change and coral reef via remote sensing. If you have some informations or suggestions about this topic do not hesit to e-mail me, yours sincerely From KCAZA@cymbolic.com Thu May 6 11:09:18 1999 From: KCAZA@cymbolic.com (Kevin Cazabon) Date: Thu, 06 May 1999 03:09:18 -0700 Subject: [Image-SIG] TIFF compatibility problems with PIL 1.0b Message-ID: I'm having a few problems with TIFF files that I create using PIL. It seems that the TIFF files I save are fine when I load them into Photoshop, but they are totally incompatible with many other programs, including PIL! (i.e. I can create a TIF, but cannot reload it into PIL, although it works fine in Photoshop). Any suggestions, or ideas as to why this may be happening? If I load the image into Photoshop and resave it, it works fine in PIL, etc. I'll attach a sample if anyone would like to see it (this ALWAYS happens, I'm using Win98). Kevin Cazabon From mstrout@ucsd.edu Thu May 6 19:36:47 1999 From: mstrout@ucsd.edu (Michelle Mills Strout) Date: Thu, 6 May 1999 11:36:47 -0700 (PDT) Subject: [Image-SIG] Problems installing PIL Message-ID: I have attempted to install both releases of PIL, 0.2b4 and 0.2b3. I am attempting to install on a Linux system. I get an error in the ./configure script for the libImaging directory. Specifically I get the following output: alicatado % ./configure loading cache ./config.cache checking for --without-gcc... no checking for gcc... gcc checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for ranlib... ranlib checking for ar... ar checking MACHDEP... linux2 checking for -ljpeg... no checking for -lmpeg... no checking for -lz... yes checking how to run the C preprocessor... gcc -E checking whether cross-compiling... yes checking for ANSI C header files... yes checking for inline... inline checking whether byte ordering is bigendian... no checking size of char... configure: error: can not run test program while cross compiling I do have Python installed in a non-standard directory. Do I need to call ./configure with --prefix? If so what directory in the install hierarchy should I specify? Thanks for any assistance, Michelle From fredrik@pythonware.com Thu May 6 21:01:58 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 6 May 1999 22:01:58 +0200 Subject: [Image-SIG] TIFF compatibility problems with PIL 1.0b References: Message-ID: <006001be97fb$4d6d0b50$f29b12c2@pythonware.com> Kevin Cazabon wrote: > I'm having a few problems with TIFF files that I create using PIL. > > It seems that the TIFF files I save are fine when I load them into > Photoshop, but they are totally incompatible with many other > programs, including PIL! this is a quite interesting feature of 1.0b1 (and probably a few releases before that). to make a long story short, let's just say I'm working on it... From fredrik@pythonware.com Thu May 6 21:00:30 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Thu, 6 May 1999 22:00:30 +0200 Subject: [Image-SIG] Problems installing PIL References: Message-ID: <005f01be97fb$4d500d70$f29b12c2@pythonware.com> Michelle Mills Strout wrote: > I have attempted to install both releases of PIL, 0.2b4 and 0.2b3. I am > attempting to install on a Linux system. I get an error in the > ./configure script for the libImaging directory. Specifically I get the > following output: > > alicatado % ./configure > loading cache ./config.cache > checking for --without-gcc... no > checking for gcc... gcc > checking whether we are using GNU C... yes > checking whether gcc accepts -g... yes > checking for ranlib... ranlib > checking for ar... ar > checking MACHDEP... linux2 > checking for -ljpeg... no > checking for -lmpeg... no > checking for -lz... yes > checking how to run the C preprocessor... gcc -E this far, everything looks just fine. but the next line looks a bit odd: > checking whether cross-compiling... yes this means that configure has decided that it cannot run the files created by gcc. check the config.log file for more details. From cgw@fnal.gov Thu May 6 21:35:02 1999 From: cgw@fnal.gov (Charles G Waldman) Date: Thu, 6 May 1999 15:35:02 -0500 (CDT) Subject: [Image-SIG] ImageDraw.Draw Message-ID: <14129.64758.813401.121380@buffalo.fnal.gov> The "Draw" method described in: http://www.pythonware.com/library/pil/handbook/imagedraw.htm isn't present in Imaging-1.0b/ImageDraw.py, and consequently the example code on the above Handbook page doesn't run. This doesn't bother me too much but I'm teaching Python to a friend and the incongruity between the manual and the actual software gets a bit confusing. I assume this is just a case of the Handbook being ahead of the actual release... will this method be in PIL 1.0 final? From mstrout@ucsd.edu Thu May 6 22:17:38 1999 From: mstrout@ucsd.edu (Michelle Mills Strout) Date: Thu, 6 May 1999 14:17:38 -0700 (PDT) Subject: [Image-SIG] Problems installing PIL In-Reply-To: <005f01be97fb$4d500d70$f29b12c2@pythonware.com> Message-ID: > > checking whether cross-compiling... yes > > this means that configure has decided that it > cannot run the files created by gcc. check > the config.log file for more details. The config.log file looks like this: configure:660: gcc -E conftest.c configure:802: gcc -o conftest -g -O conftest.c -ljpeg 1>&5 /tmp/cclKarsg.o: In function `t': /cse/grad/mstrout/package/Python-1.5.2/Extensions/Imaging/libImaging/configure:7 98: undefined reference to `jpeg_create_compress' collect2: ld returned 1 exit status configure:846: gcc -o conftest -g -O conftest.c -lmpeg 1>&5 /usr/bin/ld: cannot open -lmpeg: No such file or directory collect2: ld returned 1 exit status configure:890: gcc -o conftest -g -O conftest.c -lz 1>&5 configure:937: gcc -E conftest.c >/dev/null 2>conftest.out configure:985: gcc -o conftest -g -O conftest.c -lz 1>&5 configure:1011: gcc -E conftest.c >/dev/null 2>conftest.out configure:1112: gcc -c -g -O conftest.c 1>&5 configure:1155: gcc -c -g -O conftest.c 1>&5 configure:1171: gcc -c -g -O conftest.c 1>&5 configure: In function `t': configure:1166: `not' undeclared (first use in this function) configure:1166: (Each undeclared identifier is reported only once configure:1166: for each function it appears in.) configure:1166: parse error before `big' The 'not' the error is referring to is in these lines. #if BYTE_ORDER != BIG_ENDIAN not big endian #endif Any suggestions on how I could fix this? Thanks, Michelle From akuchlin@cnri.reston.va.us Fri May 7 15:58:50 1999 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Fri, 7 May 1999 10:58:50 -0400 (EDT) Subject: [Image-SIG] Textual data inside PNGs: not supported? Message-ID: <199905071458.KAA07681@amarok.cnri.reston.va.us> Looking at PngImagePlugin.py, it seems that while tEXt chunks are supported on reading in a PNG file, it doesn't look as if they're written on saving a PNG file. I really need the ability to add comments to PNG files, in order to add annotations to microscope images (date taken, who took it, other meta-info), so I'm willing to implement this with a bit of guidance. My questions are: * Am I actually correct in thinking that comments aren't saved in PNG file? * It looks like the fix is fairly simple: loop over the contents of the im.info dictionary and write out a tEXt chunk for each key/value pair. This is complicated a bit by the PngImagePlugin storing other things in the info dictionary, like 'interlace' and 'gamma' keys. Is it enough to just ignore those two keys, or are there more keys that should be ignored? * According to the PNG Recommendation, 'tEXt' chunks shouldn't be copied if the image is modified in any way (indicated by the lower-case fourth letter). I'm not sure what to do about this; I don't care for my application because I'm generating new images, not modifying a pre-existing image, but Fredrik will probably want some solution for this. /F, any ideas about what to do? -- A.M. Kuchling http://starship.python.net/crew/amk/ Monty Python's usual schoolboy humour is here let loose on a period of history appropriately familiar to every schoolboy in the West, and a faith which could be shaken by such good-humoured ribaldry would be a very precarious faith indeed. -- The British Board Of Film Censors, in their report on _Life of Brian_ From akuchlin@cnri.reston.va.us Fri May 7 18:01:10 1999 From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling) Date: Fri, 7 May 1999 13:01:10 -0400 (EDT) Subject: [Image-SIG] PNG text chunk patch Message-ID: <199905071701.NAA07895@amarok.cnri.reston.va.us> Here's the simple patch required to write out the contents of the info dictionary as text chunks: *** PngOrig Fri May 7 12:53:42 1999 --- PngImagePlugin.py Fri May 7 12:54:40 1999 *************** *** 408,411 **** --- 420,429 ---- chunk(fp, "gAMA", o32(int(gamma * 100000.0))) + # Write text chunks + for key, value in im.info.items(): + # Skip PIL-internal keys + if key in ['interlace', 'gamma']: continue + chunk(fp, 'tEXt', key + chr(0) + value) + ImageFile._save(im, _idat(fp, chunk), [("zip", (0,0)+im.size, 0, rawmode)]) As a small bonus, here's a completely untested implementation of chunk_zTXt, to read in compressed text chunks. *** PngOrig Fri May 7 12:53:42 1999 --- PngImagePlugin.py Fri May 7 12:54:40 1999 *************** *** 198,201 **** --- 198,213 ---- return s + def chunk_zTXt(self, pos, len): + # compressed text + s = self.fp.read(len) + [k, v] = string.split(s, "\0") + comp_method = ord( v[0] ) ; v = v[1:] + if comp_method != 0: + raise SyntaxError, "Unknown compression method %i in zTXt chunk" % comp_method + # Deflate/inflate compression was used + import zlib + self.im_info[k] = zlib.decompress( v ) + return s + # -------------------------------------------------------------------- -- A.M. Kuchling http://starship.python.net/crew/amk/ A successful tool is one that was used to do something undreamed of by its author. -- S.C. Johnson From aureli.soria_frisch@ipk.fhg.de Tue May 18 18:18:16 1999 From: aureli.soria_frisch@ipk.fhg.de (Aureli Soria Frisch) Date: Tue, 18 May 1999 19:18:16 +0200 Subject: [Image-SIG] Saving TIFF Message-ID: Hi! I have a problem when saving a TIFF Image with the PIL (version 0.3a1). The function 'save' saves an inverted image of the displayed image (with ImageTk.PhotoImage, mode "L"). Could you help me? Thanks in advance Aureli __\/__ . / - - \ |\l (o)(o) l/| I-----.OOOo----oo----oOOO.-----------------------------------------I Aureli Soria Frisch Tel. (++49)-(0)30-39006-150 FhG-IPK Fax (++49)-(0)30-3911037 Dept. of Pattern Recognition Pascalstr. 8-9 D-10587 Berlin, Germany Email Aureli.Soria_Frisch@ipk.fhg.de WWW Oooo. I---------.oooO--( )---------------------------------------------I ( ) ) / \ ( (_/ \_) From trigg@parc.xerox.com Thu May 20 23:20:02 1999 From: trigg@parc.xerox.com (Randy Trigg) Date: Thu, 20 May 1999 15:20:02 PDT Subject: [Image-SIG] PIL: stepping through multi-page tiff files Message-ID: <37448A92.B47294D9@parc.xerox.com> Has anyone had any trouble with the PIL support for multi-page tiffs? I have a 9-page tiff file (packbits compression) which I open in PIL, as in im = Image.open(foo.tif) Then I call im.seek(1), im.seek(2), ..., im.seek(9). I only get four steps of this before it dies with "Missing TIFF directories." Looking at the frames it generates, I can see that successive seeks skip frames, that is, seek(1) gives me page 3, seek(2) gives page 5, seek(3) gives page 7, and seek(4) gives page 9 (thus the error after the fourth seek). I've tried some variations like seek(0), seek(1), seek(0), seek(2), seek(0), seek(3), etc. That gives me more of the pages, 7 or 8, but with one of the pages repeated. But no variation gives me all of the pages. I tried to do this with an uncompressed version of the tiff file, but still no luck. By the way, the tiff file is fine - all 9 pages are viewable with the "Imaging for NT" application. Any ideas? Thanks much, - Randy From KCAZA@cymbolic.com Thu May 20 23:44:44 1999 From: KCAZA@cymbolic.com (Kevin Cazabon) Date: Thu, 20 May 1999 15:44:44 -0700 Subject: [Image-SIG] PIL: stepping through multi-page tiff files Message-ID: Just a shot in the dark, but isn't the seek() command ADDITIVE? as in: im.seek(1) im.seek(1) (would bring you to the second image) im.seek(1) (for the third image...) etc.... >>> Randy Trigg 05/20/99 03:20PM >>> Has anyone had any trouble with the PIL support for multi-page tiffs? I have a 9-page tiff file (packbits compression) which I open in PIL, as in im = Image.open(foo.tif) Then I call im.seek(1), im.seek(2), ..., im.seek(9). I only get four steps of this before it dies with "Missing TIFF directories." Looking at the frames it generates, I can see that successive seeks skip frames, that is, seek(1) gives me page 3, seek(2) gives page 5, seek(3) gives page 7, and seek(4) gives page 9 (thus the error after the fourth seek). I've tried some variations like seek(0), seek(1), seek(0), seek(2), seek(0), seek(3), etc. That gives me more of the pages, 7 or 8, but with one of the pages repeated. But no variation gives me all of the pages. I tried to do this with an uncompressed version of the tiff file, but still no luck. By the way, the tiff file is fine - all 9 pages are viewable with the "Imaging for NT" application. Any ideas? Thanks much, - Randy _______________________________________________ Image-SIG maillist - Image-SIG@python.org http://www.python.org/mailman/listinfo/image-sig From trigg@parc.xerox.com Fri May 21 01:47:39 1999 From: trigg@parc.xerox.com (Randy Trigg) Date: Thu, 20 May 1999 17:47:39 PDT Subject: [Image-SIG] Re: PIL: stepping through multi-page tiffs Message-ID: <3744AD2B.8145AA4C@parc.xerox.com> > Just a shot in the dark, but isn't the seek() command ADDITIVE? Yow. I just tried and it turns out that successive calls to im.seek(1) worked better, but still skipped from 1 to 3. But if I use successive calls to im.seek(0) I get through all 9 pages. Thanks for the tip. - Randy P.S. I think Iterator in the ImageSequence module needs to be changed to reflect this additive behavior... From fredrik@pythonware.com Sun May 23 14:15:28 1999 From: fredrik@pythonware.com (Fredrik Lundh) Date: Sun, 23 May 1999 15:15:28 +0200 Subject: [Image-SIG] Re: PIL: stepping through multi-page tiffs References: <3744AD2B.8145AA4C@parc.xerox.com> Message-ID: <015601bea51e$54d0e210$f29b12c2@pythonware.com> > > Just a shot in the dark, but isn't the seek() command ADDITIVE? > > Yow. I just tried and it turns out that successive calls to im.seek(1) > worked better, but still skipped from 1 to 3. But if I use successive > calls to im.seek(0) I get through all 9 pages. > > Thanks for the tip. > > - Randy > > P.S. I think Iterator in the ImageSequence module needs to be changed to > reflect this additive behavior... I'd rather change the TIFF decoder; this definitely looks like a bug to me... From rburnham@cri-inc.com Wed May 26 03:21:18 1999 From: rburnham@cri-inc.com (Roger Burnham) Date: Tue, 25 May 1999 18:21:18 -800 Subject: [Image-SIG] Building Imaging-1.0b1 on win95 Message-ID: <199905260121.UAA02721@mail1.gte.net> Hi, I'm having trouble building imaging from sources: Python 1.5.2 Imaging-1.0b1 jpeg-6b zlib113 VC++ 6.0 Zlib is built (zlibmodule links okay), as well as jpeg. I've created a generic DLL project for Imaging (based on the distrib example_nt). It compiles fine, but the linker reports: --------------------Configuration: Imaging - Win32 Release-------------------- Linking... Creating library Release/Imaging.lib and object Release/Imaging.exp ZipDecode.obj : error LNK2001: unresolved external symbol _inflateEnd ZipDecode.obj : error LNK2001: unresolved external symbol _inflate ZipDecode.obj : error LNK2001: unresolved external symbol _inflateInit_ ZipEncode.obj : error LNK2001: unresolved external symbol _deflateEnd ZipEncode.obj : error LNK2001: unresolved external symbol _deflate ZipEncode.obj : error LNK2001: unresolved external symbol _deflateSetDictionary ZipEncode.obj : error LNK2001: unresolved external symbol _deflateInit2_ Release/Imaging.dll : fatal error LNK1120: 7 unresolved externals Error executing link.exe. Imaging.dll - 8 error(s), 0 warning(s) These are defined in and exported by zlib (in the .def file). I get the same errors if I do not specify zlib as a linker option, so its a name mangling issue or some such. I'm using the compiler switches: /nologo /MD /W3 /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /Fp"Release/Imaging.pch" /YX /Fo"Release/" /Fd"Release/" /FD /c /Tc Any clues? Thanks, Roger Burnham Cambridge Research & Instrumentation rburnham@cri-inc.com http://www.cri-inc.com/ http://starship.python.net/crew/roger/ PGP Key: http://www.nai.com/default_pgp.asp PGP Fingerprint: 5372 729A 9557 5F36 177F 084A 6C64 BE27 0BC4 CF2D From rburnham@cri-inc.com Wed May 26 17:41:13 1999 From: rburnham@cri-inc.com (Roger Burnham) Date: Wed, 26 May 1999 16:41:13 GMT Subject: [Image-SIG] Adventures building zlib and _imaging Message-ID: <374c19c9.8520944@news.gte.net> I finally took the plunge and upgraded CRI's production software to the latest versions of Python (1.5.2), PythonWin (build 125), Numeric (LLNLDistribution11), zlib (113, with buildzlib113dll.zip, from http://www.winimage.com/zLibDll/build.html), jpeg (6b), and Imaging (Imaging-1.0b1). This is on Win95 (4.00.950 B) using VC++ 6.0 (no service packs). The problems: Including windows.h after Imaging.h causes the error: C:\vc\VC98\INCLUDE\basetsd.h(33) : error C2632: 'int' followed by 'int' is illegal The fix is to #undef INT32 #undef UINT32 before including windows.h, in map.c and ImDib.h. Neither map.c, nor any file that includes ImDib.h directly reference either symbol. When linking _imaging, names exported by zlib are not found due to name mangling in zlib. The fix was in zconf.h. Change: /* Compile with -DZLIB_DLL for Windows DLL support */ #if defined(ZLIB_DLL) # if defined(_WINDOWS) || defined(WINDOWS) # ifdef FAR # undef FAR # endif # include # define ZEXPORT WINAPI to /* Compile with -DZLIB_DLL for Windows DLL support */ /* WINAPI */ #if defined(ZLIB_DLL) # if defined(_WINDOWS) || defined(WINDOWS) # ifdef FAR # undef FAR # endif # include # define ZEXPORT FAR _cdecl to get the undecorated names exported. Now everything builds ok (zlibmodule also, which links to the static version of zlib). And now a hack I added to Imaging... I really like the way Numeric exports its API to other C/C++ programs via the import_array macro. As I also use Imaging from C extensions, I've added the same to Imaging. Imaging.c: Remove typedef struct { PyObject_HEAD Imaging image; } ImagingObject; and add #define _IMAGING_MODULE before including Imaging.h Change init_imaging to: init_imaging() { PyObject *m, *d; static void *PyImaging_API[PyImaging_API_pointers]; /* Patch object type */ Imaging_Type.ob_type = &PyType_Type; m = Py_InitModule("_imaging", functions); d = PyModule_GetDict(m); /* Initialize C API pointer arrays and store them in module */ PyImaging_API[PyImaging_Type_NUM] = (void *)&Imaging_Type; PyDict_SetItemString(d, "_IMAGING_API", PyCObject_FromVoidPtr((void *)PyImaging_API, NULL)); /* Check for errors */ if (PyErr_Occurred()) Py_FatalError("can't initialize module _imaging"); } To Imaging.h add #define PyImaging_Type_NUM 0 #define PyImaging_API_pointers 1 #if defined (_IMAGING_MODULE) || defined (_IMAGING_USER) typedef struct { PyObject_HEAD Imaging image; } ImagingObject; #endif #ifdef _IMAGING_USER void **PyImaging_API; #define PyImaging_Check(op) \ ((op)->ob_type == (PyTypeObject *)PyImaging_API[PyImaging_Type_NUM]) #define Imaging_Type *(PyTypeObject *)PyImaging_API[PyImaging_Type_NUM] #define import_imaging() \ { \ PyObject *_pilMod = PyImport_ImportModule("_imaging"); \ if (_pilMod != NULL) { \ PyObject *module_dict = PyModule_GetDict(_pilMod); \ PyObject *c_api_object = PyDict_GetItemString(module_dict, "_IMAGING_API"); \ if (PyCObject_Check(c_api_object)) { \ PyImaging_API = (void **)PyCObject_AsVoidPtr(c_api_object); \ } \ } \ } #endif after the typedef struct's near the top. Now, in your C/C++ code, before including Imaging.h #define _IMAGING_USER and in your modules init, add import_imaging(); Not quite as clean as the Numeric method, but works, Any chance of getting this or something like it in the Imaging distribution? Thanks to all of the authors of the above software, quite a powerful lot of stuff for a mornings work! If any one wants the VC++ project files for Imaging, drop me a line... Cheers, Roger Burnham Cambridge Research & Instrumentation rburnham@cri-inc.com http://www.cri-inc.com/ http://starship.python.net/crew/roger/ PGP Key: http://www.nai.com/default_pgp.asp PGP Fingerprint: 5372 729A 9557 5F36 177F 084A 6C64 BE27 0BC4 CF2D From rburnham@cri-inc.com Thu May 27 19:58:48 1999 From: rburnham@cri-inc.com (Roger Burnham) Date: Thu, 27 May 1999 10:58:48 -800 Subject: [Image-SIG] Need 12 or 16 bits/pixel images Message-ID: <199905271759.MAA02514@smtp1.gte.net> Hi, I've an application presented to me that needs the dynamic range of 12-16 bits/pixel images. We have a digital camera interfaced to Python, that can return such images (currently, I scale the data to 8 bits). I would like to stick with a standard format so that the user can view/manipulate the images with other programs as well. BMP is obviously out (I think!). I know TIF can do it, as I have an example 16 bit image collected with the same camera using a third party program. PIL opens this image successfully. The image has a rawmode of L;16B, but the decoder seems to just take the upper byte and give me a 0-255 grayscale image. Now I know I'll have to scale to 8 bits to display (on win95, using ImageWin), but I need the raw 16 bit data for computations, and I need to be able to save 16 bit images as well. I'd prefer not to resort to floating point images, as this application will be very memory intensive (up to 16 input images to the algo, and up to 4 output images). Can I do this with a variant of the TIF plugin? Any other advice anyone cares to offer on how to tackle this? Much appreciated, Roger Burnham Cambridge Research & Instrumentation rburnham@cri-inc.com http://www.cri-inc.com/ http://starship.python.net/crew/roger/ PGP Key: http://www.nai.com/default_pgp.asp PGP Fingerprint: 5372 729A 9557 5F36 177F 084A 6C64 BE27 0BC4 CF2D From r.hooft@euromail.net Sun May 30 20:34:49 1999 From: r.hooft@euromail.net (Rob Hooft) Date: Sun, 30 May 1999 21:34:49 +0200 (MZT) Subject: [Image-SIG] Need 12 or 16 bits/pixel images In-Reply-To: <199905271759.MAA02514@smtp1.gte.net> References: <199905271759.MAA02514@smtp1.gte.net> Message-ID: <14161.37593.25525.75046@octopus.chem.uu.nl> >>>>> "RB" == Roger Burnham writes: RB> Hi, I've an application presented to me that needs the dynamic RB> range of 12-16 bits/pixel images. We have a digital camera RB> interfaced to Python, that can return such images (currently, I RB> scale the data to 8 bits). I have a similar application. Scaling the image to 8 bits is really the only sensible thing to do, as the human eye cannot differentiate much more anyway, and there are AFAIK no regular graphics cards that can do more than 8 bit greyscale. See my "dis.py" on http://starship.python.net/crew/hooft/ Regards, Rob Hooft. -- ===== R.Hooft@EuroMail.net http://www.xs4all.nl/~hooft/rob/ ===== ===== R&D, Nonius BV, Delft http://www.nonius.nl/ ===== ===== PGPid 0xFA19277D ========================== Use Linux! =========