From fredrik@pythonware.com  Wed Sep  1 09:17:08 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 1 Sep 1999 10:17:08 +0200
Subject: [Image-SIG] pixmap error
References: <107503.199908262300@olib>
Message-ID: <02e201bef452$a5e3add0$f29b12c2@secret.pythonware.com>

<N.B.Price@exeter.ac.uk> wrote:
> undefined symbol XFreePixMap

add -lX11 to the link line in Setup[.in].

(this has been fixed in 1.0.1)

</F>



From fredrik@pythonware.com  Wed Sep  1 09:47:36 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 1 Sep 1999 10:47:36 +0200
Subject: [Image-SIG] ImageDraw not working ( for me )
References: <37CBD6D9.77612C2D@on-ramp.ior.com>
Message-ID: <033e01bef456$e6ef9ba0$f29b12c2@secret.pythonware.com>

phil wilshire <philwil@on-ramp.ior.com> wrote:
> I am looking at a simple example almost out of the book.

> import Image, ImageDraw, ImagePalette
> 
> #im = Image.new('P',(300,200),100)
> im = Image.open("lena.jpg")
> draw = ImageDraw.Draw(im)
> pal = ImagePalette.ImagePalette
> draw.setink(128)
> 
> #print draw.ink
> #print draw.im
> 
> draw.line((0,0),im.size)

try

draw.line((0, 0) + im.size)

(the example in the documentation is still broken,
it seems.  updated docs is coming soon).

</F>



From pels@bio.uva.nl  Wed Sep  1 10:12:00 1999
From: pels@bio.uva.nl (bas pels)
Date: Wed, 01 Sep 1999 11:12:00 +0200
Subject: [Image-SIG] Re: ImageDraw not working
References: <199909010502.BAA14375@python.org>
Message-ID: <37CCEDE0.7E337CA6@bio.uva.nl>

> I am looking at a simple example almost out of the book.
> 
> import Image, ImageDraw, ImagePalette
> 
> #im = Image.new('P',(300,200),100)
> im = Image.open("lena.jpg")
> draw = ImageDraw.Draw(im)
> pal = ImagePalette.ImagePalette
> draw.setink(128)
> 
> #print draw.ink
> #print draw.im
> 
> draw.line((0,0),im.size)
> 
> I get the following error.
> 
> Traceback (innermost last):
>   File "t.py", line 14, in ?
>     draw.line((0,0),im.size)
>   File "/usr/local/lib/python1.5/site-packages/PIL/ImageDraw.py", line
> 107, in line
>     ink, fill = self._getink(fill)
>   File "/usr/local/lib/python1.5/site-packages/PIL/ImageDraw.py", line
> 73, in _getink
>     ink = self.im.draw_ink(ink)
> TypeError: illegal argument type for built-in operation
> 


hi,
a couple of days ago i arrived at the same problem.
for one or another reason, the draw objects (line, rectangle etc)
now require a single tuple for the xy coordinates.

draw.line((0,0,im.size))     or
draw.line(((0,0),im.size))

should do the job.

ciao,
bas


......................................................................
bas pels
university of amsterdam
section population biology
kruislaan 320, 1098 sm amsterdam                  fax: +31 20 525 7754
the netherlands                                   tel: +31 20 525 7743


From fredrik@pythonware.com  Wed Sep  1 13:13:40 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 1 Sep 1999 14:13:40 +0200
Subject: [Image-SIG] Bezier, or any other way to draw closed pictures made of curves?
References: <19990831161155.A5466@webcom.com>
Message-ID: <001701bef473$6f000040$f29b12c2@secret.pythonware.com>

Lalo Martins <lalo@webcom.com> wrote:
> The major thing I miss in ImageDraw is some way of drawing
> closed, filled pictures composed of curves (like `polygon' lets
> me draw pictures composed of straight lines). One possible way
> to do that would be simply adding a floodfill function, so I
> draw the picture with individual lines then fill it - one way,
> but not the best :-)

luckily, I managed to fix my time machine (with a little
help from Skalman), and added it to the 1.0 release.

import ImageDraw

s = ImageDraw.Outline()
s.move(0, 0)
s.curve(0, 100, 100, 100, 100, 0)
s.line(0, 0)

d = ImageDraw.Draw(im)
d.shape(s, fill=1)

this is of course highly experimental (and you may hurt
your eyes if you look at the code), so you better not
tell anyone about it... ;-)

</F>



From fredrik@pythonware.com  Wed Sep  1 13:54:03 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 1 Sep 1999 14:54:03 +0200
Subject: [Image-SIG] Bezier, or any other way to draw closed pictures made of curves?
References: <19990831161155.A5466@webcom.com>
Message-ID: <000e01bef479$12355da0$f29b12c2@secret.pythonware.com>

Lalo Martins <lalo@webcom.com> also wrote:
> On an unrelated note, is someone officially responsible for the
> documentation? As a way of showing my appreciation for you guys
> splitting imageTk off, I'd like to finish the documentation for
> the modules I'm using (currently that would be ImageDraw and
> PsDraw). It's pretty straightforward to do, and I already
> documented them anyway for the documentation of my project.

just send it to me, and I'll make sure it's
added to the master docs (plain text is
preferred).

</F>



From Anthony Baxter <anthony@interlink.com.au>  Thu Sep  2 12:22:38 1999
From: Anthony Baxter <anthony@interlink.com.au> (Anthony Baxter)
Date: Thu, 02 Sep 1999 21:22:38 +1000
Subject: [Image-SIG] PIL 1.0 as a package
In-Reply-To: Message from "Fredrik Lundh" <fredrik@pythonware.com>
 of "Thu, 26 Aug 1999 12:11:34 +0200." <002801beefab$fde434b0$f29b12c2@secret.pythonware.com>
Message-ID: <199909021122.VAA12147@mbuna.arbhome.com.au>

If you nuke the PIL.pth file (to remove the ImageFile.py clash with Zope)
you can no longer autoload ImagePlugin.py files.  I found that as a quick
workaround, to change Image.py so that instead of looking in sys.path[n],
it instead looks in sys.path[n]+"/PIL" for the files.

Could something like this be considered for the next release?

ta,
Anthony


From vball@erols.com  Thu Sep  2 16:38:22 1999
From: vball@erols.com (Michael Perry)
Date: Thu, 02 Sep 1999 11:38:22 -0400
Subject: [Image-SIG] OpenGL
Message-ID: <37CE99EE.36D3B3ED@erols.com>

Hello,

I'm trying to load Pyopengl on Redhat Linux 6.0.  I've got
python-opengl-1.5.5-2.i386.rpm and get errors from these lib's:

error: failed dependencies:
 libMesaGL.so.3 is needed by python-opengl-1.5.5-2
 libMesaGLU.so.3 is needed by python-opengl-1.5.5-2
 libglut.so.3 is needed by python-opengl-1.5.5-2


I'm attempting to load the package with, rpm -vv -i
python-opengl-1.5.5-2.i386.rpm as root

These are the python packages currently loaded:
$ rpm -qa | grep -i pyt
python-docs-1.5.1-10
python-imaging-1.0b1-3
python-1.5.1-10
pythonlib-1.22-5
python-HTMLgen-2.1-4
python-numpy-1.11-2
python-demos-1.5.2-2


Seems like I need something else but I'm not sure what?



From da@ski.org  Thu Sep  2 17:15:26 1999
From: da@ski.org (David Ascher)
Date: Thu, 2 Sep 1999 09:15:26 -0700 (Pacific Daylight Time)
Subject: [Image-SIG] OpenGL
In-Reply-To: <37CE99EE.36D3B3ED@erols.com>
Message-ID: <Pine.WNT.4.04.9909020913090.181-100000@rigoletto.ski.org>

On Thu, 2 Sep 1999, Michael Perry wrote:

> Hello,
> 
> I'm trying to load Pyopengl on Redhat Linux 6.0.  I've got
> python-opengl-1.5.5-2.i386.rpm and get errors from these lib's:

1) This is the wrong list to bring this up.  Instead, try the PyOpenGL
   mailing list http://www.egroups.com/group/pyopengl/

> error: failed dependencies:
>  libMesaGL.so.3 is needed by python-opengl-1.5.5-2
>  libMesaGLU.so.3 is needed by python-opengl-1.5.5-2
>  libglut.so.3 is needed by python-opengl-1.5.5-2

2) This suggests that your Linux doesn't have Mesa or GLUT installed.  I
   don't know what the RPM names are for those, sorry.

   (someone on the pyopengl may have more information)

--david



From lalo@webcom.com  Thu Sep  2 18:22:47 1999
From: lalo@webcom.com (Lalo Martins)
Date: Thu, 2 Sep 1999 14:22:47 -0300
Subject: [Image-SIG] Bezier, or any other way to draw closed pictures made of curves?
In-Reply-To: <001701bef473$6f000040$f29b12c2@secret.pythonware.com>; from Fredrik Lundh on Wed, Sep 01, 1999 at 02:13:40PM +0200
References: <19990831161155.A5466@webcom.com> <001701bef473$6f000040$f29b12c2@secret.pythonware.com>
Message-ID: <19990902142247.A11218@webcom.com>

On Wed, Sep 01, 1999 at 02:13:40PM +0200, Fredrik Lundh wrote:
> 
> luckily, I managed to fix my time machine (with a little
> help from Skalman), and added it to the 1.0 release.
> 
> import ImageDraw
> 
> s = ImageDraw.Outline()
> s.move(0, 0)
> s.curve(0, 100, 100, 100, 100, 0)
> s.line(0, 0)
> 
> d = ImageDraw.Draw(im)
> d.shape(s, fill=1)

Wow, you're so great :-) I will try it out on the weekend. I
will also document it, you may save the part on it for later
when it's stable.

[]s,
                                               |alo
                                               +----
--
      I am Lalo of deB-org. You will be freed.
                 Resistance is futile.

http://www.webcom.com/lalo      mailto:lalo@webcom.com
                 pgp key in the web page

Debian GNU/Linux       --        http://www.debian.org



From lalo@webcom.com  Thu Sep  2 18:25:39 1999
From: lalo@webcom.com (Lalo Martins)
Date: Thu, 2 Sep 1999 14:25:39 -0300
Subject: [Image-SIG] Bezier, or any other way to draw closed pictures made of curves?
In-Reply-To: <000e01bef479$12355da0$f29b12c2@secret.pythonware.com>; from Fredrik Lundh on Wed, Sep 01, 1999 at 02:54:03PM +0200
References: <19990831161155.A5466@webcom.com> <000e01bef479$12355da0$f29b12c2@secret.pythonware.com>
Message-ID: <19990902142538.B11218@webcom.com>

On Wed, Sep 01, 1999 at 02:54:03PM +0200, Fredrik Lundh wrote:
> Lalo Martins <lalo@webcom.com> also wrote:
> > [interest on helping with *Draw documentation]
> 
> just send it to me, and I'll make sure it's
> added to the master docs (plain text is
> preferred).

Ok, I'll fetch the current ones from the sources and take them
home, then if I don't go to the beach on the weekend (Sep. 7 is
Independence Day in Brazil) you'll receive the docs by Wed.

[]s,
                                               |alo
                                               +----
--
      I am Lalo of deB-org. You will be freed.
                 Resistance is futile.

http://www.webcom.com/lalo      mailto:lalo@webcom.com
                 pgp key in the web page

Debian GNU/Linux       --        http://www.debian.org



From Fred L. Drake, Jr." <fdrake@acm.org  Fri Sep  3 19:15:14 1999
From: Fred L. Drake, Jr." <fdrake@acm.org (Fred L. Drake, Jr.)
Date: Fri, 3 Sep 1999 14:15:14 -0400 (EDT)
Subject: [Image-SIG] PIL 1.0 as a package
In-Reply-To: <199909021122.VAA12147@mbuna.arbhome.com.au>
References: <fredrik@pythonware.com>
 <002801beefab$fde434b0$f29b12c2@secret.pythonware.com>
 <199909021122.VAA12147@mbuna.arbhome.com.au>
Message-ID: <14288.4146.962346.514063@weyr.cnri.reston.va.us>

Anthony Baxter writes:
 > If you nuke the PIL.pth file (to remove the ImageFile.py clash with Zope)
 > you can no longer autoload ImagePlugin.py files.  I found that as a quick
 > workaround, to change Image.py so that instead of looking in sys.path[n],
 > it instead looks in sys.path[n]+"/PIL" for the files.

  The "right" approach to doing this for packages would be to select
the search path this way:

    import sys
    try:
        path = __path__
    except NameError:
        path = sys.path

path will be set to the "right thing" after this, and will be a lot
faster to search if __path__ is defined (because it'll be shorter; for 
PIL, just one entry!).


  -Fred

--
Fred L. Drake, Jr.	     <fdrake@acm.org>
Corporation for National Research Initiatives


From kernr@ncifcrf.gov  Fri Sep 10 02:44:03 1999
From: kernr@ncifcrf.gov (Robert Kern)
Date: Thu, 09 Sep 1999 21:44:03 -0400
Subject: [Image-SIG] PIL font file format?
Message-ID: <37D86263.A7C095C0@mail.ncifcrf.gov>

Can anyone give me a brief rundown of the information that should be in 
the DATA section of a PIL font?

FYI, I am almost finished with wrapping FreeType, a TrueType rendering
engine, and I would like to write a TtfFontFile.py to handle converting
from TrueType to the PIL font format, but I can't glean from the source
of FontFile.py (or BdfFontFile or PcfFontFile) what information is 
necessary for each glyph.

-- 
Robert Kern           |
----------------------|"In the fields of Hell where the grass grows high
This space            | Are the graves of dreams allowed to die."
intentionally         |           - Richard Harter
left blank.           |


From hannu@tm.ee  Fri Sep 10 07:27:02 1999
From: hannu@tm.ee (Hannu Krosing)
Date: Fri, 10 Sep 1999 09:27:02 +0300
Subject: [Image-SIG] PIL font file format?
References: <37D86263.A7C095C0@mail.ncifcrf.gov>
Message-ID: <37D8A4B6.A53C09C6@tm.ee>

Robert Kern wrote:
> 
> Can anyone give me a brief rundown of the information that should be in
> the DATA section of a PIL font?

You could look at bdf2pil.py in Scripts subdirectory. 
At least it used to be there ..
 
-------------
Hannu


From kernr@ncifcrf.gov  Fri Sep 10 08:11:14 1999
From: kernr@ncifcrf.gov (Robert Kern)
Date: Fri, 10 Sep 1999 03:11:14 -0400
Subject: [Image-SIG] PIL font file format?
References: <37D86263.A7C095C0@mail.ncifcrf.gov> <37D8A4B6.A53C09C6@tm.ee>
Message-ID: <37D8AF12.9401199@mail.ncifcrf.gov>

Hannu Krosing wrote:
> 
> Robert Kern wrote:
> >
> > Can anyone give me a brief rundown of the information that should be in
> > the DATA section of a PIL font?
> 
> You could look at bdf2pil.py in Scripts subdirectory.
> At least it used to be there ..

I've looked at FontFile.py, BdfFontFile.py, and PcfFontFile.py, but the
source is just too cryptic for me without comments that say what x, y,
l, d, etc. are supposed to stand for.

I think I might be able to figure it out from learning the BDF format 
and comparing that with how BdfFontFile.py parses, but since *someone*
here must know it, I decided to ask first.  :-)

> -------------
> Hannu

-- 
Robert Kern           |
----------------------|"In the fields of Hell where the grass grows high
This space            | Are the graves of dreams allowed to die."
intentionally         |           - Richard Harter
left blank.           |


From schorsch@schorsch.com  Sun Sep 12 19:50:09 1999
From: schorsch@schorsch.com (Georg Mischler)
Date: Sun, 12 Sep 1999 14:50:09 -0400 (EDT)
Subject: [Image-SIG] first results: floating point color in PIL
Message-ID: <Pine.BSF.4.10.9909121440580.7285-100000@emancholl.pair.com>

Hi again, 

my last bunch of questions resulted in some encouraging
messages by private mail, so I decided to just give it a
try instead of waiting for someone to tell me what to do.

The result can be admired in my starship cabin:

  http://starship.python.net/crew/schorsch/pilray.html

This document has all the documentation and a download
link for my patches and extensions. Anyone who is interested
in this topic please have a look at it and tell me what you 
think. 


Have fun!

-schorsch

-- 
Georg Mischler  --  simulation developper  --  schorsch at schorsch.com
+schorsch.com+  --  lighting design tools  --  http://www.schorsch.com/



From davidws@csmctmto.interpoint.net  Wed Sep 15 21:29:48 1999
From: davidws@csmctmto.interpoint.net (#!/usr/bin/entropy --why-me)
Date: Wed, 15 Sep 1999 16:29:48 -0400 (EDT)
Subject: [Image-SIG] GGI libImaging target
Message-ID: <199909152029.QAA12619@csmctmto.interpoint.net>

Hello,

	Has anyone ported the libImaging stuff to GGI
(www.ggi-project.org) ? If not, I was going to. 

David







From davidws@csmctmto.interpoint.net  Wed Sep 15 21:34:57 1999
From: davidws@csmctmto.interpoint.net (#!/usr/bin/entropy --why-me)
Date: Wed, 15 Sep 1999 16:34:57 -0400 (EDT)
Subject: [Image-SIG] libImaging questions
Message-ID: <199909152034.QAA12649@csmctmto.interpoint.net>

Hello,

	Where can I find information regarding the modes 
("1", "L", "P", "RGB", "RGBA", "CMYK") and what they mean.
I can guess RGB, RGBA but what is the difference between 1 and L 
and CMYK ?

Thanks,

david


From deirdre@deirdre.net  Wed Sep 15 21:47:13 1999
From: deirdre@deirdre.net (Deirdre Saoirse)
Date: Wed, 15 Sep 1999 13:47:13 -0700 (PDT)
Subject: [Image-SIG] libImaging questions
In-Reply-To: <199909152034.QAA12649@csmctmto.interpoint.net>
Message-ID: <Pine.LNX.4.10.9909151344510.2636-100000@adelie.deirdre.org>

CMYK = cyan, magenta, yellow, black

In other words, a way of representing color as a percentage of the four
colors used in offset printing.

On Wed, 15 Sep 1999, #!/usr/bin/entropy --why-me wrote:

> Hello,
> 
> 	Where can I find information regarding the modes 
> ("1", "L", "P", "RGB", "RGBA", "CMYK") and what they mean.
> I can guess RGB, RGBA but what is the difference between 1 and L 
> and CMYK ?
-- 
_Deirdre   *   http://www.linuxcabal.net   *   http://www.deirdre.net
"I must say that I was really happy to see _Linux for Dummies_ -- that's 
when you know you've arrived." -- Linus Torvalds



From fredrik@pythonware.com  Wed Sep 15 22:32:35 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 15 Sep 1999 23:32:35 +0200
Subject: [Image-SIG] libImaging questions
References: <199909152034.QAA12649@csmctmto.interpoint.net>
Message-ID: <007a01beffc1$f285f970$f29b12c2@secret.pythonware.com>

> Where can I find information regarding the modes 
> ("1", "L", "P", "RGB", "RGBA", "CMYK") and what they mean.
> I can guess RGB, RGBA but what is the difference between 1 and L 
> and CMYK ?

reading the documentation might help:
http://www.pythonware.com/library/pil/handbook/concepts.htm

</F>



From fredrik@pythonware.com  Wed Sep 15 22:36:01 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 15 Sep 1999 23:36:01 +0200
Subject: [Image-SIG] PIL font file format?
References: <37D86263.A7C095C0@mail.ncifcrf.gov>
Message-ID: <009e01beffc2$bb711040$f29b12c2@secret.pythonware.com>

Robert Kern <kernr@ncifcrf.gov> wrote:
> FYI, I am almost finished with wrapping FreeType, a TrueType rendering
> engine, and I would like to write a TtfFontFile.py to handle converting
> from TrueType to the PIL font format, but I can't glean from the source
> of FontFile.py (or BdfFontFile or PcfFontFile) what information is 
> necessary for each glyph.

a better approach might be to provide a FreeTypeFont
object, which implements the ImageFont interface:

http://www.pythonware.com/library/pil/handbook/imagefont.htm

to render such fonts, simply pass FreeTypeFont instances
to ImageDraw's setfont method.

</F>



From guido@CNRI.Reston.VA.US  Thu Sep 16 19:53:52 1999
From: guido@CNRI.Reston.VA.US (Guido van Rossum)
Date: Thu, 16 Sep 1999 14:53:52 -0400
Subject: [Image-SIG] Reminder: Python Conference papers due soon!
Message-ID: <199909161853.OAA01738@eric.cnri.reston.va.us>

The deadline for paper submissions for the next Python conference is
nearing!  Make sure that if you are considering submitting a paper,
the program chair sees your paper by SEPTEMBER 30.  Papers can be on
any Python, JPython or Zope related subject.  Papers will be reviewed
and the best papers will be selected for presentation.  You will hear
about selection by October 22.

For more information, see the official call for papers:
http://www.python.org/workshops/2000-01/cfp.html

** We are planning a significant Zope presence at this conference! **

The conference will be held from January 24-27 in Alexandria, VA (just
across the Potomac from DC).  Make Python the first conference in the
new millennium you visit!  For more info, see the conference home
page: http://www.python.org/workshops/2000-01/

Send all email questions about papers to: ipc8papers@cs.uchicago.edu

--Guido van Rossum (home page: http://www.python.org/~guido/)

(And sorry for the broad spamming.)



From schorsch@schorsch.com  Tue Sep 21 19:22:17 1999
From: schorsch@schorsch.com (Georg Mischler)
Date: Tue, 21 Sep 1999 14:22:17 -0400 (EDT)
Subject: [Image-SIG] PIL buglet?
Message-ID: <Pine.BSF.4.10.9909211256150.14298-100000@emancholl.pair.com>

Hi all,

it looks as if I just found a tiny bug in PIL 1.0.

In Imaging.h, the ImagingMemoryInstance is defined as:

struct ImagingMemoryInstance {

    /* Format */
    char mode[4+1];	/* Band names ("1", "L", "P", "RGB", "RGBA", "CMYK") */
    int type;		/* Data type */
    int depth;		/* Depth (ignored in this version) */
    int bands;	
...

This allows for mode designators up to 4 characters in length.
Unfortunately, some of the modes implemented in Storage.c
have names of up to 6 characters, which may (or may not,
depending on your compiler) overwrite the type member.
Most of those modes (except YCbCr) are marked as experimental,
and I didn't use any of them. But finding stuff like this
is probably still a part of that experiment.

I had some strange interactions with tkImaging, which seemed
to depend on the layout of the ImagingMemoryInstance. This
surfaced on linux when I tried to add another member (which I
don't to anymore). If the new member was in the "wrong" position
within the struct, then the image would get displayed
completely garbled. Now I had another effect on Solaris 2.4,
which resulted in images displayed with a strong blue tint.
In this case, I had made no changes to ImagingMemoryInstance.

I don't know if those effects have in fact anything to do
with the above buglet, but once I changed the definition
to "char mode[8];" and recompiled, the solaris blues went
away immediately. There may be other hidden dependencies
that were resolved by the recompile (it would be nice, if
the Makefile in the top level Imaging directory would
use Imaging.h and libImaging.a as conditions!), so I
can't say for sure what caused my funny results.

But even so, another bug removed is still a Good Thing... ;)


Have fun!

-schorsch

-- 
Georg Mischler  --  simulation developper  --  schorsch at schorsch.com
+schorsch.com+  --  lighting design tools  --  http://www.schorsch.com/



From schorsch@schorsch.com  Mon Sep 27 15:43:22 1999
From: schorsch@schorsch.com (Georg Mischler)
Date: Mon, 27 Sep 1999 10:43:22 -0400 (EDT)
Subject: [Image-SIG] TkImaging on SGI?
Message-ID: <Pine.BSF.4.10.9909271041090.17858-100000@emancholl.pair.com>

Hi all,

has anyone else had troubles with getting tkImaging to
work on a sgi box with the standard sgi compiler?
In my case, attempting to display an image would dump
a segmentation violation:

  Process 54208 (python) stopped on signal SIGSEGV: Segmentation violation (default) at [Tk_GetImageMasterData:781 ,0x5ff17120]
         Source (of ./../generic/tkImage.c) not available for Process 54208

Since some of the already installed libraries were compiled
that way, I had to use the -o32 option. Displaying images
with the Tk demos works fine, and PIL alone also doesn't
make any problems. The system is an O2 with irix 6.5 (I think
Python and Tk were compiled with an older OS version).

Any suggestions where to look for fixing the problem?


Thanks 

-schorsch

-- 
Georg Mischler  --  simulation developper  --  schorsch at schorsch.com
+schorsch.com+  --  lighting design tools  --  http://www.schorsch.com/



From godzilla@netmeg.net (Les Schaffer)  Mon Sep 27 21:55:52 1999
From: godzilla@netmeg.net (Les Schaffer) (Les Schaffer)
Date: Mon, 27 Sep 1999 16:55:52 -0400 (EDT)
Subject: [Image-SIG] ImageTk.PhotoImage vs. Tkinter.PhotoImage
In-Reply-To: <Pine.BSF.4.10.9909121440580.7285-100000@emancholl.pair.com>
References: <Pine.BSF.4.10.9909121440580.7285-100000@emancholl.pair.com>
Message-ID: <14319.55768.317546.946593@gargle.gargle.HOWL>

i need to zoom in on a user specified subset of an image. 

but i am confussed about ImageTk.PhotoImage and
Tkinter.PhotoImage. the former creates an instance of the latter in
its self.__photo, used for pasting. but i need access to
Tkinter.Photoimage's copy and zoom commands. i dont understand why
ImageTk.PhotoImage doesnt just extend Tkinter.PhotoImage so the copy
and zoom methods are available, or delegate those calls to __photo
methods.

also, i notice that in Tkinter.PhotoImage the -from and -to keywordd
for the image create methods are not explicitly defined. wonder
why....

this is my first real foray into using tkinter/PIL for some astro
work, so please excuse if my questions are stupid.


so, with code like this:

	...
        self.photo = ImageTk.PhotoImage(image)
        self.canvas.create_image(0, 0, image=self.photo, anchor=NW)
	...

i want to create a new PhotoImage consisting of a zoom in on a subset
of self.photo (i have the x,y coords of the desired zoom area in
self.photo).

-- 
____        Les Schaffer              ___| --->> Engineering R&D <<---
Theoretical & Applied Mechanics          |  Designspring, Inc. 
Center for Radiophysics & Space Research |  http://www.designspring.com/
Cornell Univ.  schaffer@tam.cornell.edu  |  les@designspring.com


From godzilla@netmeg.net (Les Schaffer)  Mon Sep 27 22:30:30 1999
From: godzilla@netmeg.net (Les Schaffer) (Les Schaffer)
Date: Mon, 27 Sep 1999 17:30:30 -0400 (EDT)
Subject: [Image-SIG] ImageTk.PhotoImage vs. Tkinter.PhotoImage
In-Reply-To: <14319.55768.317546.946593@gargle.gargle.HOWL>
References: <Pine.BSF.4.10.9909121440580.7285-100000@emancholl.pair.com>
 <14319.55768.317546.946593@gargle.gargle.HOWL>
Message-ID: <14319.57846.699553.36505@gargle.gargle.HOWL>

i mis-spoke:

> also, i notice that in Tkinter.PhotoImage the -from and -to keywordd
> for the image create methods are not explicitly defined
                ^^^^^^
                  copy       

that is, why doesnt PhotoImage.copy() implement the -from and -to
keywords?


-- 
____        Les Schaffer              ___| --->> Engineering R&D <<---
Theoretical & Applied Mechanics          |  Designspring, Inc. 
Center for Radiophysics & Space Research |  http://www.designspring.com/
Cornell Univ.  schaffer@tam.cornell.edu  |  les@designspring.com


From fredrik@pythonware.com  Wed Sep 29 11:32:09 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 29 Sep 1999 12:32:09 +0200
Subject: [Image-SIG] TkImaging on SGI?
References: <Pine.BSF.4.10.9909271041090.17858-100000@emancholl.pair.com>
Message-ID: <00f401bf0a65$e330bce0$f29b12c2@secret.pythonware.com>

Georg Mischler <schorsch@schorsch.com> wrote:
> has anyone else had troubles with getting tkImaging to
> work on a sgi box with the standard sgi compiler?
> In my case, attempting to display an image would dump
> a segmentation violation:
>
>   Process 54208 (python) stopped on signal SIGSEGV: Segmentation violation (default) at
[Tk_GetImageMasterData:781 ,0x5ff17120]
>          Source (of ./../generic/tkImage.c) not available for Process 54208
>
> Since some of the already installed libraries were compiled
> that way, I had to use the -o32 option. Displaying images
> with the Tk demos works fine, and PIL alone also doesn't
> make any problems. The system is an O2 with irix 6.5 (I think
> Python and Tk were compiled with an older OS version).
>
> Any suggestions where to look for fixing the problem?

if you've change the Imaging.h structure, you may
have to rebuild _tkinter (depending on where you've
placed the tkImage.c module).  If they doesn't match,
getting a segmentation violation down in tkImage is
quite likely.

</F>



From fredrik@pythonware.com  Wed Sep 29 11:29:41 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 29 Sep 1999 12:29:41 +0200
Subject: [Image-SIG] PIL buglet?
References: <Pine.BSF.4.10.9909211256150.14298-100000@emancholl.pair.com>
Message-ID: <00f301bf0a65$e32487e0$f29b12c2@secret.pythonware.com>

(it's wednesday! pil support day!)

Georg Mischler <schorsch@schorsch.com> wrote:
> In Imaging.h, the ImagingMemoryInstance is defined as:
> 
> struct ImagingMemoryInstance {
> 
>     /* Format */
>     char mode[4+1]; /* Band names ("1", "L", "P", "RGB", "RGBA", "CMYK") */
>     int type; /* Data type */
>     int depth; /* Depth (ignored in this version) */
>     int bands; 
> ...
> 
> This allows for mode designators up to 4 characters in length.
> Unfortunately, some of the modes implemented in Storage.c
> have names of up to 6 characters, which may (or may not,
> depending on your compiler) overwrite the type member.

oops.

luckily, it's "may not" on every modern platform
(up to seven characters is ok, thanks to integer
padding).

by various reasons, I'm very reluctant to change
the instance layout before the next major release,
so I guess we have to live with this buglet a while.
it shouldn't affect anything, as far as I can tell.

(which means that your problems must have
been caused by something else).

</F>



From fredrik@pythonware.com  Wed Sep 29 11:38:02 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 29 Sep 1999 12:38:02 +0200
Subject: [Image-SIG] ImageTk.PhotoImage vs. Tkinter.PhotoImage
References: <Pine.BSF.4.10.9909121440580.7285-100000@emancholl.pair.com> <14319.55768.317546.946593@gargle.gargle.HOWL>
Message-ID: <00fe01bf0a66$b8f43fa0$f29b12c2@secret.pythonware.com>

Les Schaffer <godzilla@netmeg.net> wrote:
> so, with code like this:
> 
> ...
>         self.photo = ImageTk.PhotoImage(image)
>         self.canvas.create_image(0, 0, image=self.photo, anchor=NW)
> ...
> 
> i want to create a new PhotoImage consisting of a zoom in on a subset
> of self.photo (i have the x,y coords of the desired zoom area in
> self.photo).

the easiest (and by far fastest) way to do this
is to keep a reference to the original PIL image,
and create a new ImageTk.PhotoImage instance
when necessary.

here's some (untested) sample code:

    ...

        self.image = image

        # display original image
        self.setimage(self.image)

        # display subregion
        im = self.image.transform(
            (512, 512), Image.EXTENT,
            (12.5, 12.5, 27.5, 27.5)
            )
        self.setimage(im)

    ...

    def setimage(self, image):
        self.photo = ImageTk.PhotoImage(image)
        self.canvas.delete("image")
        self.canvas.create_image(0, 0,
            image=self.photo,
            anchor=NW, tag="image"
            )

    ...

hope this helps!

</F>



From schorsch@schorsch.com  Wed Sep 29 12:10:30 1999
From: schorsch@schorsch.com (Georg Mischler)
Date: Wed, 29 Sep 1999 07:10:30 -0400 (EDT)
Subject: [Image-SIG] TkImaging on SGI?
In-Reply-To: <00f401bf0a65$e330bce0$f29b12c2@secret.pythonware.com>
Message-ID: <Pine.BSF.4.10.9909290657360.14609-100000@emancholl.pair.com>

> > Since some of the already installed libraries were compiled
> > that way, I had to use the -o32 option. Displaying images
> > with the Tk demos works fine, and PIL alone also doesn't
> > make any problems. The system is an O2 with irix 6.5 (I think
> > Python and Tk were compiled with an older OS version).
> >
> > Any suggestions where to look for fixing the problem?
> 
> if you've change the Imaging.h structure, you may
> have to rebuild _tkinter (depending on where you've
> placed the tkImage.c module).  If they doesn't match,
> getting a segmentation violation down in tkImage is
> quite likely.

This might explain some of the earlier funny errors I had,
which just mangled the images without dumping.
In this case here, the ImagingInstance is in its original
state (hmmm... except for the type string set to char[8]). 

Another post suggested to compile with -n32 consistently,
which the friendly sysop will make possible as reccommended.

Thinking of it: what happens when _tkinter isn't set up
for _imaging at all (is this still necessary?)?  Could
this cause a dump as well, or would it refuse to work
right away? I don't have root access to those systems,
so I haven't installed Python myself.

In any case, I think I hvae now three more places to look
for the source of the problem, one of which may well solve it.


Thanks so far!

-schorsch

-- 
Georg Mischler  --  simulation developper  --  schorsch at schorsch.com
+schorsch.com+  --  lighting design tools  --  http://www.schorsch.com/



From schorsch@schorsch.com  Wed Sep 29 12:27:06 1999
From: schorsch@schorsch.com (Georg Mischler)
Date: Wed, 29 Sep 1999 07:27:06 -0400 (EDT)
Subject: [Image-SIG] PIL as a package
Message-ID: <Pine.BSF.4.10.9909290710500.14609-100000@emancholl.pair.com>

Hi again,

(let's shoot everything at them as long as it's wednesday... ;)

I read somewhere that the current PIL release should work
equally well as plain modules (with PIL.pth) or as a package.
I may have misunderstood this, but the only problem I found
should be fairly easy to fix. The preinit() and init() methods
search for the plug-ins on sys.path. This fails if PIL is
installed as a package (I was fooled myself first, because I
still had a non-package installation around on my system...).

I think that searching in the directory where Image.py was
loaded from before trying the rest of sys.path would be a
satisfactory solution. In fact, it is quite likely (though
a tad less flexible) that the plug-ins should always be
loaded exclusively from this place. 

I'll try to wrap someting up and supply the result (unless
someone has already done something similar, and I just
haven't seen it).


-schorsch

-- 
Georg Mischler  --  simulation developper  --  schorsch at schorsch.com
+schorsch.com+  --  lighting design tools  --  http://www.schorsch.com/



From fredrik@pythonware.com  Wed Sep 29 12:49:49 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 29 Sep 1999 13:49:49 +0200
Subject: [Image-SIG] PIL as a package
References: <Pine.BSF.4.10.9909290710500.14609-100000@emancholl.pair.com>
Message-ID: <002201bf0a70$bc597f20$f29b12c2@secret.pythonware.com>

Georg Mischler <schorsch@schorsch.com> wrote:
> (let's shoot everything at them as long as it's wednesday... ;)

well, we won't guarantee that we'll answer
questions the same day :-)

> I read somewhere that the current PIL release should work
> equally well as plain modules (with PIL.pth) or as a package.
> I may have misunderstood this, but the only problem I found
> should be fairly easy to fix. The preinit() and init() methods
> search for the plug-ins on sys.path. This fails if PIL is
> installed as a package (I was fooled myself first, because I
> still had a non-package installation around on my system...).

Anthony Baxter pointed this out a while ago, and
Fred Drake came up with the following solution:

    import sys
    try:
        path = __path__
    except NameError:
        path = sys.path

which will be in the forthcoming maintenance
release (PIL 1.0.1).

(and yes, I also had a non-package installation on
my box -- and so did the person contributing the
original package fix, I suppose)

</F>



From godzilla@netmeg.net  Wed Sep 29 13:47:20 1999
From: godzilla@netmeg.net (Les Schaffer)
Date: Wed, 29 Sep 1999 08:47:20 -0400
Subject: [Image-SIG] Re: ImageTk.PhotoImage vs. Tkinter.PhotoImage
In-Reply-To: <00fe01bf0a66$b8f43fa0$f29b12c2@secret.pythonware.com>
References: <Pine.BSF.4.10.9909121440580.7285-100000@emancholl.pair.com>
 <14319.55768.317546.946593@gargle.gargle.HOWL>
Message-ID: <3.0.1.32.19990929084720.0090cd90@pop.netmeg.net>

At 12:38 PM 9/29/99 +0200, Comrade Fredrik Lundh opined:

->        # display subregion
->        im = self.image.transform(
->            (512, 512), Image.EXTENT,
->            (12.5, 12.5, 27.5, 27.5)
->            )
->        self.setimage(im)


my first solution was to use crop() followed by a resize(). will try the
transform() next for comparison.

still, the more illuminating topic would be why the parallel design of
PhotoImage in both Tkinter and ImageTk? why doesnt the latter inherit the
former. why do they co-exist side by side?

PIL is one great package. i am already doing useful stuff one day after
"""""learning""""" PIL.

les



From pas@scansoft.com  Wed Sep 29 19:04:37 1999
From: pas@scansoft.com (Perry Stoll)
Date: Wed, 29 Sep 1999 14:04:37 -0400 (EDT)
Subject: [Image-SIG] PIL buglet?
In-Reply-To: <00f301bf0a65$e32487e0$f29b12c2@secret.pythonware.com>
Message-ID: <Pine.LNX.4.10.9909291355570.7673-100000@kyoto.scansoft.com>

On Wed, 29 Sep 1999, Fredrik Lundh wrote:

    (it's wednesday! pil support day!)
    
    Georg Mischler <schorsch@schorsch.com> wrote:
    > In Imaging.h, the ImagingMemoryInstance is defined as:
    > 
    > struct ImagingMemoryInstance {
    > 
    >     /* Format */
    >     char mode[4+1]; /* Band names ("1", "L", "P", "RGB", "RGBA", "CMYK") */
    >     int type; /* Data type */
    >     int depth; /* Depth (ignored in this version) */
    >     int bands; 
    > ...
    > 
    > This allows for mode designators up to 4 characters in length.
    > Unfortunately, some of the modes implemented in Storage.c
    > have names of up to 6 characters, which may (or may not,
    > depending on your compiler) overwrite the type member.
    
    oops.
    
    luckily, it's "may not" on every modern platform
    (up to seven characters is ok, thanks to integer
    padding).

Grrr...that's completely compiler dependent, e.g. MSVC has a switch to
modify the default padding size, which is a (moderately) reasonable thing
to do.

    I 'm very reluctant to change
    the instance layout before the next major release,
    so I guess we have to live with this buglet a while.
    it shouldn't affect anything, as far as I can tell.

Can you explain why you are reluctant to change something that is
obviously broken and dangerous, and is going to cause mysterious and hard
to trace errors? There are enough undiscovered bug's out there - let's
squash the ones we can.

Going back to debugging some code of my own,

  -Perry





From aprasad/ne_de@fs.fed.us  Thu Sep 30 20:57:04 1999
From: aprasad/ne_de@fs.fed.us (Anantha Prasad)
Date: Thu, 30 Sep 1999 15:57:04 -0400
Subject: [Image-SIG] Imaging-1.0 problems on IRIX 6.5
Message-ID: <37F3C090.36DBC27F@fs.fed.us>

Hi:
I installed Python1.5.2 and then tried to install Imaging-1.0 (in order
to run sketch)
(platform: IRIX 6.5.3 on SGI Indigo2 EX). I run into the following
problem:

* since I don't have the JPEG, PNG and ZIP support, I commented this out
in the Setup file...
as per the instructions in the README file and compiled. 
No problem until: 
	$ PYTHONPATH=.:./PIL ; export PYTHONPATH
	$ python

	>>> import _imaging

Traceback (innermost last):
  File "<stdin>", line 1, in ?
ImportError: 39705:python: rld: Fatal Error: unresolvable symbol in
./_imaging.so: jpeg_resync_to_restart

	>>> import Image

The "import Image" worked OK.

Why am I getting this even though I commented out the relevant sections
in the 
Setup file before compiling as below:

_imaging  _imaging.c decode.c encode.c map.c display.c outline.c path.c
\
	-IlibImaging libImaging/libImaging.a \
#
# *** IJG JPEG library (libjpeg) location
#	-I/usr/local/include -L/usr/local/lib -ljpeg \
#
# *** ZLIB (libz) location
#	-I/usr/local/include -L/usr/local/lib -lz \
#
# *** Tcl/Tk support and library location
        Tk/tkImaging.c -DWITH_TKINTER -I/usr/local/include
-L/usr/local/lib -ltcl8.0 -ltk8.0

# --------------------------------------------------------------------
# uncomment to enable the SANE driver (see Sane/README for more info)

# _sane Sane/_sanemodule.c -IlibImaging -L/usr/local/lib/sane/
-lsane-dll

The sketch program is core dumping and I am suspecting that it is
because of this error in 
the _imageing.so

Thanks much in advance for any help.
Prasad

-- 
*****************************************************************************
Mr. Anantha Prasad         Ph: (740)-368-0103
Ecologist/Spatial_Analyst  Fax: (740)-368-0152
N.E. Research Station    Email: aprasad/ne_de@fs.fed.us
USDA Forest Service      http://www.fs.fed.us/ne/delaware/4153/4153.html
359 Main Rd.                   Don't Miss Global Change Study!!
Delaware OHIO 43015
USA
****************************************************************************


From jose_luis_torreslanda@bausch.com  Thu Sep 30 21:17:52 1999
From: jose_luis_torreslanda@bausch.com (jose_luis_torreslanda@bausch.com)
Date: Thu, 30 Sep 1999 13:17:52 -0700
Subject: [Image-SIG] Hi i'm new here
Message-ID: <7t0ghg$9249@eGroups.com>

Hello every one, I just joined your group because I'm taking a course
in Image procesing (I'm a collage student in Mexico City) and as part
of this course I have to post in a web page Image Procesing news. 
So if anyone has any news in the image procesing world that would like
to share witn me I would really apreciate it, my e-mail address is
jose_luis_torreslanda@bausch.com if you could please send it here or
post it in the egroup I would be greatfull.
My web page is http://artuto.morelia.homepad.com in case someone cares,
it is in spanish but maybe some of you speak my native tongue.
Thanks a lot
Best regards
Jose Luis



From herzog@online.de  Thu Sep 30 22:08:11 1999
From: herzog@online.de (Bernhard Herzog)
Date: 30 Sep 1999 23:08:11 +0200
Subject: [Image-SIG] Imaging-1.0 problems on IRIX 6.5
In-Reply-To: Anantha Prasad's message of "Thu, 30 Sep 1999 15:57:04 -0400"
References: <37F3C090.36DBC27F@fs.fed.us>
Message-ID: <m3n1u4umys.fsf@greebo.nodomain.de>

Anantha Prasad <aprasad/ne_de@fs.fed.us> writes:

> Hi:
> I installed Python1.5.2 and then tried to install Imaging-1.0 (in order
> to run sketch)

Wow!

> (platform: IRIX 6.5.3 on SGI Indigo2 EX). I run into the following
> problem:
> 
> * since I don't have the JPEG, PNG and ZIP support, I commented this out
> in the Setup file...
> as per the instructions in the README file and compiled. 
> No problem until: 
> 	$ PYTHONPATH=.:./PIL ; export PYTHONPATH
> 	$ python
> 
> 	>>> import _imaging
> 
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> ImportError: 39705:python: rld: Fatal Error: unresolvable symbol in
> ./_imaging.so: jpeg_resync_to_restart

Strange.

jpeg_resync_to_restart is only referenced in libImaging/JpegDecode.c .
The configure script in libImaging/ should have been able to tell
whether you have a working Jpeg library and should have deactivated
JpegDecode.c.

Since you were apparantly able to compile JpegDecode.c you probably have
JPEG suport after all. So just activating jpeg in Setup so that
_imaging.so is linked against the jpeg lib might help.

Alternatively you could try to expicitly deactivate jpeg by running
configure with the --without-jpeg option.


> 	>>> import Image
> 
> The "import Image" worked OK.

The Image module silently catches ImportError exceptions when it tries
to import _imaging and only offers very limited services in that case,
like identifying file formats.

> The sketch program is core dumping and I am suspecting that it is
> because of this error in 
> the _imageing.so

I tried to reproduce this on my Linux box by temporarily making 'import
_imaging' fail, but I can't get Sketch to dump core. All I ever got were
the 'ImportError: The _imaging C module is not installed' exceptions PIL
raises when it couldn't import _imaging.

What did you do exactly to make Sketch crash? I'd like to fix it.

-- 
Bernhard Herzog	  | Sketch, a drawing program for Unix
herzog@online.de  | http://www.online.de/home/sketch/