From cgw@pgt.com  Wed Dec  9 16:48:21 1998
From: cgw@pgt.com (Charles G Waldman)
Date: Wed, 9 Dec 1998 11:48:21 -0500 (EST)
Subject: [Image-SIG] Python 1.5.2 core dumps on Linux
Message-ID: <13934.43477.42007.170617@janus.pgt.com>

On my Linux box, running Python 1.5.2b1 and PIL-0.3b2, I repeatably
get the following core-dump:

janus:~> python
Python 1.5.2b1 (#2, Nov 20 1998, 17:27:56)  [GCC 2.7.2.3] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import Image
>>> Image.fromstring()
Segmentation fault (core dumped)

janus:~> gdb `which python` core
GNU gdb 4.17
<gdb startup banner omitted>
Core was generated by `python'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libtermcap.so.2...done.
Reading symbols from /usr/lib/libtix4.1.8.0.so...done.
Reading symbols from /usr/lib/libtk8.0.so...done.
Reading symbols from /usr/lib/libtcl8.0.so...done.
Reading symbols from /lib/libm.so.5...done.
Reading symbols from /lib/libdl.so.1...done.
Reading symbols from /lib/libc.so.5...done.
Reading symbols from /lib/ld-linux.so.1...done.
Reading symbols from /usr/local/lib/python1.5/site-packages/PIL/_imaging.so...done.
Reading symbols from /usr/lib/libjpeg.so.6...done.
Reading symbols from /usr/lib/libz.so.1...done.
#0  0x8077563 in PyObject_Print (op=0x8111f7d, fp=0x80dde40, flags=0) at object.c:178
178                     else if (op->ob_type->tp_print == NULL) {
(gdb) where
#0  0x8077563 in PyObject_Print (op=0x8111f7d, fp=0x80dde40, flags=0) at object.c:178
#1  0x806f128 in PyFile_WriteObject (v=0x8111f7d, f=0x80e1650, flags=0)
    at fileobject.c:989
#2  0x807ea70 in eval_code2 (co=0x8109070, globals=0x80e17c8, locals=0x80e17c8, args=0x0, 
    argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, owner=0x0) at ceval.c:1028
#3  0x807d852 in PyEval_EvalCode (co=0x8109070, globals=0x80e17c8, locals=0x80e17c8)
    at ceval.c:322
#4  0x806371b in run_node (n=0x8108698, filename=0x80b9f3a "<stdin>", globals=0x80e17c8, 
    locals=0x80e17c8) at pythonrun.c:882
#5  0x8062c22 in PyRun_InteractiveOne (fp=0x80ddf00, filename=0x80b9f3a "<stdin>")
    at pythonrun.c:523
#6  0x8062a97 in PyRun_InteractiveLoop (fp=0x80ddf00, filename=0x80b9f3a "<stdin>")
    at pythonrun.c:467
#7  0x80629e7 in PyRun_AnyFile (fp=0x80ddf00, filename=0x80b9f3a "<stdin>")
    at pythonrun.c:444
#8  0x8054aea in Py_Main (argc=1, argv=0xbffff964) at main.c:286
#9  0x8054510 in main (argc=1, argv=0xbffff964) at python.c:12
#10 0x805448e in ___crt_dummy__ ()


The other system on my desk is a PC running Python 1.5.1 and the same
version of PIL.   It gives the expected behavior:

hermes:~$ python -i
Python 1.5.1 (#0, Apr 13 1998, 20:22:04) [MSC 32 bit (Intel)] on win32
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import Image
>>> Image.fromstring()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
TypeError: not enough arguments; expected 3, got 0
>>> 

There are two things different here - it's Windows rather than Linux
and it's Python 1.5.1 instead of 1.5.2b1.  I guess I have to do more
experiments to pin down which is the significant variable...



From fredrik@pythonware.com  Wed Dec  9 17:41:47 1998
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 9 Dec 1998 18:41:47 +0100
Subject: [Image-SIG] Re: [PSA MEMBERS] Python 1.5.2 core dumps on Linux
Message-ID: <00d701be239b$32f2f980$f29b12c2@pythonware.com>

>On my Linux box, running Python 1.5.2b1 and PIL-0.3b2, I repeatably
>get the following core-dump:

/.../
>#0  0x8077563 in PyObject_Print (op=0x8111f7d, fp=0x80dde40, flags=0) at object.c:178
>178                     else if (op->ob_type->tp_print == NULL) {

I came up with one bright idea after another, but they all
turned out to be bogus...  Guess I have to do some serious
testing to see if I can get the same behaviour...

Just one small question: does "op->ob_type" point to some-
thing strange, or is it NULL ?
 
Cheers /F
fredrik@pythonware.com
http://www.pythonware.com



From cgw@pgt.com  Wed Dec  9 17:57:10 1998
From: cgw@pgt.com (Charles G Waldman)
Date: Wed, 9 Dec 1998 12:57:10 -0500 (EST)
Subject: [Image-SIG] Re: [PSA MEMBERS] Python 1.5.2 core dumps on Linux
In-Reply-To: <00d701be239b$32f2f980$f29b12c2@pythonware.com>
References: <00d701be239b$32f2f980$f29b12c2@pythonware.com>
Message-ID: <13934.47606.993771.820552@janus.pgt.com>

Fredrik Lundh writes:

#0  0x8077563 in PyObject_Print (op=0x81084fd, fp=0x80dde40, flags=0) at object.c:178
178                     else if (op->ob_type->tp_print == NULL) {
(gdb) print op->ob_type
$1 = (PyTypeObject *) 0x6e697274
(gdb) print op->ob_type->tp_print
Cannot access memory at address 0x6e697290.
(gdb) 



From gstein@lyra.org  Wed Dec  9 21:08:18 1998
From: gstein@lyra.org (Greg Stein)
Date: Wed, 09 Dec 1998 13:08:18 -0800
Subject: [Image-SIG] Re: [PSA MEMBERS] Python 1.5.2 core dumps on Linux
References: <00d701be239b$32f2f980$f29b12c2@pythonware.com> <13934.47606.993771.820552@janus.pgt.com>
Message-ID: <366EE6C2.4E2F8F8@lyra.org>

Charles G Waldman wrote:
> 
> Fredrik Lundh writes:
> 
> #0  0x8077563 in PyObject_Print (op=0x81084fd, fp=0x80dde40, flags=0) at object.c:178
> 178                     else if (op->ob_type->tp_print == NULL) {
> (gdb) print op->ob_type
> $1 = (PyTypeObject *) 0x6e697274
> (gdb) print op->ob_type->tp_print
> Cannot access memory at address 0x6e697290.
> (gdb)

Something stomped on memory.

The obtype pointer corresponds to the characters 'nirt'. I find it rare
that "real" pointers only contain valid characters, so I'd say memory
was walked on.

-g

--
Greg Stein, http://www.lyra.org/


From fredrik@pythonware.com  Wed Dec  9 21:41:47 1998
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 9 Dec 1998 22:41:47 +0100
Subject: [Image-SIG] Re: [PSA MEMBERS] Python 1.5.2 core dumps on Linux
Message-ID: <004e01be23bc$baa45bf0$f29b12c2@pythonware.com>

Greg Stein wrote:
>> (gdb) print op->ob_type
>> $1 = (PyTypeObject *) 0x6e697274
>> (gdb) print op->ob_type->tp_print
>> Cannot access memory at address 0x6e697290.
>> (gdb)
>
>Something stomped on memory.
>
>The obtype pointer corresponds to the characters 'nirt'.

or "trin", if stored in little endian order (*).  Which is pretty
interesting, given that Charles was calling the "froms-trin-g"
function...

Hmm /F

*) I have to admit that Greg's slightly smarter than me anyway --
when I first saw Charles' mail, I noticed that the tp_print pointer
corresponded to "nir\220".  Sigh...



From fredrik@pythonware.com  Wed Dec  9 21:45:07 1998
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 9 Dec 1998 22:45:07 +0100
Subject: [Image-SIG] Re: [PSA MEMBERS] Python 1.5.2 core dumps on Linux
Message-ID: <006601be23bd$31e2c990$f29b12c2@pythonware.com>

>Charles G Waldman wrote:
>> 
>> Fredrik Lundh writes:
>> 
>> #0  0x8077563 in PyObject_Print (op=0x81084fd, fp=0x80dde40, flags=0) at object.c:178
>> 178                     else if (op->ob_type->tp_print == NULL) {
>> (gdb) print op->ob_type
>> $1 = (PyTypeObject *) 0x6e697274
>> (gdb) print op->ob_type->tp_print
>> Cannot access memory at address 0x6e697290.
>> (gdb)

By the way, I cannot seem to repeat this on my local
Linux box (still using RedHat 4.2)

Could this be glibc-related?

    /F




From da@skivs.ski.org  Thu Dec 10 18:01:05 1998
From: da@skivs.ski.org (David Ascher)
Date: Thu, 10 Dec 1998 10:01:05 -0800 (Pacific Standard Time)
Subject: [Image-SIG] GIF problems
Message-ID: <Pine.WNT.4.04.9812100948080.289-100000@rigoletto.ski.org>

What's the way to save a P mode image in a GIF-encoded string.  If I try:

  i.tostring('GIF')

I get:

  File "c:\Extras\PIL\Image.py", line 551, in save
    SAVE[string.upper(format)](self, fp, filename)
  File "c:\Extras\PIL\GifImagePlugin.py", line 229, in _save
    ImageFile._save(im, fp, [("gif", (0,0)+im.size, 0, RAWMODE[im.mode])])
  File "c:\Extras\PIL\ImageFile.py", line 223, in _save
    e = Image._getencoder(im.mode, e, a, im.encoderconfig)
  File "c:\Extras\PIL\Image.py", line 174, in _getencoder
    return apply(encoder, args + extra)
TypeError: illegal argument type for built-in operation

--david






From fredrik@pythonware.com  Thu Dec 10 18:16:15 1998
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Thu, 10 Dec 1998 19:16:15 +0100
Subject: [Image-SIG] Re: GIF problems
Message-ID: <00ed01be2469$2e1385f0$f29b12c2@pythonware.com>

David Ascher wrote:
>What's the way to save a P mode image in a GIF-encoded string.  If I try:
>
>  i.tostring('GIF')

if you want an entire GIF file, the right way
to do it is:

    fp = StringIO.StringIO()
    i.save(fp, "GIF")
    data = fp.getvalue()

but assuming you already knew that, and really
want to run the gif encoder (which produces
uncompressed LWZ data, but no headers), you
could try something like:

    data = i.tostring("gif", i.mode)

Cheers /F
fredrik@pythonware.com
http://www.pythonware.com



From da@skivs.ski.org  Thu Dec 10 18:14:52 1998
From: da@skivs.ski.org (David Ascher)
Date: Thu, 10 Dec 1998 10:14:52 -0800 (Pacific Standard Time)
Subject: [Image-SIG] Re: GIF problems
In-Reply-To: <00ed01be2469$2e1385f0$f29b12c2@pythonware.com>
Message-ID: <Pine.WNT.4.04.9812101013580.289-100000@rigoletto.ski.org>

On Thu, 10 Dec 1998, Fredrik Lundh wrote:

> if you want an entire GIF file, the right way
> to do it is:
> 
>     fp = StringIO.StringIO()
>     i.save(fp, "GIF")

That line produces the same error:

    i.save(fp, "GIF")
  File "c:\Extras\PIL\Image.py", line 551, in save
    SAVE[string.upper(format)](self, fp, filename)
  File "c:\Extras\PIL\GifImagePlugin.py", line 229, in _save
    ImageFile._save(im, fp, [("gif", (0,0)+im.size, 0, RAWMODE[im.mode])])
  File "c:\Extras\PIL\ImageFile.py", line 209, in _save
    e = Image._getencoder(im.mode, e, a, im.encoderconfig)
  File "c:\Extras\PIL\Image.py", line 174, in _getencoder
    return apply(encoder, args + extra)
TypeError: illegal argument type for built-in operation

>     data = fp.getvalue()
> 
> but assuming you already knew that, and really
> want to run the gif encoder (which produces
> uncompressed LWZ data, but no headers), you
> could try something like:
> 
>     data = i.tostring("gif", i.mode)

same here.





From vkissoyan@dc.usweb.com  Thu Dec 10 22:00:16 1998
From: vkissoyan@dc.usweb.com (Vaskin Kissoyan)
Date: Thu, 10 Dec 1998 17:00:16 -0500
Subject: [Image-SIG] need to covert from gif to jpeg
Message-ID: <F44CAC672F4DD211A46200A0C9D8568708930F@moog.dc.usweb.com>

using the 1.4 version of the compiled python with tk and pil

This is not working! help!


import os, sys
import Image
import glob

for infile in glob.glob("*.gif"):
	outfile = os.path.splitext(infile)[0] + ".jpg"
	if infile != outfile:
		try:
			im = Image.open(infile)
			print im.format, "%dx%d" % im.size, im.mode
			im.save(outfile, ")
		except IOError:
			print "cannot convert", infile





VASKIN H KISSOYAN
Senior Architect, USWeb DC
-----------------------------------------------------------
USWeb Corporation    http://www.usweb.com/
7220 Wisconsin Ave, Suite 300
Bethesda, MD  20814
ph: 301.652.5250 x 298 

A Strategic Partner for the Information Age





From fredrik@pythonware.com  Fri Dec 11 10:01:32 1998
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 11 Dec 1998 11:01:32 +0100
Subject: [Image-SIG] need to covert from gif to jpeg
Message-ID: <005a01be24ed$f7a705c0$f29b12c2@pythonware.com>

>using the 1.4 version of the compiled python with tk and pil

if you can, get a more recent version!

> im = Image.open(infile)
> print im.format, "%dx%d" % im.size, im.mode
> im.save(outfile, ")

PIL usually avoids implicit mode conversions; in this
case, you have to spell it out yourself:

    im.convert("RGB").save(outfile)

Cheers /F
fredrik@pythonware.com
http://www.pythonware.com




From tom.schwaller@linux-magazin.de  Fri Dec 11 11:04:19 1998
From: tom.schwaller@linux-magazin.de (Tom Schwaller)
Date: Fri, 11 Dec 1998 12:04:19 +0100
Subject: [Image-SIG] need to covert from gif to jpeg
References: <005a01be24ed$f7a705c0$f29b12c2@pythonware.com>
Message-ID: <3670FC33.B475EA32@linux-magazin.de>

Fredrik Lundh wrote:
> PIL usually avoids implicit mode conversions; in this
> case, you have to spell it out yourself:
> 
>     im.convert("RGB").save(outfile)

And how does the converson from a GIF or JPG
to a grayscale compressed TIFF work? 
Is that possible with PIL?

-- 

Tom


From cgw@pgt.com  Tue Dec 22 17:25:46 1998
From: cgw@pgt.com (Charles G Waldman)
Date: Tue, 22 Dec 1998 12:25:46 -0500 (EST)
Subject: [Image-SIG] Re: [PSA MEMBERS] Python 1.5.2 core dumps on Linux
Message-ID: <13951.54810.752639.673125@janus.pgt.com>

Me:
 > #0  0x8077563 in PyObject_Print (op=0x81084fd, fp=0x80dde40, flags=0) at object.c:178
 > 178                     else if (op->ob_type->tp_print == NULL) {
 > (gdb) print op->ob_type
 > $1 = (PyTypeObject *) 0x6e697274
 > (gdb) print op->ob_type->tp_print
 > Cannot access memory at address 0x6e697290.
 > (gdb)

Greg Stein:
 > Something stomped on memory.
 >
 > The obtype pointer corresponds to the characters 'nirt'. I find it rare
 > that "real" pointers only contain valid characters, so I'd say memory
 > was walked on.

We can close the books on this one.  This was also due to eval_code2
not setting "retval" to NULL.  I had been using an out-of-date CVS
tree (shame on me!).  This problem is not present in the current
version of ceval.c (2.159).




From fredrik@pythonware.com  Wed Dec 30 18:02:32 1998
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 30 Dec 1998 19:02:32 +0100
Subject: [Image-SIG] PRE-ANNOUNCEMENT: PIL 1.0 beta 1
Message-ID: <00db01be341e$94dd31e0$f29b12c2@pythonware.com>

the code base for PIL 1.0b1 (formerly known as
0.3b3, or "The Library That's Always In Beta") is
now frozen on Windows.  we'll test it on a few
Unix boxes early next week, and a source kit
should be available before the end of next
week.

...

from the CHANGES file:

-- colour quantization (that is, select the best
possible palette for a given true colour image,
or for a group of images)
-- bilinear and bicubic interpolation
-- fancy new transforms: quad, mesh
-- arc, chord, pieslice, ellipse drawing primitives
-- xv thumbnail reader
-- tons of bug fixes
-- no need to hack Tk to make it display PIL
images (if you have Python 1.5.2, at least, and
don't care that much about best possible per-
formance...)

many thanks to all contributors (you know
who you are!)

...

the final 1.0 version should be out there
before the end of January.

...and a happy new year to you all...

Cheers /F
http://www.pythonware.com/people/fredrik



From akuchlin@cnri.reston.va.us  Tue Dec 29 15:00:16 1998
From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling)
Date: Tue, 29 Dec 1998 10:00:16 -0500 (EST)
Subject: [Image-SIG] Minor SANE changes for PIL 1.0
Message-ID: <13960.60066.608433.634839@amarok.cnri.reston.va.us>

<<< No Message Collected >>>


From akuchlin@cnri.reston.va.us  Wed Dec 30 21:05:31 1998
From: akuchlin@cnri.reston.va.us (Andrew M. Kuchling)
Date: Wed, 30 Dec 1998 16:05:31 -0500 (EST)
Subject: [Image-SIG] Minor SANE changes for PIL 1.0
In-Reply-To: <13960.60066.608433.634839@amarok.cnri.reston.va.us>
References: <13960.60066.608433.634839@amarok.cnri.reston.va.us>
Message-ID: <13962.38063.283687.925384@amarok.cnri.reston.va.us>

Andrew M. Kuchling writes:
><<< No Message Collected >>>

No, I'm not insane -- a name server problem at CNRI caused all my
e-mails to build up in the mail queue, and there were some
problems. :)

	The purpose of the original message was to say that I'd made
some changes to the SANE module on my Web page, both my own work and a
patch from Lorenzo Catucci, and that the copy of the code in PIL can
be updated accordingly. (The message also asked about the schedule for
PIL 1.0, but that question is now happily irrelevant.)

-- 
A.M. Kuchling			http://starship.skyport.net/crew/amk/
    Mary had a little key - she kept it in escrow,
    and every thing that Mary said, the feds were sure to know.
    -- Sam Simpson