From greg@cbcainc.com Tue Feb 5 23:04:30 2002 From: greg@cbcainc.com (Greg Abbas) Date: Tue, 5 Feb 2002 15:04:30 -0800 Subject: [Image-SIG] Re: aliasing on resize or thumnail? Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C1AE56.69E9E040 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I kinda have to agree with marc's line of reasoning on this. I've noticed severe aliasing problems on transformed images too, and it seems like there's no reason why bilinear or bicubic (or sinc or gaussian or ...) resampling couldn't be implemented as described in the DSP textbooks, to keep aliasing to a minimum regardless of whether the resulting image is larger or smaller than the original. If you're doing any geometric transform (scaling or rotation or something funkier), unless speed is the only consideration don't you _always_ want to antialias? Is anyone working on this? -greg. marc lindahl wrote: > > They do blur the picture a little for me, in comparison if NEAREST. I > > believe what is happening - by design - is that BILINEAR and BICUBIC are > > just exactly that: they calculate each pixel color from the four pixels > > closest to it in the original image. > > That's not how it's supposed to work, to be an antialising filter, is it? it isn't an anti-aliasing filter: the BILINEAR and BICUBIC resampling filters are intended for geometric transforms (rotations, quadrilateral warps), not thumbnail generation. (and the ANTIALIAS filter isn't available in 1.1.2) you can get a better-than-nothing result by resizing multiple times with the BILINEAR filter; untested: while im.size[0] > size[0] or im.size[1] > size[1]: im = im.resize( (max(size[0], im.size[0]/2), max(size[1], im.size[1]/2)), Image.BILINEAR ) ------=_NextPart_000_00A9_01C1AE56.69E9E040 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I kinda have = to agree=20 with marc's line of reasoning on this. I've noticed severe aliasing = problems on=20 transformed images too, and it seems like there's no reason why bilinear = or=20 bicubic (or sinc or gaussian or ...) resampling couldn't be implemented = as=20 described in the DSP textbooks, to keep aliasing to a minimum = regardless of=20 whether the resulting image is larger or smaller than the original. If = you're=20 doing any geometric transform (scaling or rotation or something = funkier), unless=20 speed is the only consideration don't you _always_ want to=20 antialias?
 
Is anyone = working on=20 this?
 
-greg.
 
marc lindahl <marc@bowery.com>=20 wrote:
> > They do blur the picture a little for me, in = comparison=20 if NEAREST. I
> > believe what is happening - by design = - is=20 that BILINEAR and BICUBIC are
> > just exactly that: = they=20 calculate each pixel color from the four pixels
> > = closest to=20 it in the original image.
>
> That's not how = it's=20 supposed to work, to be an antialising filter, is it?

it = isn't an=20 anti-aliasing filter: the BILINEAR and BICUBIC resampling
filters are = intended for geometric transforms (rotations, quadrilateral
warps), = not=20 thumbnail generation.

(and the ANTIALIAS filter isn't available = in=20 1.1.2)

you can get a better-than-nothing result by resizing = multiple=20 times
with the BILINEAR filter; untested:

    = while=20 im.size[0] > size[0] or im.size[1] >=20 size[1]:
        im =3D=20 im.resize(
          = ; =20 (max(size[0], im.size[0]/2), max(size[1],=20 im.size[1]/2)),
         =   =20 Image.BILINEAR
       =20 )

</F>
 
------=_NextPart_000_00A9_01C1AE56.69E9E040-- From sjh@ucf.ics.uci.edu Wed Feb 6 21:47:11 2002 From: sjh@ucf.ics.uci.edu (Seth Hettich) Date: Wed, 06 Feb 2002 13:47:11 -0800 Subject: [Image-SIG] build problems Message-ID: <20020206214711.47D15281@whiskey.ucf.ics.uci.edu> I see in the archives this has come up before, but I didn't see a solution. I'm building w/ gcc on a solaris system. libImaging builds fine, but back in the main dir, when it comes time to link: gcc -shared ./_imaging.o ./decode.o ./encode.o ./map.o ./display.o ./outline.o ./path.o libImaging/libImaging.a -L/opt/contrib/gnome/lib -R/opt/contrib/gnome/ lib -ljpeg -L/opt/contrib/gnome/lib -R/opt/contrib/gnome/lib -lz -o ./_imaging. so Text relocation remains referenced against symbol offset in file ImagingTransformAffine 0x3b90 libImaging/libImaging.a(Geometry .o) ImagingTransformAffine 0x3cc0 libImaging/libImaging.a(Geometry .o) ImagingCopy 0x68 libImaging/libImaging.a(Bands.o) [...] I see that these functions are in _imaging.o, so I tried: gcc -shared ./decode.o ./encode.o ./map.o ./display.o ./outline.o ./path.o libImaging/libImaging.a -L/opt/contrib/gnome/lib -R/opt/contrib/gnome/lib -ljpeg -L/opt/contrib/gnome/lib -R/opt/contrib/gnome/lib -lz -o ./_imaging.so ./_imaging.o ld: fatal: symbol `ImagingError_ModeError' is multiply defined: (file libImaging/libImaging.a(Except.o) and file ./_imaging.o); ld: fatal: symbol `ImagingError_IOError' is multiply defined: (file libImaging/libImaging.a(Except.o) and file ./_imaging.o); ld: fatal: symbol `ImagingError_MemoryError' is multiply defined: (file libImaging/libImaging.a(Except.o) and file ./_imaging.o); ld: fatal: symbol `ImagingError_ValueError' is multiply defined: (file libImaging/libImaging.a(Except.o) and file ./_imaging.o); ld: fatal: symbol `ImagingError_Mismatch' is multiply defined: (file libImaging/libImaging.a(Except.o) and file ./_imaging.o); ld: fatal: File processing errors. No output written to ./_imaging.so moving _imaging.o to the end makes the link errors go away, but I get new ones instead. I don't fully understand the setup of the build system, so I'm unsure how this is supposed to be working. Any ideas? -Seth From sjh@whiskey.ucf.ics.uci.edu Wed Feb 6 22:31:57 2002 From: sjh@whiskey.ucf.ics.uci.edu (Seth Hettich) Date: Wed, 06 Feb 2002 14:31:57 -0800 Subject: [Image-SIG] build problems In-Reply-To: Your message of "Wed, 06 Feb 2002 13:47:11 PST." <20020206214711.47D15281@whiskey.ucf.ics.uci.edu> Message-ID: <20020206223157.B6D5C269@whiskey.ucf.ics.uci.edu> > I see in the archives this has come up before, but I didn't see a solution. > > I'm building w/ gcc on a solaris system. libImaging builds fine, > but back in the main dir, when it comes time to link: > gcc -shared ./_imaging.o ./decode.o ./encode.o ./map.o ./display.o > ./outline.o > ./path.o libImaging/libImaging.a -L/opt/contrib/gnome/lib > -R/opt/contrib/gnome/ > lib -ljpeg -L/opt/contrib/gnome/lib -R/opt/contrib/gnome/lib -lz -o > ./_imaging. > so > Text relocation remains referenced > against symbol offset in file > ImagingTransformAffine 0x3b90 libImaging/libImaging.a(Geometry > .o) [...] Ok, I got it to link, here is what I used: ld -G ./decode.o ./encode.o ./map.o ./display.o ./outline.o ./path.o -L./libImaging -L/opt/contrib/gnome/lib -R/opt/contrib/gnome/lib -ljpeg -L/opt/contrib/gnome/lib -R/opt/contrib/gnome/lib -lz -o ./_imaging.so ./_imaging.o -lImaging -lc -L/opt/contrib/python-2.2/lib/python2.2/config -lpython2.2 -lm -ldl It seems to be working fine now after I itstalled it. So, I dunno, you may want to take a look at this for making it work on solaris. -Seth From drewes@interstice.com Sat Feb 9 19:34:00 2002 From: drewes@interstice.com (Rich Drewes) Date: Sat, 09 Feb 2002 11:34:00 -0800 Subject: [Image-SIG] PIL video capture extension type problem Message-ID: <3C6579A8.4040206@interstice.com> Hello, I'm trying to write a C extension that simply takes a PIL image as an argument and fills it in with data grabbed from a video capture device. This should be simple, but the Python type casting is baffling me. The Python code looks like this: ---- #!/usr/bin/python import Image import mouse print "running" # open the camera device: mouse.init(0) im=Image.new("RGB", (160,120)) # capture a frame into 'im': mouse.getimage(im); ---- This fails at runtime on the last line with this error: ---- Traceback (most recent call last): File "mintest.py", line 14, in ? mouse.getimage(im); SystemError: ././_imaging.c:155: bad argument to internal function ---- My extension code for the getimage() looks like this: ---- static PyObject *GetImage(PyObject *self, PyObject *args) { PyObject* op; Imaging im; /* Check to see that one arguement was passed in */ if (!PyArg_ParseTuple(args, "O", &op)) return NULL; /* Check to see if that object is an Imaging */ // this is how it's supposed to be done, I think: im = PyImaging_AsImaging(op); if (!im) return NULL; printf("in GetImage, type 0x%x x %d y %d\n", im->type, im->xsize, im->ysize); return Py_BuildValue("i", 1); } ---- Note that I'm not actually trying to fil any video data into the Imaging structure yet. I'll do that once it accepts that the variable 'im' is actually of the correct type! The SystemError in _imaging.c:155 is apparently in the PyImaging_AsImaging() call, which apparently is supposed to recast the PyObject as an Imaging type. However, the function is detecting some problem doing this recasting. Why? Thanks for any help, Rich From anandamal@hotmail.com Sun Feb 10 09:30:44 2002 From: anandamal@hotmail.com (Amal P Anand) Date: Sun, 10 Feb 2002 15:00:44 +0530 Subject: [Image-SIG] Re: Getting Image resolution References: Message-ID: You can the information from tiff header if the creator of the image file has specified the resolution. Below I give a sample program in ANSI C .I have tried this program on RedHat Linux 6.2;You need a library called tiffio.h which comes default with Linux; If you dont have linux i can mail you the complete C source code or the tiff header specification file;Just mail me if you want so;Hope this helps you; Resolution.c ------------- # include main ( int argc, char * argv [ ] ) { TIFF * tif = TIFFOpen ( argv [ 1 ], "r" ); if ( tif ) { uint32 w, h; uint16 bps, spp; float xr, yr; TIFFGetField ( tif, TIFFTAG_IMAGEWIDTH, &w ); TIFFGetField ( tif, TIFFTAG_IMAGELENGTH, &h ); TIFFGetField ( tif, TIFFTAG_BITSPERSAMPLE, &bps ); TIFFGetField ( tif, TIFFTAG_SAMPLESPERPIXEL, &spp ); TIFFGetField ( tif, TIFFTAG_XRESOLUTION, &xr ); TIFFGetField ( tif, TIFFTAG_YRESOLUTION, &yr ); printf("width = %d\nlength = %d\n" "bitspersample = %d\nsampleperpixel = %d\n" "xres = %f\nyres = %f\n",w,h,bps,spp,xr,yr); TIFFClose ( tif ); } exit ( 0 ); } ------------------------------------------------------- In linux compile as follows cc Resolution.c -ltiff To Run ./a.out your-tiff-file You can get help about this libtiff library at /usr/doc/libtiff ----- Original Message ----- From: To: Sent: Wednesday, January 30, 2002 10:31 PM Subject: Image-SIG digest, Vol 1 #557 - 2 msgs > Send Image-SIG mailing list submissions to > image-sig@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/image-sig > or, via email, send a message with subject or body 'help' to > image-sig-request@python.org > > You can reach the person managing the list at > image-sig-admin@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Image-SIG digest..." > > ---------------------------------------------------------------------------- ---- > Today's Topics: > > 1. Getting Image resolution ? (Doyon, Jean-Francois) > 2. Re: Getting Image resolution ? (Terry Hancock) > From fredrik@pythonware.com Sun Feb 10 10:59:23 2002 From: fredrik@pythonware.com (Fredrik Lundh) Date: Sun, 10 Feb 2002 11:59:23 +0100 Subject: [Image-SIG] PIL video capture extension type problem References: <3C6579A8.4040206@interstice.com> Message-ID: <009e01c1b222$02f30e00$ced241d5@hagrid> Rich Drewes wrote: > I'm trying to write a C extension that simply takes a PIL image as an > argument and fills it in with data grabbed from a video capture device. > This should be simple, but the Python type casting is baffling me PIL uses three different objects: - Image.Image instances (public objects) - ImagingObject (used inside the _imaging wrapper) - Imaging structures (used inside libImaging) your Python code manipulates Image.Image instances; your C code will want to manipulate Imaging structures. > im=Image.new("RGB", (160,120)) here, "im" is an Image.Image instance. it's a python object, not an ImagingObject. "im.im" is the ImagingObject, "im.im.id" is a pointer to the Imaging structure, cast to a long integer. ("im.im" might be None, if the raster image hasn't been loaded. if you cannot be sure that the image was created by a call to Image.new, call "im.load()" before accessing the "im.im" attribute) and yes, if you're going to fill the entire image anyway, you can pass in None as the third argument (fill colour): im = Image.new("RGB", (160,120), None) > # capture a frame into 'im': > mouse.getimage(im); # capture a frame into 'im': # im.load() # not needed if you're using Image.new mouse.getimage(im.im.id); > /* Check to see that one arguement was passed in */ > if (!PyArg_ParseTuple(args, "O", &op)) > return NULL; > > /* Check to see if that object is an Imaging */ > // this is how it's supposed to be done, I think: > im = PyImaging_AsImaging(op); > if (!im) > return NULL; long imvalue; if (!PyArg_ParseTuple(args, "l", &imvalue)) return NULL; im = (Imaging) imvalue; also see the snap function in Sane/sane.py and Sane/_sanemodule.c hope this helps! cheers /F From eaw@connactivity.connactivity.com Sun Feb 10 16:02:07 2002 From: eaw@connactivity.connactivity.com (Eric Woudenberg) Date: Sun, 10 Feb 2002 11:02:07 -0500 Subject: [Image-SIG] Re: problem decoding JPEG files on freshly built PIL 1.1.2 on BSD unix In-Reply-To: Your message of "Mon, 28 Jan 2002 23:40:01 EST." Message-ID: <200202101602.g1AG27A09621@connactivity.connactivity.com> Hi, First: Thank you for creating PIL, it is very useful! Just FYI, I found the problem that I previously raised (see quoted mail at end). The trouble was that there was already an earlier libjpeg installed on the BSDi4.0 system that was getting picked up during linking, but the include files used during compilation of PIL came from a freshly unpacked Jpeg-6b distribution. So this test in jdapimin.c was failing: GLOBAL(void) jpeg_CreateDecompress (j_decompress_ptr cinfo, int version, size_t structsize) { int i; /* Guard against version mismatches between library and caller. */ cinfo->mem = NULL; /* so jpeg_destroy knows mem mgr not called */ if (version != JPEG_LIB_VERSION) ERREXIT2(cinfo, JERR_BAD_LIB_VERSION, JPEG_LIB_VERSION, version); I found it by enabling the error printf in JpegDecode.c: METHODDEF(void) error(j_common_ptr cinfo) { JPEGERROR* error; error = (JPEGERROR*) cinfo->err; #if 1 /* DEBUG */ cinfo->err->output_message(cinfo); #endif longjmp(error->setjmp_buffer, 1); } My one suggestion would be to always print a message here, it's not the sort of information that a programmer would not want to know about. Thanks, Eric Eric Woudenberg writes: >I'm using PIL 1.1.2 happily under Windows to produce thumbnails from >.gif and .jpeg files. The final app must run under BSDI4.0. I rebuilt >PIL from sources, also built Jpeg-6b and zlib-1.1.3. Everything built >and passed tests (PIL passed up to the point where the image was >trying to be displayed -- I don't have a screen on this machine): > >mook:~/src/Imaging-1.1.2/libImaging $ make check >./coretest >>>> processing lena.ppm... >>>> elapsed time: 10 >>>> as far as we tested, everything seems to be ok... >xv test.ppm >xv: Can't open display >*** Error code 1 (ignored) > > >But when I use it, I always get an error that it couldn't decode the file: > >mook:~/src/Imaging-1.1.2/Images $ python >Python 2.2 (#5, Jan 27 2002, 22:13:28) >[GCC 2.7.2.1] on bsdos4 >Type "help", "copyright", "credits" or "license" for more information. >>>> import Image >>>> a=Image.open('lena.jpg') >>>> a.getbbox() >Traceback (most recent call last): > File "", line 1, in ? > File "/home/minidisc/local/lib/python2.2/site-packages/PIL/Image.py", line 5 >14, in getbbox > self.load() > File "/home/minidisc/local/lib/python2.2/site-packages/PIL/ImageFile.py", li >ne 166, in load > raise IOError, "decoder error %d when reading image file" % e >IOError: decoder error -2 when reading image file >>>> > >Any ideas? My impression was that this should "just work", given that >it all works so nicely under windows. > >The Jpeg decoder is being built in (from ImConfig.h): > >/* Define if you have the IJG jpeg library (-ljpeg). */ >#define HAVE_LIBJPEG 1 > >GIF files seem to work okay. > >Thanks in advance for any help or suggestions. > >Eric Woudenberg > From drewes@interstice.com Sun Feb 10 23:04:48 2002 From: drewes@interstice.com (Rich Drewes) Date: Sun, 10 Feb 2002 15:04:48 -0800 Subject: [Image-SIG] PIL video capture extension type problem References: <3C6579A8.4040206@interstice.com> <009e01c1b222$02f30e00$ced241d5@hagrid> Message-ID: <3C66FC90.9090804@interstice.com> Fredrik Lundh wrote: >"im.im" is the ImagingObject, "im.im.id" is a pointer to the >Imaging structure, cast to a long integer. > >("im.im" might be None, if the raster image hasn't been loaded. >if you cannot be sure that the image was created by a call to >Image.new, call "im.load()" before accessing the "im.im" attribute) > >and yes, if you're going to fill the entire image anyway, you can >pass in None as the third argument (fill colour): > > im = Image.new("RGB", (160,120), None) > You have me on the right track now. Thanks! However . . . >also see the snap function in Sane/sane.py and Sane/_sanemodule.c > It seems like it would be more natural for the python code to pass the plain "im" (not im.im or im.im.id) and then have the C code access the actual Imaging portion of the structure itself. The _sanemodule.c doesn't do this though--it passes in the im.im.id from Python, and the C code has to accept that pointer as an int and typecast it to a pointer . . . all kind of ugly. Why do it this way instead of passing in the "im" and letting the C code find the Imaging portion of the structure? Thanks again! Rich From sjr@debian.org Mon Feb 11 10:54:50 2002 From: sjr@debian.org (Simon Richter) Date: Mon, 11 Feb 2002 11:54:50 +0100 (CET) Subject: [Image-SIG] Bug#133272: python-imaging-doc: pilfont utility does not work (fwd) Message-ID: Hi, I just received the attached bug report. Has anyone on this list already experienced this problem? Simon ---------- Forwarded message ---------- Date: 10 Feb 2002 13:06:43 -0800 From: Ben Pfaff To: submit@bugs.debian.org Subject: Bug#133272: python-imaging-doc: pilfont utility does not work Resent-Date: Sun, 10 Feb 2002 21:06:54 GMT Resent-From: Ben Pfaff Resent-To: debian-bugs-dist@lists.debian.org Resent-cc: Simon Richter , python-imaging@packages.qa.debian.org Package: python-imaging-doc Version: 1.1.2-4 The pilfont utility does not work. Using python 2.1, for instance, along with cour08.bdf provided in the python-imaging source package: blp@pfaff:~/tmp/python-imaging-1.1.2/Images(1)$ python /usr/share/doc/python-imaging-doc/examples/pilfont.py courB08.bdf PILFONT 0.3 -- PIL font compiler. Copyright (c) Fredrik Lundh 1997. All rights reserved. courB08.bdf... Traceback (most recent call last): File "/usr/share/doc/python-imaging-doc/examples/pilfont.py", line 52, in ? p = BdfFontFile.BdfFontFile(fp) File "/usr/lib/python2.1/site-packages/PIL/BdfFontFile.py", line 86, in __init__ FontFile.FontFile.__init__() TypeError: unbound method __init__() must be called with instance as first argument blp@pfaff:~/tmp/python-imaging-1.1.2/Images(1)$ -- "In this world that Hugh Heffner had made, he alone seemed forever bunnyless." --John D. MacDonald From hpj@urpla.net Mon Feb 11 14:07:05 2002 From: hpj@urpla.net (Hans-Peter Jansen) Date: Mon, 11 Feb 2002 15:07:05 +0100 Subject: [Image-SIG] PILing tiff G3 files? Message-ID: <20020211140705.E278B141B@shrek.lisa.de> [CC me, please] Hi Pythonics, I'm currently evaluating for a wxPython based fax viewer/manager project for fax G3 tiffs, which are typically generated by hylafax. I've found the Image Squeezer on http://starship.python.net/jjkunce/ as a basic example, how to mix wxPython and PIL, where I fall over this: When loading a fax tiff, im.mode is set to "1", and trying to convert it to RGB results in: IOError: decoder group3 not available Is there any chance, that PIL supports this decoder soon, or do I need to look for other ways to get around this? Cheers, Hans-Peter From fredrik@pythonware.com Mon Feb 11 16:47:00 2002 From: fredrik@pythonware.com (Fredrik Lundh) Date: Mon, 11 Feb 2002 17:47:00 +0100 Subject: [Image-SIG] Bug#133272: python-imaging-doc: pilfont utility does not work (fwd) References: Message-ID: <014e01c1b31b$bb6daae0$0900a8c0@spiff> simon wrote: > I just received the attached bug report. Has anyone on this list = already > experienced this problem? someone played with PyChecker just before the 1.1.2 release, and got a little carried away... here's a patch: Change 3671 by fredrik@modules-hagrid (re)moved bogus __init__ call (bug spotted by Fred Clare) Affected files ... ... //modules/pil/PIL/BdfFontFile.py#3 edit Differences ... =3D=3D=3D=3D //modules/pil/PIL/BdfFontFile.py#3 (ktext) =3D=3D=3D=3D @@ -83,14 +84,12 @@ def __init__(self, fp): - FontFile.FontFile.__init__() + FontFile.FontFile.__init__(self) s =3D fp.readline() if s[:13] !=3D "STARTFONT 2.1": raise SyntaxError, "not a valid BDF file" - FontFile.FontFile.__init__(self) - props =3D {} comments =3D [] From srichter@cbu.edu Mon Feb 11 17:12:36 2002 From: srichter@cbu.edu (Stephan Richter) Date: Mon, 11 Feb 2002 11:12:36 -0600 Subject: [Image-SIG] PILing tiff G3 files? In-Reply-To: <20020211140705.E278B141B@shrek.lisa.de> Message-ID: <5.1.0.14.2.20020211111125.02d85d80@mercury-1.cbu.edu> >Is there any chance, that PIL supports this decoder soon, or do >I need to look for other ways to get around this? Well, I asked the question about 2 years ago and it comes up frequently. I guess noone with the necessary cash or knowledge has been able to write the driver. Regards, Stephan -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From sjr@debian.org Mon Feb 11 17:41:23 2002 From: sjr@debian.org (Simon Richter) Date: Mon, 11 Feb 2002 18:41:23 +0100 (CET) Subject: [Image-SIG] Bug#133272: python-imaging-doc: pilfont utility doesnot work (fwd) In-Reply-To: <014e01c1b31b$bb6daae0$0900a8c0@spiff> Message-ID: On Mon, 11 Feb 2002, Fredrik Lundh wrote: > > I just received the attached bug report. Has anyone on this list already > > experienced this problem? > someone played with PyChecker just before the 1.1.2 release, > and got a little carried away... > here's a patch: Thanks Simon -- GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! From hpj@urpla.net Mon Feb 11 18:11:50 2002 From: hpj@urpla.net (Hans-Peter Jansen) Date: Mon, 11 Feb 2002 19:11:50 +0100 Subject: [Image-SIG] PILing tiff G3 files? In-Reply-To: <5.1.0.14.2.20020211111125.02d85d80@mercury-1.cbu.edu> References: <5.1.0.14.2.20020211111125.02d85d80@mercury-1.cbu.edu> Message-ID: <20020211181150.BFAB5141B@shrek.lisa.de> On Monday, 11. February 2002 18:12, Stephan Richter wrote: > On Monday, 11. February 2002 15:07, Hans-Peter Jansen wrote: > >I'm currently evaluating for a wxPython based fax viewer/manager project > >for fax G3 tiffs, which are typically generated by hylafax. > >I've found the Image Squeezer on http://starship.python.net/jjkunce/ > >as a basic example, how to mix wxPython and PIL, where I fall over this: > >When loading a fax tiff, im.mode is set to "1", and trying to convert it > >to RGB results in: > >IOError: decoder group3 not available > >Is there any chance, that PIL supports this decoder soon, or do > >I need to look for other ways to get around this? > > Well, I asked the question about 2 years ago and it comes up frequently. I > guess noone with the necessary cash or knowledge has been able to write the > driver. Bad news! Well, I dived into this a bit deeper this afternoon, and found a workaround, because wxImage was able to decode the G3 stuff: if img1.format == "TIFF" and img1.mode == "1": # Fax G3 tiff img = wxImage(self.srcpath, wxBITMAP_TYPE_TIF) bm = img.ConvertToBitmap() imgsize = bm.GetWidth(), bm.GetHeight() img1 = Image.fromstring("RGB", imgsize, img.GetData()) Unfortunately, I ran right across the next problems: wxImage ignores any subsequent pages of the fax tiff. Does some enlighted wxMind know, how do I get all images/pages out of this kind of tiff's? Now, I stick in the process of getting the scaling of low resolution faxes right (with different V/H resolutions). I guess, I've to double every scanline of them :() > Regards, > Stephan Cheers, Hans-Peter From ken.chiu@propel.com Mon Feb 11 22:47:21 2002 From: ken.chiu@propel.com (Ken Chiu) Date: Mon, 11 Feb 2002 14:47:21 -0800 Subject: [Image-SIG] compressed gif Message-ID: Hi, Does PIL support writing compressed gif file? I am in the process of getting a gif license. After I have the license, where can I get a python library that supports writing compressed gif files? Thanks Ken From srichter@cbu.edu Tue Feb 12 00:37:21 2002 From: srichter@cbu.edu (Stephan Richter) Date: Mon, 11 Feb 2002 18:37:21 -0600 Subject: [Image-SIG] compressed gif In-Reply-To: Message-ID: <5.1.0.14.2.20020211183624.02d43db0@mercury-1.cbu.edu> At 02:47 PM 2/11/2002 -0800, Ken Chiu wrote: >Hi, > >Does PIL support writing compressed gif file? I am in the process of getting >a gif license. After I have the license, where can I get a python library >that supports writing compressed gif files? Thanks What I do is to write out the uncompressed GIF with PIL and then use gifsicle to do the rest. This works very, very well for me creating animated GIFs. Regards, Stepahn -- Stephan Richter CBU - Physics and Chemistry Student Web2k - Web Design/Development & Technical Project Management From mike@nthwave.net Thu Feb 14 22:42:45 2002 From: mike@nthwave.net (Michael Mell) Date: Thu, 14 Feb 2002 14:42:45 -0800 Subject: [Image-SIG] img doesn't handle upper case extentsions Message-ID: <3C6C3D65.674FC942@nthwave.net> in the module img, the class _FileDict contains the dictionary __fmtdict with these values: 'rgb': 'imgsgi', 'gif': 'imggif', 'pgm': 'imgpgm', 'ppm': 'imgppm', 'pbm': 'imgpbm', 'tiff': 'imgtiff', 'tif': 'imgtiff', 'jpeg': 'imgjpeg', 'jpg': 'imgjpeg', 'bmp': 'imgbmp', 'xbm': 'imgxbm', 'png': 'imgpng' Upper case extensions are not handled and throw an error: raise error, 'Unknown image file type (bad magic number)' Is there a way to include upper case extensions in the dictionary without editing the module? thanks -- mike@nthwave.net llemekim YahooIM 415.455.8812 voice 419.735.1167 fax From hancock@anansispaceworks.com Fri Feb 15 05:40:36 2002 From: hancock@anansispaceworks.com (Terry Hancock) Date: Thu, 14 Feb 2002 21:40:36 -0800 Subject: [Image-SIG] ld problem with libImaging Message-ID: <3C6C9F54.9FE50A4E@anansispaceworks.com> Hi, I'm trying to build PIL on a Debian Linux system, with a number of source packages installed under a single directory "/usr/local/narya" -- the reasoning is that I have to port all of these onto another, rather different system, and I want to keep these development packages together. So, for example, I have libjpeg and libpng installed under /usr/local/narya/lib . For some reason, "ld" can't seem to find these, as invoked in the libImaging makefile, so my build ends like this: gcc -o coretest coretest.o libImaging.a -lz -ljpeg -lm /usr/bin/ld: cannot find -ljpeg collect2: ld returned 1 exit status make: *** [coretest] Error 1 However: % cat /etc/ld.so.conf /usr/X11R6/lib /usr/local/narya/lib and % echo $LD_LIBRARY_PATH /usr/local/narya/lib:/usr/local/narya/mysql/lib/mysql:/usr/local/narya/lib:/usr/local/narya/mysql/lib/mysql: and I've already run "/sbin/ldconfig -v", which shows the /usr/local/narya/lib directory and the jpeg and png libraries (among others): ... /usr/local/narya/lib: libMagick.so.5 => libMagick.so.5.0.42 libfreetype.so.6 => libfreetype.so.6.2.0 libpng.so.3 => libpng.so.3.1.2.1 libxml2.so.2 => libxml2.so.2.4.15 libjpeg.so.62 => libjpeg.so.62.0.0 libz.so.1 => libz.so.1.1.3 ... Furthermore: gcc -o coretest coretest.o libImaging.a -lz -ljpeg -lm fails, as above, but adding the search path with the -L flag works: gcc -o coretest coretest.o libImaging.a -lz -ljpeg -lm -L/usr/local/narya/lib But I can't seem to get this to happen without the flag, and I'm not sure where to define such an option so that the makefile will use it. I'm not sure if this is really a PIL problem, but it's the only package that's giving me this kind of trouble (for example, the libMagick library, which also depends on these libraries, built without problems). So why can't the loader find it? Any recommendations on how I can finish the install? Are there some missing options I can put somewhere, or have I missed a step in making the libraries available? I'm pretty stumped. Any help or suggestions would be much appreciated, thanks! Terry -- ------------------------------------------------------ Terry Hancock hancock@anansispaceworks.com Anansi Spaceworks http://www.anansispaceworks.com ------------------------------------------------------ From hancock@anansispaceworks.com Fri Feb 15 22:37:00 2002 From: hancock@anansispaceworks.com (Terry Hancock) Date: Fri, 15 Feb 2002 14:37:00 -0800 Subject: [Fwd: Re: [Image-SIG] ld problem with libImaging (solved)] Message-ID: <3C6D8D8C.26B153A7@anansispaceworks.com> (My solution and a diff to Makefile.in, to make this a little easier for the next person ;) ). Thanks to Chris (clee) for making it clear that this had to be handled by changing the flag for gcc. The problem: Terry Hancock wrote: > gcc -o coretest coretest.o libImaging.a -lz -ljpeg -lm > /usr/bin/ld: cannot find -ljpeg > collect2: ld returned 1 exit status > make: *** [coretest] Error 1 Was apparently caused by not being able to find the jpeg library (which was in /usr/local/narya/lib in my case). The only way to make this work apparently, is to provide gcc with the -L flag, so the makefile needs a change to reflect this. I solved this by adding an LFLAGS variable to Makefile.in, and referencing it in the build line, which I think is a good solution for general use. This was really confusing. The thing is that the linking operation doesn't use the CFLAGS variable, and the LIBS variable is supposed to be controlled by "configure". So I put this in the "things configurable but not by configure" section. Probably should really be in configure somewhere, but that's out of my depth at present. Diff of my solution (omitting all the stuff specific to my system -- obviously I then changed "/usr/local/lib" to my oddball directory "/usr/local/narya/lib"). I'd like to suggest adding this change to the distribution: % diff -C3 Makefile.original Makefile.in *** Makefile.original Fri Feb 15 04:33:18 2002 --- Makefile.in Fri Feb 15 04:34:08 2002 *************** *** 34,39 **** --- 34,40 ---- OPT= @OPT@ #OPT= -g CFLAGS= $(OPT) -I$(INCLDIR) -I$(JPEGINCLUDE) $(DEFS) + LFLAGS= -L/usr/local/lib MKDEP= mkdep SHELL= /bin/sh *************** *** 80,86 **** all: coretest $(LIB) coretest: coretest.o $(LIB) ! $(CC) -o coretest coretest.o $(LIB) $(LIBS) $(LIB): $& $(OBJS) -rm -f $(LIB) --- 81,87 ---- all: coretest $(LIB) coretest: coretest.o $(LIB) ! $(CC) -o coretest coretest.o $(LIB) $(LIBS) $(LFLAGS) $(LIB): $& $(OBJS) -rm -f $(LIB) -- ------------------------------------------------------ Terry Hancock hancock@anansispaceworks.com Anansi Spaceworks http://www.anansispaceworks.com P.O. Box 60583 Pasadena, CA 91116-6583 ------------------------------------------------------ From maynard@mpi-cbg.de Wed Feb 20 14:19:57 2002 From: maynard@mpi-cbg.de (Gary Maynard) Date: Wed, 20 Feb 2002 15:19:57 +0100 Subject: [Image-SIG] problem reading tiffs In-Reply-To: <3C6D8D8C.26B153A7@anansispaceworks.com> Message-ID: Hi everybody, I am trying to use PIL to read tiffs created by metamorph. I get an error: >Traceback (most recent call last): > File "./get_data.py", line 12, in ? > im = Image.open("2.6_7.8DIC21.TIF") > File "/usr/local/python-2.2/lib/python2.2/site-packages/PIL/Image.py", line 960, in open > raise IOError, "cannot identify image file" >IOError: cannot identify image file Whenever I run tiffinfo on the file I get: >2.6_7.8DIC02.TIF: Warning, unknown field with tag 317 (0x13d) ignored. >2.6_7.8DIC02.TIF: Warning, unknown field with tag 33628 (0x835c) ignored. >TIFF Directory at offset 0x2b8cc > Subfile Type: (0 = 0x0) > Image Width: 300 Image Length: 296 > Resolution: 15.5358, 15.5358 pixels/inch > Bits/Sample: 16 > Compression Scheme: None > Photometric Interpretation: min-is-black > Date & Time: "2002:01:08 14:00:11" > Software: "MetaMorph" > Image Description: "Acquired from MV-1500\r\nExposure: 250 ms\r\nRegion: 600 x 600, offset at (340, 212)\r\nBinning: 2 x 2\r\nGain: 1\r\nBit Depth: 12\r\n" > Rows/Strip: 13 > Planar Configuration: single image plane now it could be that the unknown tags are causing the read to fail, in which case I will need to modify tiffimageplugin.py to accept these new tags (I think). Alternatively, I am concerned that my libImaging directry is still in my home, and wasn't moved to /usr/local/python like everything else. Perhaps this is a problem also? I also saw in the archives (way back in 99!) that there was a re-written version of TiffImagePlugin.py which mentioned specifically handling these files (created my metamorph). Is this still available? Is it now the current module? Is my problem nothing to do with the files I'm trying to read and instead to do with my installation? Any help at in pointing me towards decoding these slightly unusual tiffs would be much appreciated. At the moment I am not really so sure how I can trace the problem and do the decoding. thanks, Gary From spankaccount@yahoo.com Thu Feb 21 03:11:52 2002 From: spankaccount@yahoo.com (Kevin Stanchfield) Date: Wed, 20 Feb 2002 19:11:52 -0800 (PST) Subject: [Image-SIG] Imaging-1.1.2 Message-ID: <20020221031152.51373.qmail@web14404.mail.yahoo.com> Hi Everyone, I'm trying to compile on Solaris 2.6, 32bit, gcc. Anyone know what these errors mean. Let me know if I need to provide more information. ###### gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c coretest.c In file included from Imaging.h:21, from coretest.c:19: ImPlatform.h:18: #error Sorry, this library requires ANSI header files. ImPlatform.h:36: #error Cannot find required 32-bit integer type ImPlatform.h:48: #error Cannot find required 32-bit floating point type *** Error code 1 make: Fatal error: Command failed for target `coretest.o' ###### __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From rtrocca@libero.it Sat Feb 23 02:14:28 2002 From: rtrocca@libero.it (Riccardo Trocca) Date: Fri, 22 Feb 2002 18:14:28 -0800 Subject: [Image-SIG] Help with AVI files Message-ID: <5.1.0.14.0.20020222175552.02ecbf30@popmail.libero.it> Hello, I'll describe my problem just saying that I'm getting crazy! Some time ago I wrote a Python extension that could read frames from an AVI file. Everything worked well until my HD crashed and I lost every bit of my work. Now I've got to do that again, therefore I'm writing a new extension. This time I decided to go through SWIG in order to learn it and then build a bigger package for Image Processing. The problem that I've got now is that I can't see nothing else than noise in every image I try to grab with python. The C program I wrote is simple, and I've already used it in other applications and it works: struct _AVIFile { PAVISTREAM ppavi; PGETFRAME pgframe; AVISTREAMINFO avis; LPBITMAPINFOHEADER bi; //IplImage* img; int width; int height; int frames; int bitcount; int current; }; typedef struct _AVIFile AVIFile; LONG AFOpenVideoStream(AVIFile* af,const char* path,bool flip=false); LPBITMAPINFOHEADER AFGetFrame(AVIFile* af, int index); void AFCloseVideoStream(AVIFile* af); LONG AFOpenVideoStream(AVIFile* af,const char* path, bool flip){ LONG hr; int channels; int origin; hr=AVIStreamOpenFromFile( &(af->ppavi), path, streamtypeVIDEO, 0, OF_SHARE_DENY_WRITE,0L); if (hr!=0) return false; AVIStreamInfo(af->ppavi, &(af->avis), sizeof(af->avis)); af->pgframe=AVIStreamGetFrameOpen(af->ppavi,0L); if (!af->pgframe) return false; af->bi = (LPBITMAPINFOHEADER) AVIStreamGetFrame(af->pgframe,0); af->frames=af->avis.dwLength; af->width=af->bi->biWidth; af->height=af->bi->biHeight; af->bitcount=af->bi->biBitCount; af->current=0; return true; } LPBITMAPINFOHEADER AFGetFrame(AVIFile* af, int index){ static int temp; temp=(index>af->frames-1?af->frames-1:(index<0?0:index)); if (af->current!=temp) { af->current=temp; af->bi=(LPBITMAPINFOHEADER) AVIStreamGetFrame(af->pgframe,af->current); } return af->bi; } Then I wrote a SWIG file like this: %module _pyAVIFile %{ #include #include #include #include "AVIFile.h" #include %} %include "typemaps.i" typedef struct { %readonly int width; int height; int frames; int bitcount; int current; } AVIFile; %addmethods AVIFile{ AVIFile(char* path) { AVIFile* af=(AVIFile*)malloc(sizeof(AVIFile)); if (!AFOpenVideoStream(af,path,false)) return NULL; return af; } ~AVIFile() { AFCloseVideoStream(self); free(self); } PyObject* getNumeric(int frame) { int dims[3]; dims[0]=self->width; dims[1]=self->height; dims[2]=3; AFGetFrame(self,frame); return PyArray_FromDimsAndData(3,dims,PyArray_UBYTE, (char*)self+(self->bi->biSize)); } PyObject* getString(int frame) { int dims[3]; dims[0]=self->width; dims[1]=self->height; dims[2]=3; AFGetFrame(self,frame); return PyString_FromStringAndSize((char*)self+(self->bi->biSize),dims[0]*dims[1]*dims[2]); } } void AVIFileInit(); void AVIFileExit(); %init %{ import_array(); %} Of course all of this will work with just 24bit images, but by now it is ok. Everything seems to work, and when I open the AVI file I can see the exact width and size being read. Ok. The problem is with the Numeric and string representation. If I try to print the Numeric object, Python crashes. This just printing! if I use NumTut.view it will not crash, but it will show just noise! The same result with: im=Image.new('RGB',(352,288)) im.fromstring(af2.getString(100)) im.show() the same "noise" I remember problems with channels ordering, but in that case I should be able to see a false color image. Well, now I'm really lost. Can somebody give some help? Riccardo From geert@boskant.nl Sat Feb 23 18:58:38 2002 From: geert@boskant.nl (Geert Jansen) Date: Sat, 23 Feb 2002 19:58:38 +0100 Subject: [Image-SIG] ANNOUCE: Python-gd 0.9 Message-ID: Hi Everyone, I recently wrote a new Python interface for the gd imaging library. I was rather dissatified with the available interfaces and so I decided to write a new one. The Python/gd combo is of course not nearly as advanced as PIL, but with my interface you get some nice features, like an like an object oriented API, truecolor support and anti aliased truetype rendering. I use it for generating images in a web application system it works very well for me. If you want to check it out, see http://www.boskant.nl/geert/Software/ for a source distribution and online documentation. The interface is dubbed Python-gd and is freely available for everyone under the Artistic license. Greetings, Geert Jansen -- long long email=0X78DC806B91FCA334,i=0,j; main(){j=(email>>4*i)&15; putchar(j+j/2+j/5-j/12+(j<13?97:-65+7*j));i/15?exit(0):++i,main();} From fredrik@pythonware.com Mon Feb 25 16:11:06 2002 From: fredrik@pythonware.com (Fredrik Lundh) Date: Mon, 25 Feb 2002 17:11:06 +0100 Subject: [Image-SIG] Imaging-1.1.2 References: <20020221031152.51373.qmail@web14404.mail.yahoo.com> Message-ID: <033f01c1be17$10324620$ced241d5@hagrid> kevin wrote: > I'm trying to compile on Solaris 2.6, 32bit, gcc. > Anyone know what these errors mean. Let me know if I > need to provide more information. > > ###### > gcc -O -I./. -I/usr/local/include -DHAVE_CONFIG_H -c > coretest.c > In file included from Imaging.h:21, > from coretest.c:19: > ImPlatform.h:18: #error Sorry, this library requires > ANSI header files. > ImPlatform.h:36: #error Cannot find required 32-bit > integer type > ImPlatform.h:48: #error Cannot find required 32-bit > floating point type > *** Error code 1 > make: Fatal error: Command failed for target > `coretest.o' > ###### looks like a broken compiler installation; for some reason, the compiler is picking up non-ANSI/pre-ANSI header files. the libImaging/config.log file may provide additional clues. From acobb@oeb.harvard.edu Mon Feb 25 16:29:50 2002 From: acobb@oeb.harvard.edu (Alex Cobb) Date: Mon, 25 Feb 2002 11:29:50 -0500 Subject: [Image-SIG] Feature recognition in Python? In-Reply-To: <033f01c1be17$10324620$ced241d5@hagrid> References: <20020221031152.51373.qmail@web14404.mail.yahoo.com> Message-ID: <5.1.0.14.0.20020225111953.00bbd928@pop.fas.harvard.edu> Hi everyone, I am working on a (very) simple feature recognition task: finding light-colored ellipses on a dark background. Has anyone seen any code/know of any resources for feature recognition using Python? More detail, if you want it: I am working on an algorithm that would determine whether any given pixel represented the center of an ellipse by determining whether it is the centroid of pixel values in a neighborhood of a given radius. I've gotten as far as using PIL to load a .jpg, transferring it to a NumPy matrix using tostring and fromstring -- now I want to apply the filter. Is it possible to implement custom filters like this in PIL? Or am I better off doing it using NumPy? Thanks in advance for any help -- Alex From Aureli.Soria_Frisch@ipk.fhg.de Mon Feb 25 17:10:13 2002 From: Aureli.Soria_Frisch@ipk.fhg.de (Aureli Soria Frisch) Date: Mon, 25 Feb 2002 18:10:13 +0100 Subject: [Image-SIG] 11-bit Sat-images viewer? In-Reply-To: <015e01c15e02$2ff25240$0900a8c0@spiff> References: Message-ID: Hi, I am trying to open and view satellite images (3 bands 11-bit per band). It seems not to be possible with the actual configuration of Python I have: Python 2.0, PIL 1.1.1 on Mac OS 8.6. Is that possible with another PIL version? I need to open the images and to access the numerical information. Does someone know any feasable solution? Thanks in advance, Aureli ################################# Aureli Soria Frisch Fraunhofer IPK Dept. Pattern Recognition post: Pascalstr. 8-9, 10587 Berlin, Germany e-mail: aureli@ipk.fhg.de fon: +49 30 39006-150 fax: +49 30 3917517 web: http://vision.fhg.de/~aureli/web-aureli_en.html ################################# From spankaccount@yahoo.com Tue Feb 26 01:22:48 2002 From: spankaccount@yahoo.com (Kevin Stanchfield) Date: Mon, 25 Feb 2002 17:22:48 -0800 (PST) Subject: [Image-SIG] Re: Image-SIG digest, Vol 1 #570 - 2 msgs In-Reply-To: Message-ID: <20020226012248.19022.qmail@web14402.mail.yahoo.com> Hi All, I getting further now when compiling. When trying to make the modules I get a ton of errors. Bellow is just a snipit. Any help would be greatly appreciated. ##### 0x7c /usr/local/lib/libz.a(deflate.o) 0x88 /usr/local/lib/libz.a(deflate.o) 0x94 /usr/local/lib/libz.a(deflate.o) 0xa0 /usr/local/lib/libz.a(deflate.o) 0xac /usr/local/lib/libz.a(deflate.o) 0x420 /usr/local/lib/libjpeg.a(jcparam.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make: *** [_imaging.so] Error 1 #### __________________________________________________ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com From whale@mycameo.com Tue Feb 26 09:02:54 2002 From: whale@mycameo.com (whale) Date: Tue, 26 Feb 2002 17:02:54 +0800 Subject: [Image-SIG] Problem with opening PCX image Message-ID: V2hlbiBJIG9wZW5lZCBQQ1ggaW1hZ2VzIHdpdGggUElMLCBtb3N0IGltYWdlcyB3b3JrIGZpbmUu DQpIb3dldmVyLCB0aGVyZSBpcyBvbmUgaW1hZ2UgSSBvcGVuZWQgaXQgd2l0aCB0aGUgc2FtZSBw cm9jZWR1cmUsIHRoZSBleGNlcHRpb24gb2NjdXJlZC4NCkkgY2FuIHZpZXcgdGhpcyBpbWFnZSB3 aXRoIGRpZmZlcmVudCBpbWFnZSB2aWV3ZXIuDQpJIGFtIG5vdCBzdXJlIGhvdyBkb2VzIHRoaXMg aGFwcGVuPw0KSXMgdGhpcyB0aGUgYnVnIGV4aXN0aW5nIGluIFBJTCBtb2R1bGU/DQpJIHB1dCBh IHByb2JsZW1hdGljIGltYWdlIG9ubGluZSBhdCBodHRwOi8vd3d3Lm15Y2FtZW8uY29tL2Rvd25s b2FkL2Zyb21RQS5QQ1guDQpQbGVhc2UgdGFrZSBhIGxvb2sgYXQgaXQuDQpUaGFua3MgYSBsb3Qu DQoNClB5dGhvbldpbiAyLjEuMSAoIzIwLCBKdWwgMjYgMjAwMSwgMTE6Mzg6NTEpIFtNU0MgMzIg Yml0IChJbnRlbCldIG9uIHdpbjMyLg0KUG9ydGlvbnMgQ29weXJpZ2h0IDE5OTQtMjAwMSBNYXJr IEhhbW1vbmQgKE1hcmtIQEFjdGl2ZVN0YXRlLmNvbSkgLSBzZWUgJ0hlbHAvQWJvdXQgUHl0aG9u V2luJyBmb3IgZnVydGhlciBjb3B5cmlnaHQgaW5mb3JtYXRpb24uDQo+PiBpbXBvcnQgSW1hZ2UN Cj4+IGltID0gSW1hZ2Uub3BlbigiMS5wY3giKQ0KPj4gaW0ubG9hZCgpDQpUcmFjZWJhY2sgKG1v c3QgcmVjZW50IGNhbGwgbGFzdCk6DQogIEZpbGUgIjxpbnRlcmFjdGl2ZSBpbnB1dD4iLCBsaW5l IDEsIGluID8NCiAgRmlsZSAiRDpcUHl0aG9uMjFcSW1hZ2VcUElMXEltYWdlLnB5IiwgbGluZSA0 MjcsIGluIGNvbnZlcnQNCiAgICBzZWxmLmxvYWQoKQ0KICBGaWxlICJEOlxQeXRob24yMVxJbWFn ZVxQSUxcSW1hZ2VGaWxlLnB5IiwgbGluZSAxNjYsIGluIGxvYWQNCiAgICByYWlzZSBJT0Vycm9y LCAiZGVjb2RlciBlcnJvciAlZCB3aGVuIHJlYWRpbmcgaW1hZ2UgZmlsZSIgJSBlDQpJT0Vycm9y OiBkZWNvZGVyIGVycm9yIC0xIHdoZW4gcmVhZGluZyBpbWFnZSBmaWxl From gritsch@iue.tuwien.ac.at Wed Feb 27 15:25:58 2002 From: gritsch@iue.tuwien.ac.at (Markus Gritsch) Date: Wed, 27 Feb 2002 16:25:58 +0100 Subject: [Image-SIG] PIL video capture extension type problem Message-ID: <3C7CFA86.1080407@iue.tuwien.ac.at> Rich Drewes wrote: > Hello, > > I'm trying to write a C extension that simply takes a PIL > image as an argument and fills it in with data grabbed > from a video capture device. I wrote a C extension which can capture images from a video device on Win32. The C extension requires DirectX 8 and just returns the raw data, but a thin wrapper module written in Python uses PIL to generate Images. http://stud4.tuwien.ac.at/~e9326522/VideoCapture/ Markus From in000818@students.univr.it Thu Feb 28 17:27:47 2002 From: in000818@students.univr.it (Colombari Omar) Date: Thu, 28 Feb 2002 18:27:47 +0100 (CET) Subject: [Image-SIG] ERROR IN CAM SHIFT ALGORITHM Message-ID: We have installed the open cv 0.0.9.3 under linux (Red Hat 7.0). The our video card is flush bus and we have a frame grabber. When we can start cvcsdemo software, the application give us an error: "Camera not found". We have tried to collegate our camera, but the error is the same. We have change the device from "/dev/video*" to "/dev/fbusmod", where the video card is installed. The source code return as an error in the file otherlibs/cvcam/scr/unix/cvvideo.cpp at line if(ioctl(descriptors[count], VIDIOCGCAP, &VidCap)==-1) { pthread_mutex_unlock(&ioctlmutex); break; } What can we do? Thank you a lot!!! UNIVERSITY OF VERONA (ITALY) |-----------------------------------| | | | Departmet of Computer science | | | |-----------------------------------|