From fredrik@pythonware.com  Sun Aug  1 11:51:04 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sun, 1 Aug 1999 12:51:04 +0200
Subject: [Image-SIG] pil 1.0 update
Message-ID: <000901bedc0b$c1468d90$f29b12c2@secret.pythonware.com>

just a quickie: during the final testing of 1.0, we
discovered a very stupid bug that only affected
big endian platforms (suns, macs).  I hope to be
able to fix this on Monday.

</F>

PS. if you're curious, the problem was that the glue
code that dealt with pixel colours assumed that all
libImaging functions use pointers to a byte buffer to
represent colors.  that's not the case; some use
integers instead, and thus gets bogus values on
big-endian platforms.



From RALDRIDG@gulf-states.com  Mon Aug  2 06:04:39 1999
From: RALDRIDG@gulf-states.com (Robert Aldridge)
Date: Mon, 02 Aug 1999 00:04:39 -0500
Subject: [Image-SIG] Re:Image-SIG digest, Vol 1 #158 - 1 msg
Message-ID: <s7a4e0c0.035@gulf-states.com>

I will be on vacation until Monday, August 9.


From fredrik@pythonware.com  Tue Aug  3 00:17:54 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Tue, 3 Aug 1999 01:17:54 +0200
Subject: [Image-SIG] ann: pil 1.0 final
Message-ID: <002301bedd3d$4072ee10$f29b12c2@secret.pythonware.com>

PIL 1.0 final is now available from:

    http://www.pythonware.com/

Changes since the beta include faster text rendering, support for
using PIL as a package, mechanisms to hook into a standard Tkinter
build, better GIF encoding, incremental image decoding, and various
bug fixes.  see the README and CHANGES files for the full story.

PIL 1.0 is (as before) shipped under a Python-style license, and can be
used without fee also in commercial projects.  However, we encourage
commercial users to support our development efforts by purchasing a
support package; for details, see:

    http://www.pythonware.com/products/pil/support.htm

This announcement will be sent to a wider audience within a few days.
If you find any problems with the distribution (or the support package,
or whatever), please let us know as soon as possible.

regards,
the PIL development team



From RALDRIDG@gulf-states.com  Tue Aug  3 06:02:15 1999
From: RALDRIDG@gulf-states.com (Robert Aldridge)
Date: Tue, 03 Aug 1999 00:02:15 -0500
Subject: [Image-SIG] Re:Image-SIG digest, Vol 1 #159 - 2 msgs
Message-ID: <s7a631ab.081@gulf-states.com>

I will be on vacation until Monday, August 9.


From herzog@online.de  Tue Aug  3 11:10:21 1999
From: herzog@online.de (Bernhard Herzog)
Date: 03 Aug 1999 12:10:21 +0200
Subject: [Image-SIG] Syntax Error im ImageTk.py
Message-ID: <m37lndqinm.fsf@greebo.nodomain.de>

I've just installed the the final 1.0 release, and when I byte-compiled
the python modules, I got a syntax error:

>>> import ImageTk
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "ImageTk.py", line 183
    p    class UI(Tkinter.Label):
    ^
SyntaxError: invalid syntax

Apart from that, PIL seems to work fine, at least I didn't have any
problems with Sketch.

Cheers,

	Bernhard


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


From RALDRIDG@gulf-states.com  Wed Aug  4 06:01:55 1999
From: RALDRIDG@gulf-states.com (Robert Aldridge)
Date: Wed, 04 Aug 1999 00:01:55 -0500
Subject: [Image-SIG] Re:Image-SIG digest, Vol 1 #160 - 2 msgs
Message-ID: <s7a78300.086@gulf-states.com>

I will be on vacation until Monday, August 9.


From Fred L. Drake, Jr." <fdrake@acm.org  Thu Aug  5 03:30:14 1999
From: Fred L. Drake, Jr." <fdrake@acm.org (Fred L. Drake, Jr.)
Date: Wed, 4 Aug 1999 22:30:14 -0400 (EDT)
Subject: [Image-SIG] Proper application of the buffer interface
Message-ID: <14248.63286.73014.204886@weyr.cnri.reston.va.us>

  There has been a bit of discussion lately regarding the buffer
interface to objects in the C API.  Some of this has been on the main
list (comp.lang.python) and some has been on other Python-related
lists.
  I have a question that I don't recall seeing answered (or asked):
What is the real intent of the buffer interface?  When should a Python 
C type implement it?
  The context is this:  the t1python package (an interface to a Type1
font renderer) has, in the past, been passing bitmaps back to Python
as string objects.  In the next release, I may create a new type in
the C layer that provides all the interesting stuff, and would like to 
be able to convert these "glyph" objects to PIL images and GTK+/GNOME
compatible images.  Does it make the most sense for the glyph objects
to offer the buffer interface to make more conversions possible
without increasing the number of memory copies, or do I misunderstand
the application of the interface?
  I'd appreciate some input on this matter.  I hope to get the next
release of t1python done before too much longer, and this is probably
the biggest remaining question that I need to deal with.
  (Any other feedback on t1python would be useful as well!)
  Thanks!


  -Fred

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


From mhammond@skippinet.com.au  Thu Aug  5 03:57:04 1999
From: mhammond@skippinet.com.au (Mark Hammond)
Date: Thu, 5 Aug 1999 12:57:04 +1000
Subject: [Image-SIG] Proper application of the buffer interface
In-Reply-To: <14248.63286.73014.204886@weyr.cnri.reston.va.us>
Message-ID: <006501bedeee$33ef5c20$1101a8c0@bobcat>

>   The context is this:  the t1python package (an interface to a Type1
> font renderer) has, in the past, been passing bitmaps back to Python
> as string objects.  In the next release, I may create a new type in
> the C layer that provides all the interesting stuff, and
> would like to
> be able to convert these "glyph" objects to PIL images and GTK+/GNOME
> compatible images.  Does it make the most sense for the glyph objects
> to offer the buffer interface to make more conversions possible
> without increasing the number of memory copies, or do I misunderstand
> the application of the interface?

I believe you are correct, although _all_ these packages need to support
the interface.  The good news is that due to tricks inside Python, they
already may.

As you mention, it is common to use Python string objects to move chunks of
binary data around.  The buffer interfaces now allow us to use _any_
object, and as long as it conforms to the buffer interface, you dont lose
anything by not using strings (and obviously gain whatever functionality
your object has)

The general idea is that PIL and other such frameworks can think in terms
of buffers.  Rather than PIL saying "give me a Python string with the raw
binary data", it can say "give me an object from which I can obtain a
buffer with the raw binary data".  Strings obviously still fit the bill.

The good news is that it is most common for extension modules to spell
"give me a string with the raw binary data" as "PyArg_ParseTyple("s#",
...);".  PyArg_ParseTuple has been upgraded to use the buffer interfaces,
and so have Python string objects.  Thus, whenever code uses
PyArg_ParseTuple in that way, they are already supporting the buffer
interface.

Thus, you could implement your new object, and define the buffer
interfaces.  This object could then be passed to any C extension function
that use PyArg_ParseTuple, and the extension module will still think it has
a "char *" pointer from an in-place string object.  In practice, this means
that automatically people will be able to say "file.write(your_object)"
etc. with your new object.

The problem remains, of course, for extensions that use the
PyString_Check(), PyString_AsString() etc functions.  If they were upgraded
to use the buffer interfaces, then the transition would be complete.

Just to extend my guesswork somewhat, there is a new built-in "buffer()"
function.  This returns a "buffer" object.  I speculate this should be used
in preference to Python strings when you have binary data.  As this buffer
object supports the buffer interfaces, they are basically as functional as
strings for this purpose, but clearly indicate the data is not really a
string!  This appears to be more a matter of style, and also paves the road
to Unicode - eg, it makes sense to convert any Python string object to
Unicode, but not necessarily a binary buffer.

>   I'd appreciate some input on this matter.  I hope to get the next
> release of t1python done before too much longer, and this is probably
> the biggest remaining question that I need to deal with.

Probably Greg and Guido are the only 2 with the real insight, as they
threashed out the details.  But Im pretty happy with my understanding (as
detailed above) of the issues.

Mark.



From RALDRIDG@gulf-states.com  Thu Aug  5 06:03:33 1999
From: RALDRIDG@gulf-states.com (Robert Aldridge)
Date: Thu, 05 Aug 1999 00:03:33 -0500
Subject: [Image-SIG] Re:Image-SIG digest, Vol 1 #161 - 3 msgs
Message-ID: <s7a8d4e6.045@gulf-states.com>

I will be on vacation until Monday, August 9.


From fredrik@pythonware.com  Thu Aug  5 14:52:06 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Thu, 5 Aug 1999 15:52:06 +0200
Subject: [Image-SIG] Syntax Error im ImageTk.py
References: <m37lndqinm.fsf@greebo.nodomain.de>
Message-ID: <000d01bedf49$b4f84a10$f29b12c2@secret.pythonware.com>

> I've just installed the the final 1.0 release, and when I byte-compiled
> the python modules, I got a syntax error:
> 
> >>> import ImageTk
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
>   File "ImageTk.py", line 183
>     p    class UI(Tkinter.Label):
>     ^
> SyntaxError: invalid syntax

thanks for spotting this.  I've updated the tar file on
our site (the correct size is 313109 bytes).

</F>



From Fred L. Drake, Jr." <fdrake@cnri.reston.va.us  Thu Aug  5 16:07:39 1999
From: Fred L. Drake, Jr." <fdrake@cnri.reston.va.us (Fred L. Drake, Jr.)
Date: Thu, 5 Aug 1999 11:07:39 -0400 (EDT)
Subject: [Image-SIG] Proper application of the buffer interface
In-Reply-To: <006501bedeee$33ef5c20$1101a8c0@bobcat>
References: <14248.63286.73014.204886@weyr.cnri.reston.va.us>
 <006501bedeee$33ef5c20$1101a8c0@bobcat>
Message-ID: <14249.43195.9095.338176@weyr.cnri.reston.va.us>

Mark Hammond writes:
 > The good news is that it is most common for extension modules to spell
 > "give me a string with the raw binary data" as "PyArg_ParseTyple("s#",
 > ...);".  PyArg_ParseTuple has been upgraded to use the buffer interfaces,

Mark,
  This is really cool.  Buffers are probably what I want, then; the
question is starting to become whether to use a buffer object or to
create a new object that implements the buffer interface.  I think I
can handle that!  (And it's looking like implementing a new C type,
for those following t1python.)

 > The problem remains, of course, for extensions that use the
 > PyString_Check(), PyString_AsString() etc functions.  If they were upgraded
 > to use the buffer interfaces, then the transition would be complete.

  Understandable; this is the price of using the lowest-level concrete 
object interfaces.

 > strings for this purpose, but clearly indicate the data is not really a
 > string!  This appears to be more a matter of style, and also paves the road
 > to Unicode - eg, it makes sense to convert any Python string object to
 > Unicode, but not necessarily a binary buffer.

  This is a compelling argument for the buffer type/interface in my
book.  I won't be happy until Unicode strings are in the core!  (No,
I'm not holding out for Unicode strings to replace the current string
type, just that they be in the core and well-supported.)

 > Probably Greg and Guido are the only 2 with the real insight, as they
 > threashed out the details.  But Im pretty happy with my understanding (as
 > detailed above) of the issues.

  Your elucidation on the topic is excellent; if you'd like to write a 
section for the "Extending & Embedding" manual regarding when to
implement the buffer interface and when to use it, I'd certainly be
glad to mark it up and integrate it.  ;-)
  (Greg: No, this wouldn't get you off the hook for reference material!)


  -Fred

--
Fred L. Drake, Jr. <fdrake@cnri.reston.va.us>
Corporation for National Research Initiatives


From RALDRIDG@gulf-states.com  Fri Aug  6 06:01:57 1999
From: RALDRIDG@gulf-states.com (Robert Aldridge)
Date: Fri, 06 Aug 1999 00:01:57 -0500
Subject: [Image-SIG] Re:Image-SIG digest, Vol 1 #162 - 3 msgs
Message-ID: <s7aa2602.086@gulf-states.com>

I will be on vacation until Monday, August 9.


From RALDRIDG@gulf-states.com  Sat Aug  7 06:00:52 1999
From: RALDRIDG@gulf-states.com (Robert Aldridge)
Date: Sat, 07 Aug 1999 00:00:52 -0500
Subject: [Image-SIG] Re:Image-SIG digest, Vol 1 #163 - 1 msg
Message-ID: <s7ab7758.050@gulf-states.com>

I will be on vacation until Monday, August 9.


From RALDRIDG@gulf-states.com  Sun Aug  8 06:00:46 1999
From: RALDRIDG@gulf-states.com (Robert Aldridge)
Date: Sun, 08 Aug 1999 00:00:46 -0500
Subject: [Image-SIG] Re:Image-SIG digest, Vol 1 #164 - 1 msg
Message-ID: <s7acc8bf.086@gulf-states.com>

I will be on vacation until Monday, August 9.


From roman@speeder.com  Sun Aug  8 10:10:11 1999
From: roman@speeder.com (Roman Milner)
Date: 08 Aug 1999 04:10:11 -0500
Subject: [Image-SIG] ImageFile name clash with zope
Message-ID: <m3oggitz7w.fsf@blip.speeder.com>

I guess this is just an FYI - both Zope and PIL have an
ImageFile.py.  I had both in my PYTHONPATH and none of the PIL sample 
scripts worked because PIL was trying to import zope's ImageFile.py.

Changing the sample scripts to explicitly import from the PIL package
fixed it.

from PIL import Image

Just thought this might be useful to someone.


^Roman


From RALDRIDG@gulf-states.com  Mon Aug  9 06:02:04 1999
From: RALDRIDG@gulf-states.com (Robert Aldridge)
Date: Mon, 09 Aug 1999 00:02:04 -0500
Subject: [Image-SIG] Re:Image-SIG digest, Vol 1 #165 - 2 msgs
Message-ID: <s7ae1a9b.010@gulf-states.com>

I will be on vacation until Monday, August 9.


From kuncej@mail.conservation.state.mo.us  Tue Aug 10 15:38:14 1999
From: kuncej@mail.conservation.state.mo.us (Jeffrey Kunce)
Date: Tue, 10 Aug 1999 09:38:14 -0500
Subject: [Image-SIG] pil 1.0 final for NT
Message-ID: <s7aff311.081@mail.conservation.state.mo.us>

>PIL 1.0 final is now available from:

Has anyone built this for Windows yet?

  --Jeff



From nfakh@bom2.vsnl.net.in  Tue Aug 10 19:34:37 1999
From: nfakh@bom2.vsnl.net.in (Najmuddin Fakhruddin)
Date: Wed, 11 Aug 1999 00:04:37 +0530
Subject: [Image-SIG] Saving jpeg files with optimization
Message-ID: <37B070BD.5A5E510A@bom2.vsnl.net.in>

Hello,

I get an error if I try to save jpeg files with the optimize option,
unless the size of the image is quite small. The examples that I've
tried seem to suggest that the error occurs when the width or height
is greater than about 500. (The error disappears if the image is
resized to make it smaller, so I don't think it's a problem with the
images themselves.)

I'm using the 1.0 release of PIL with Python 1.5.2 on Linux (Red Hat 5.2).
The traceback is attached below.

Thanks,
Najmuddin

>>> im.size
(544, 459)
>>> im.save("new.jpg", optimize=1)
Suspension not allowed here
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/site-packages/PIL/Image.py", line 666, in save
    SAVE[string.upper(format)](self, fp, filename)
  File "/usr/local/lib/python1.5/site-packages/PIL/JpegImagePlugin.py", line
307, in _save
    ImageFile._save(im, fp, [("jpeg", (0,0)+im.size, 0, rawmode)])
  File "/usr/local/lib/python1.5/site-packages/PIL/ImageFile.py", line 370, in
_save
    raise IOError, "encoder error %d when writing image file" % s
IOError: encoder error -2 when writing image file


From lalo@webcom.com  Tue Aug 10 21:23:37 1999
From: lalo@webcom.com (Lalo Martins)
Date: Tue, 10 Aug 1999 17:23:37 -0300
Subject: [Image-SIG] Re: Processed: oops
In-Reply-To: <14256.34566.467865.227558@bolero>; from Matthias Klose on Tue, Aug 10, 1999 at 10:12:05PM +0200
References: <19990810162655.H2132@webcom.com> <handler.s.C.9343132955213.transcript@bugs.debian.org> <14256.34566.467865.227558@bolero>
Message-ID: <19990810172336.L2132@webcom.com>

On Tue, Aug 10, 1999 at 10:12:05PM +0200, Matthias Klose wrote:
> Why do you reopen this bug without giving any reasons? This package
> depends on tk8.0, so it's very meaningful to make it depend on
> python-tk as well.

Sorry, I gave the reasons on a separate message so that they
stay on the archive. No offense to you; basically the mistake of
depending on tk is no longer yours, but upstream. It still
_shouldn't_ depend on Tk - drawing images on X is only one of
the many things it can do.

[]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 doko@cs.tu-berlin.de  Tue Aug 10 21:27:29 1999
From: doko@cs.tu-berlin.de (Matthias Klose)
Date: Tue, 10 Aug 1999 22:27:29 +0200 (MET DST)
Subject: [Image-SIG] Bug#41690: Ok, it now depends, but it shouldn't
In-Reply-To: <19990810164126.J2132@webcom.com>
References: <19990810164126.J2132@webcom.com>
Message-ID: <14256.34824.293101.85628@bolero>

[Please CC to 41690@bugs.debian.org]

For the beta of pil I sent a patch, which enables the dynamic loading
of the TK library (if the TK installation is properly made). Is there
a reason that this kind of configuration is not supported by PIL?
I received a suggestion of a Debian user, who uses this package in
this way.

Lalo Martins writes:
 > I can see your point; now _imaging.so depends on libtk. But
 > there's no good reason for that; this poses a problem for people
 > who want PIL in machines where X is not installed (like me). So
 > I took the liberty of reopening the bug and downgrading it to
 > `wishlist'. You can forward it to the upstream development team
 > if you wish.
 > 
 > []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 fredrik@pythonware.com  Fri Aug 13 17:57:03 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 13 Aug 1999 18:57:03 +0200
Subject: [Image-SIG] Re: Processed: oops
References: <19990810162655.H2132@webcom.com> <handler.s.C.9343132955213.transcript@bugs.debian.org> <14256.34566.467865.227558@bolero> <19990810172336.L2132@webcom.com>
Message-ID: <002301bee5ac$e14edc50$f29b12c2@secret.pythonware.com>

Lalo Martins <lalo@webcom.com> wrote:
> On Tue, Aug 10, 1999 at 10:12:05PM +0200, Matthias Klose wrote:
> > Why do you reopen this bug without giving any reasons? This package
> > depends on tk8.0, so it's very meaningful to make it depend on
> > python-tk as well.
> 
> Sorry, I gave the reasons on a separate message so that they
> stay on the archive. No offense to you; basically the mistake of
> depending on tk is no longer yours, but upstream. It still
> _shouldn't_ depend on Tk - drawing images on X is only one of
> the many things it can do.

PIL doesn't depend on Tcl/Tk anymore than it
depends on the JPEG library or the Win32 API.
There's auto configuration stuff in there to
make sure the core library is built in the right
way, but the Python bindings (the _imaging
module) may still need some manual tweaks.

see Setup.in for details.

...

besides from that, it would help if you didn't
assume that everyone is writing code in (or
for) exactly the same environment as you
are (what bug? what archive? what mistake?)

</F>



From fredrik@pythonware.com  Fri Aug 13 18:01:33 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 13 Aug 1999 19:01:33 +0200
Subject: [Image-SIG] Saving jpeg files with optimization
References: <37B070BD.5A5E510A@bom2.vsnl.net.in>
Message-ID: <002a01bee5ad$806b4850$f29b12c2@secret.pythonware.com>

Najmuddin Fakhruddin <nfakh@bom2.vsnl.net.in> wrote:
> I get an error if I try to save jpeg files with the optimize option,
> unless the size of the image is quite small. The examples that I've
> tried seem to suggest that the error occurs when the width or height
> is greater than about 500. (The error disappears if the image is
> resized to make it smaller, so I don't think it's a problem with the
> images themselves.)

after some digging, this seems to be a limitation in
the JPEG library (incremental decoding doesn't work
with optimize).

you might be able to work around this by making
PIL's output buffer large enough to hold the entire
output image:

import ImageFile
ImageFile.MAXBLOCK = 1000000 # default is 64k

im.save("file.jpg", optimize=1)

</F>



From fredrik@pythonware.com  Fri Aug 13 18:10:30 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 13 Aug 1999 19:10:30 +0200
Subject: [Image-SIG] Creating HUGE images...
References: <s7985fdf.079@cymbolic.com>
Message-ID: <004601bee5ae$c2c875a0$f29b12c2@secret.pythonware.com>

Kevin Cazabon <KCAZA@cymbolic.com> wrote:
> I'm trying to develop an easy method to create images much larger than the memory
> available on the host computer, and have one big question:
> 
> -Is there any way to create a NEW image on the hard drive (with blank background)
> without first creating it in memory?  This way, I can create the 'canvas' as large as
> I want, and paste in small chunks of data manually as I go, staying within the memory
> limits of the machine.  (Writing to an existing file shouldn't be a problem, just
> creating the blank file in the first place is causing me problems)

not in PIL 1.0, but if you're prepared to
hack around a little, it wouldn't be that
hard to tweak TiffImagePlugin to support
something like this.  here's what I would
do, if I had the time:

1) add an optional argument to _save
to make it *return* the arguments to
ImageFile._save, rather than calling
the function.

2) create image snippets in a loop,
calling ImageFile._save for each piece.

the calling code would look something
like:

import ImageFile
import TiffImagePlugin

file = "out.tif"
fp = open(file, "wb")

im = Image.new(mode, (1, 1), None)
im.size = width, height # ouch!

tile = TiffImagePlugin._save(im, fp, file, create=1)

format, bbox, offset, info = tile[0]

for y in range(0, height, 256):
    ... create 256-pixels height snippet ...
    ImageFile._save(im, fp, [format,
            (0, y, width, y+256), offset, info)])
    offset = offset + whatever

(completely untested, of course)

</F>



From lalo@webcom.com  Fri Aug 13 19:08:44 1999
From: lalo@webcom.com (Lalo Martins)
Date: Fri, 13 Aug 1999 15:08:44 -0300
Subject: [Image-SIG] Re: Processed: oops
In-Reply-To: <002301bee5ac$e14edc50$f29b12c2@secret.pythonware.com>; from Fredrik Lundh on Fri, Aug 13, 1999 at 06:57:03PM +0200
References: <19990810162655.H2132@webcom.com> <handler.s.C.9343132955213.transcript@bugs.debian.org> <14256.34566.467865.227558@bolero> <19990810172336.L2132@webcom.com> <002301bee5ac$e14edc50$f29b12c2@secret.pythonware.com>
Message-ID: <19990813150844.E3610@webcom.com>

On Fri, Aug 13, 1999 at 06:57:03PM +0200, Fredrik Lundh wrote:
> Lalo Martins <lalo@webcom.com> wrote:
> > 
> > Sorry, I gave the reasons on a separate message so that they
> > stay on the archive. No offense to you; basically the mistake of
> > depending on tk is no longer yours, but upstream. It still
> > _shouldn't_ depend on Tk - drawing images on X is only one of
> > the many things it can do.

[snip]
> besides from that, it would help if you didn't
> assume that everyone is writing code in (or
> for) exactly the same environment as you
> are (what bug? what archive? what mistake?)

Sorry :-) we were talking about the Debian package, Debian
package dependencies (if the python-pil package has a file
linked against libtk, the package will depend on the tk8.0
package), the Debian Bug Tracking System, and the archive of
this particular bug in this System. Visit
http://bugs.debian.org/python-pil to see for yourself.

What I mean by "disagreeing with the dependency" is; IMVHO,
_imaging.so shouldn't link to libtk at all; it should instead
only use functions from tkinter, so it works on a machine where
tk (and tkinter) aren't installed. The way it is, if I want to
use PIL on such a machine I have to recompile it. Not that this
is so much of a big deal, but the idea of packaging stuff is
that people can use it without recompiling.

Also, without studying the source thoroughly (sorry if I
mispelled, it's a nasty word already), I can't even understand
_why_ does PIL link to libtk; what can it want from libtk that
it couldn't get from tkinter instead?

[]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 nfakh@bom2.vsnl.net.in  Fri Aug 13 20:45:42 1999
From: nfakh@bom2.vsnl.net.in (Najmuddin Fakhruddin)
Date: Sat, 14 Aug 1999 01:15:42 +0530
Subject: [Image-SIG] Saving jpeg files with optimization
References: <37B070BD.5A5E510A@bom2.vsnl.net.in> <002a01bee5ad$806b4850$f29b12c2@secret.pythonware.com>
Message-ID: <37B475E5.3B317CF5@bom2.vsnl.net.in>

Fredrik Lundh wrote:
> 
> Najmuddin Fakhruddin <nfakh@bom2.vsnl.net.in> wrote:
> > I get an error if I try to save jpeg files with the optimize option,
> > unless the size of the image is quite small. The examples that I've
> > tried seem to suggest that the error occurs when the width or height
> > is greater than about 500. (The error disappears if the image is
> > resized to make it smaller, so I don't think it's a problem with the
> > images themselves.)
> 
> after some digging, this seems to be a limitation in
> the JPEG library (incremental decoding doesn't work
> with optimize).
> 
> you might be able to work around this by making
> PIL's output buffer large enough to hold the entire
> output image:
> 
> import ImageFile
> ImageFile.MAXBLOCK = 1000000 # default is 64k
> 
> im.save("file.jpg", optimize=1)
> 
> </F>

Thanks. I tried this and it does fix the problem.

Najmuddin


From fredrik@pythonware.com  Sat Aug 14 15:13:51 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sat, 14 Aug 1999 16:13:51 +0200
Subject: [Image-SIG] Bug#41690: Ok, it now depends, but it shouldn't
References: <19990810164126.J2132@webcom.com> <14256.34824.293101.85628@bolero>
Message-ID: <001801bee65f$3f4942c0$f29b12c2@secret.pythonware.com>

Matthias Klose <doko@cs.tu-berlin.de> wrote:
> For the beta of pil I sent a patch, which enables the dynamic loading
> of the TK library (if the TK installation is properly made). Is there
> a reason that this kind of configuration is not supported by PIL?
> I received a suggestion of a Debian user, who uses this package in
> this way.

PIL 1.0 can hook itself into Tk in two different
ways:

1) link _tkinter with the tkImaging module (old style)
2) link _imaging with the same module (new style)

in both cases, tkImaging needs access to the under-
lying Tcl/Tk libraries, so (2) only works well if you're
using shared libraries.

I reviewed several suggested modifications (cannot
remember if your were on that list, though) before
settling on the current design, which appeared to
me as the only one that didn't put any special
requirements on how/where Tcl/Tk was installed,
didn't need any modifications to _tkinter nor Tcl/Tk,
or required the user to run special commands to
finish the installation.

(but of course, 1.0 isn't the last release ever...  if
anyone has a solution that is truly better than the
current one -- and works on all platforms -- please
step forward).

</F>



From lalo@webcom.com  Sat Aug 14 15:30:05 1999
From: lalo@webcom.com (Lalo Martins)
Date: Sat, 14 Aug 1999 11:30:05 -0300
Subject: [Image-SIG] Bug#41690: Ok, it now depends, but it shouldn't
In-Reply-To: <001801bee65f$3f4942c0$f29b12c2@secret.pythonware.com>; from Fredrik Lundh on Sat, Aug 14, 1999 at 04:13:51PM +0200
References: <19990810164126.J2132@webcom.com> <14256.34824.293101.85628@bolero> <001801bee65f$3f4942c0$f29b12c2@secret.pythonware.com>
Message-ID: <19990814113004.A1319@webcom.com>

On Sat, Aug 14, 1999 at 04:13:51PM +0200, Fredrik Lundh wrote:
> Matthias Klose <doko@cs.tu-berlin.de> wrote:
> > For the beta of pil I sent a patch, which enables the dynamic loading
> > of the TK library (if the TK installation is properly made). Is there
> > a reason that this kind of configuration is not supported by PIL?
> > I received a suggestion of a Debian user, who uses this package in
> > this way.
> 
> PIL 1.0 can hook itself into Tk in two different
> ways:
> 
> 1) link _tkinter with the tkImaging module (old style)
> 2) link _imaging with the same module (new style)
> 
> in both cases, tkImaging needs access to the under-
> lying Tcl/Tk libraries, so (2) only works well if you're
> using shared libraries.

I think that's fine. But why is (2) better than (1)? For me,
looks like (1) is the reasonable solution.


Then again, you mention not wanting to modify Tkinter. But if
such a modification would be an improvement, it would be better
for everyone, wouldn't it? If it is at least minimally useful to
other users of Tkinter besides PIL, it should be done.

[]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 fredrik@pythonware.com  Sat Aug 14 16:03:08 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sat, 14 Aug 1999 17:03:08 +0200
Subject: [Image-SIG] Bug#41690: Ok, it now depends, but it shouldn't
References: <19990810164126.J2132@webcom.com> <14256.34824.293101.85628@bolero> <001801bee65f$3f4942c0$f29b12c2@secret.pythonware.com> <19990814113004.A1319@webcom.com>
Message-ID: <003401bee666$c9c89110$f29b12c2@secret.pythonware.com>

> > PIL 1.0 can hook itself into Tk in two different
> > ways:
> > 
> > 1) link _tkinter with the tkImaging module (old style)
> > 2) link _imaging with the same module (new style)
> > 
> > in both cases, tkImaging needs access to the under-
> > lying Tcl/Tk libraries, so (2) only works well if you're
> > using shared libraries.
> 
> I think that's fine. But why is (2) better than (1)? For me,
> looks like (1) is the reasonable solution.

both methods are supported, so you can use whatever
method you prefer.  (or none, if you don't use ImageTk).

> Then again, you mention not wanting to modify Tkinter. But if
> such a modification would be an improvement, it would be better
> for everyone, wouldn't it? If it is at least minimally useful to
> other users of Tkinter besides PIL, it should be done.

today, the modification is highly PIL specific (it installs
a special Tcl command whenever tkinter creates a new
root instance).

_tkinter could be modified to allow you to install new
Tcl commands from Python code, rather than by relink-
ing the module, but I'm not aware of any other module
that would benefit from this.  besides, commands are
not the only thing that you might wish to install in this
way.  there are also bitmaps, canvas types, etc.

and when you end up requiring access to many parts
of the Tcl/Tk library, linking with (shared versions of)
Tcl/Tk surely seems like the best solution... :-)

</F>



From lalo@webcom.com  Sat Aug 14 16:55:09 1999
From: lalo@webcom.com (Lalo Martins)
Date: Sat, 14 Aug 1999 12:55:09 -0300
Subject: [Image-SIG] Bug#41690: Ok, it now depends, but it shouldn't
In-Reply-To: <003401bee666$c9c89110$f29b12c2@secret.pythonware.com>; from Fredrik Lundh on Sat, Aug 14, 1999 at 05:03:08PM +0200
References: <19990810164126.J2132@webcom.com> <14256.34824.293101.85628@bolero> <001801bee65f$3f4942c0$f29b12c2@secret.pythonware.com> <19990814113004.A1319@webcom.com> <003401bee666$c9c89110$f29b12c2@secret.pythonware.com>
Message-ID: <19990814125508.A1520@webcom.com>

On Sat, Aug 14, 1999 at 05:03:08PM +0200, Fredrik Lundh wrote:
> > > PIL 1.0 can hook itself into Tk in two different
> > > ways:
> > > 
> > > 1) link _tkinter with the tkImaging module (old style)
> > > 2) link _imaging with the same module (new style)
> > > 
> > > in both cases, tkImaging needs access to the under-
> > > lying Tcl/Tk libraries, so (2) only works well if you're
> > > using shared libraries.
> > 
> > I think that's fine. But why is (2) better than (1)? For me,
> > looks like (1) is the reasonable solution.
> 
> both methods are supported, so you can use whatever
> method you prefer.  (or none, if you don't use ImageTk).

Well, I was very glad to take part of this discussion and learn
more about PIL and Tkinter, but this settles the issue; IMVHO,
the Debian PIL package should use method (1) and recommend Tk
and Tkinter, not depend on it.

[]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 fredrik@pythonware.com  Sat Aug 14 17:10:25 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sat, 14 Aug 1999 18:10:25 +0200
Subject: [Image-SIG] Bug#41690: Ok, it now depends, but it shouldn't
References: <19990810164126.J2132@webcom.com> <14256.34824.293101.85628@bolero> <001801bee65f$3f4942c0$f29b12c2@secret.pythonware.com> <19990814113004.A1319@webcom.com> <003401bee666$c9c89110$f29b12c2@secret.pythonware.com> <19990814125508.A1520@webcom.com>
Message-ID: <00d101bee66f$8518b5a0$f29b12c2@secret.pythonware.com>

Lalo Martins <lalo@webcom.com> wrote:
> Well, I was very glad to take part of this discussion and learn
> more about PIL and Tkinter, but this settles the issue; IMVHO,
> the Debian PIL package should use method (1) and recommend Tk
> and Tkinter, not depend on it.

showing off my total ignorance of all things debian:
are we talking source or binary packages here?

</F>



From doko@cs.tu-berlin.de  Sat Aug 14 17:32:20 1999
From: doko@cs.tu-berlin.de (Matthias Klose)
Date: Sat, 14 Aug 1999 18:32:20 +0200 (MET DST)
Subject: Bug#41690: [Image-SIG] Bug#41690: Ok, it now depends, but it shouldn't
In-Reply-To: <00d101bee66f$8518b5a0$f29b12c2@secret.pythonware.com>
References: <19990810164126.J2132@webcom.com>
 <14256.34824.293101.85628@bolero>
 <001801bee65f$3f4942c0$f29b12c2@secret.pythonware.com>
 <19990814113004.A1319@webcom.com>
 <003401bee666$c9c89110$f29b12c2@secret.pythonware.com>
 <19990814125508.A1520@webcom.com>
 <00d101bee66f$8518b5a0$f29b12c2@secret.pythonware.com>
Message-ID: <14261.39062.589115.132836@bolero>

Fredrik Lundh writes:
 > Lalo Martins <lalo@webcom.com> wrote:
 > > Well, I was very glad to take part of this discussion and learn
 > > more about PIL and Tkinter, but this settles the issue; IMVHO,
 > > the Debian PIL package should use method (1) and recommend Tk
 > > and Tkinter, not depend on it.
 > 
 > showing off my total ignorance of all things debian:
 > are we talking source or binary packages here?

we are talking about binary packages provided for Debian Linux and
Debian hurd distributions. But you can generalize the situation to
installations, where you don't want or cannot recompile or reinstall
Tcl and Python.

 > 1) link _tkinter with the tkImaging module (old style)

with the disadvantage of recompiling _tkinter.

 > 2) link _imaging with the same module (new style)

with the disadvantage of being forced to install all X11 and the Tk
shared library (That's the way Lalo wants to use PIL).

3) use the Tcl load extension to load the one PIL command. (does not
   has the two disadvantages above).
   But has the disadvantage that Tcl is set up correctly to handle
   autoloading of packages.


From lalo@webcom.com  Sat Aug 14 17:49:01 1999
From: lalo@webcom.com (Lalo Martins)
Date: Sat, 14 Aug 1999 13:49:01 -0300
Subject: [Image-SIG] Bug#41690: Ok, it now depends, but it shouldn't
In-Reply-To: <00d101bee66f$8518b5a0$f29b12c2@secret.pythonware.com>; from Fredrik Lundh on Sat, Aug 14, 1999 at 06:10:25PM +0200
References: <19990810164126.J2132@webcom.com> <14256.34824.293101.85628@bolero> <001801bee65f$3f4942c0$f29b12c2@secret.pythonware.com> <19990814113004.A1319@webcom.com> <003401bee666$c9c89110$f29b12c2@secret.pythonware.com> <19990814125508.A1520@webcom.com> <00d101bee66f$8518b5a0$f29b12c2@secret.pythonware.com>
Message-ID: <19990814134900.A2005@webcom.com>

On Sat, Aug 14, 1999 at 06:10:25PM +0200, Fredrik Lundh wrote:
> Lalo Martins <lalo@webcom.com> wrote:
> > Well, I was very glad to take part of this discussion and learn
> > more about PIL and Tkinter, but this settles the issue; IMVHO,
> > the Debian PIL package should use method (1) and recommend Tk
> > and Tkinter, not depend on it.
> 
> showing off my total ignorance of all things debian:
> are we talking source or binary packages here?

Binary.

[]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 fredrik@pythonware.com  Sat Aug 14 18:09:51 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sat, 14 Aug 1999 19:09:51 +0200
Subject: Bug#41690: [Image-SIG] Bug#41690: Ok, it now depends, but it shouldn't
References: <19990810164126.J2132@webcom.com><14256.34824.293101.85628@bolero><001801bee65f$3f4942c0$f29b12c2@secret.pythonware.com><19990814113004.A1319@webcom.com><003401bee666$c9c89110$f29b12c2@secret.pythonware.com><19990814125508.A1520@webcom.com><00d101bee66f$8518b5a0$f29b12c2@secret.pythonware.com> <14261.39062.589115.132836@bolero>
Message-ID: <014701bee677$d2f46000$f29b12c2@secret.pythonware.com>

Matthias Klose <doko@cs.tu-berlin.de> wrote:
>  > 1) link _tkinter with the tkImaging module (old style)
> 
> with the disadvantage of recompiling _tkinter.
> 
>  > 2) link _imaging with the same module (new style)
> 
> with the disadvantage of being forced to install all X11 and the Tk
> shared library (That's the way Lalo wants to use PIL).
> 
> 3) use the Tcl load extension to load the one PIL command. (does not
>    has the two disadvantages above).
>    But has the disadvantage that Tcl is set up correctly to handle
>    autoloading of packages.

after some fresh air, and some more digging, I've found
a fourth option, which should make everyone happy:

4) link _imagingtk with the tkImaging module

where _imagingtk is a new module, containing the tkinit
stuff from _imaging.  ImageTk should use this module to
activate the Tk interface.

to *build* the new module, you still need Tk and the rest
of the stuff, but it allows the package maintainer to ship
a single binary package.

expect a 1.0.1 release in a not too distant future...

</F>



From fredrik@pythonware.com  Sun Aug 15 12:42:26 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sun, 15 Aug 1999 13:42:26 +0200
Subject: Bug#41690: [Image-SIG] Bug#41690: Ok, it now depends, but it shouldn't
References: <19990810164126.J2132@webcom.com><14256.34824.293101.85628@bolero><001801bee65f$3f4942c0$f29b12c2@secret.pythonware.com><19990814113004.A1319@webcom.com><003401bee666$c9c89110$f29b12c2@secret.pythonware.com><19990814125508.A1520@webcom.com><00d101bee66f$8518b5a0$f29b12c2@secret.pythonware.com> <14261.39062.589115.132836@bolero> <014701bee677$d2f46000$f29b12c2@secret.pythonware.com>
Message-ID: <00da01bee713$406aab80$f29b12c2@secret.pythonware.com>

I wrote:
> expect a 1.0.1 release in a not too distant future...

I've made an experimental 1.0.1, in which
the tcl/tk interface is factored out into
a separate module (_imagingtk).  it's avail-
able at:

http://www.pythonware.com/downloads/Imaging-1.0.1.tar.gz

despite its name, please treat it as an
experimental release until further notice
(and unless you're a package provider,
there's really no need to grab this one.).

Matthias and Lalo, let me know what you
think about this solution.

</F>



From fredrik@pythonware.com  Mon Aug 16 09:11:05 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Mon, 16 Aug 1999 10:11:05 +0200
Subject: [Image-SIG] Re: Imaging-1.0.1 (was Re: Bug#41690...)
References: <19990810164126.J2132@webcom.com><14256.34824.293101.85628@bolero><001801bee65f$3f4942c0$f29b12c2@secret.pythonware.com><19990814113004.A1319@webcom.com><003401bee666$c9c89110$f29b12c2@secret.pythonware.com><19990814125508.A1520@webcom.com><00d101bee66f$8518b5a0$f29b12c2@secret.pythonware.com> <14261.39062.589115.132836@bolero> <014701bee677$d2f46000$f29b12c2@secret.pythonware.com> <00da01bee713$406aab80$f29b12c2@secret.pythonware.com>
Message-ID: <007301bee7be$e3f46600$f29b12c2@secret.pythonware.com>

> I've made an experimental 1.0.1, in which
> the tcl/tk interface is factored out into
> a separate module (_imagingtk).  it's avail-
> able at:

heavily influenced by a certain murphy, I
messed up when preparing that release.
an updated archive is available at:

http://www.pythonware.com/downloads/Imaging-1.0.1.tar.gz

the correct size is 313,447 bytes.

and yes, the following still applies, of
course:
 
> despite its name, please treat it as an
> experimental release until further notice
> (and unless you're a package provider,
> there's really no need to grab this one.).

</F>



From fpinel@fedex.com  Mon Aug 16 16:49:42 1999
From: fpinel@fedex.com (frederic pinel)
Date: Mon, 16 Aug 1999 15:49:42 +0000
Subject: [Image-SIG] Re: Image-SIG digest, Vol 1 #169 - 8 msgs
References: <199908150501.BAA22645@python.org>
Message-ID: <37B83316.5A259A19@fedex.com>

Hello,
Sorry if this question has been posted before: I couldn't work (open/save) with
G4 Tif ? Is there anything I need to do?
Thanks for any help!


From pels@bio.uva.nl  Fri Aug 20 14:05:09 1999
From: pels@bio.uva.nl (bas pels)
Date: Fri, 20 Aug 1999 15:05:09 +0200
Subject: [Image-SIG] im.show() error
Message-ID: <37BD5285.90F5A457@bio.uva.nl>

hi,

after upgrading PIL 1.0b to PIL 1.0, i cannot longer pass the first page of
the tutorial...
any idea what happened?


[bas@orius bas]$ python
Python 1.5.2 (#1, Apr 18 1999, 16:03:16)  [GCC pgcc-2.91.60 19981201 (egcs-1.1.1
on linux2   Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
python >> import Image
python >> im = Image.open("lena.ppm")
python >> print im.format, im.size, im.mode
PPM (128, 128) RGB
python >> im.show()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python1.5/site-packages/PIL/Image.py", line 694, in show
    _showxv(self, title, command)
  File "/usr/lib/python1.5/site-packages/PIL/Image.py", line 974, in _showxv
    file = self._dump(format=format)
  File "/usr/lib/python1.5/site-packages/PIL/Image.py", line 311, in _dump
    file = file + "." + format
TypeError: illegal argument type for built-in operation
python >>


strange enough, the following works fine:

[bas@orius bas]$ python
Python 1.5.2 (#1, Apr 18 1999, 16:03:16)  [GCC pgcc-2.91.60 19981201 (egcs-1.1.1
on linux2   Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
python >> from Tkinter import *
python >> import Image
python >> root = Tk()
python >> im = Image.open("lena.ppm")
python >> im.show()
python >>                                      



......................................................................
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  Fri Aug 20 14:28:56 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 20 Aug 1999 15:28:56 +0200
Subject: [Image-SIG] im.show() error
References: <37BD5285.90F5A457@bio.uva.nl>
Message-ID: <00c101beeb0f$f4dcf230$f29b12c2@secret.pythonware.com>

bas pels <pels@bio.uva.nl> wrote:
> after upgrading PIL 1.0b to PIL 1.0, i cannot longer pass the first page of
> the tutorial... any idea what happened?

when fixing show for Windows platforms, we broke it
on Unix.  (I'm beginning to suspect that you shouldn't
include functions you never use yourself ;-)

Chad Netzer recently sent me the following patch,
which will go into the official 1.0.1 update (don't
ask 'when' just yet):

--- PIL/Image.py.orig   Mon Aug  2 15:39:56 1999
+++ PIL/Image.py        Sun Aug 15 14:30:28 1999
@@ -961,7 +961,7 @@
        if not command:
            command = "start"
     else:
-       format = None
+       format = "PPM"
        if not command:
            command = "xv"
            if title:

</F>



From schorsch@schorsch.com  Sat Aug 21 21:47:39 1999
From: schorsch@schorsch.com (Georg Mischler)
Date: Sat, 21 Aug 1999 16:47:39 -0400 (EDT)
Subject: [Image-SIG] Floating point color in PIL?
Message-ID: <Pine.BSF.4.10.9908211641530.19483-100000@emancholl.pair.com>

Hi again in imaging land,

in my attempts to read Radiance image files into PIL, I
have made some partial progress. I think I understand
how the plugin should look like from the python side (and
I allready had most code needed for this). Now I am trying
to get the data in somehow, and I can't see a way to
store three band floating point images without modifying
(at least) Image.py and Storage.c.

The files store radiance (sic!) values in rgbe format,
with either a simple runlength encoding scheme or another
more complicated one. The values are encoded within four bytes,
the fourth byte holding a common exponent for the three bands.
But this is not the problem, since the encoder/decoder will
handle the peculiarities of the file format transparently.

The result are the floating point RGB radiance pixels.
How should I store those? None of the image types I could
see is big enough to handle this. Should I create a new
"RGBf" (or whatever) image type?

In Storage.c this might look like:

	...
	} else if (strcmp(mode, "RGBf") == 0) {
		/* 3x32-bit floating point images */
		im->bands = 3;
		im->pixelsize = 12; /* ?? */
		im->linesize = xsize * 3
		im->type = IMAGING_TYPE_FLOAT32;
	} ...


In Image.py, _MODEINFO would get an additional entry:

	"RGBf": ("RGB", "F", ("R", "G", "B")),

Did I miss anything that would make this break?
Is there a way to get the same effect without messing with
the PIL sources?

The obvious idea to convert the image data to true color
RGB before storing it is not an option, since I need
the real radiance values, so I can adjust the display
for exposure, and for analysis of the derived luminance
values. The data format I need is *not* intended for
being displayed directly, but will need some conversion
to any of the standard types before that.

This conversion is normally not of the kind of what Filter.c
does, but would be closer to the stuff in Convert.c, though
with a slight difference. The conversions I need usually take
one or more arguments, in the simplest case just an exposure
and a gamma value, but also some more advanced parameters
for adapting the new image in a way that mimicks the way the
human perception would represent the simulated scene in reality.

Since the filter protocol only seems to support matrixes,
and I can't see any way yet to supply additional arguments
to a simple format conversion, where should I look?
Would I have to create completely new interfaces or
am I missing some other possibility? The approach taken by
the enhance classes is only partly helpful, since most
of the needed operations can't be easily represented as
inter/extrapolations.

Could I modify the pixel access routines of my RGBf image,
so that the image object can be configured for the needed
conversions, spitting out the final RGB values as desired
for any combination of parameters?
This could mean to say:
   im.gamma = 2.4
   im.exposure = 2
   new_image = im.convert('RGB')
And the special 'RGBf' image would know how to convert its
radiance values to luminances in the RGB color space given
those settings. Does this make any kind of sense to try?

It may be obvious by now, that I am a bit lost in the dark
here, which is a disastrous feeling for a lighting designer!
I'd appreciate it very much if anyone could shed some light
ont those matters. The result of my struggling will be
contributed straight back into PIL (assuming that my output
passes the pythonware quality checks, which may not be
garanteed yet... ;).


Thanks a lot for your time.

-schorsch

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



From Fred L. Drake, Jr." <fdrake@acm.org  Tue Aug 24 15:26:14 1999
From: Fred L. Drake, Jr." <fdrake@acm.org (Fred L. Drake, Jr.)
Date: Tue, 24 Aug 1999 10:26:14 -0400 (EDT)
Subject: [Image-SIG] PIL 1.0 as a package
Message-ID: <14274.43910.34124.240383@weyr.cnri.reston.va.us>

  I have a question about the use of PIL as a package.
  The instructions in the 1.0 source release describe an installation
which is *almost* a package style installation, with the caveat that
it remains accessible without the package-style import due to the
PIL.pth file.
  Removing the PIL.pth file seems to work just fine for requiring
package-style imports, which I'm happy with.  Is this the expectation
for package use of PIL, or is the intent of using a subdir of
site-packages/ simply to keep the files together?  I noticed that
PIL.Image.init() still simply uses sys.path to search for
*ImagePlugin.py; should it do something like:

	try:
            path = __path__
        except NameError:
            path = sys.path
        for p in path:
            ...

This could at least speed the search when PIL is being used as a
package.
  When linking the Tk interface code into _imaging.so (which I think
is a bad idea still), the X11 library also needs to be linked in (and
must be dynamically linked so there's only one copy, shared with
_tkinter); that's not done in the Setup.in as distributed.


  -Fred

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


From fredrik@pythonware.com  Thu Aug 26 11:11:34 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Thu, 26 Aug 1999 12:11:34 +0200
Subject: [Image-SIG] PIL 1.0 as a package
References: <14274.43910.34124.240383@weyr.cnri.reston.va.us>
Message-ID: <002801beefab$fde434b0$f29b12c2@secret.pythonware.com>

Fred L. Drake, Jr. <fdrake@acm.org> wrote:
>   The instructions in the 1.0 source release describe an installation
> which is *almost* a package style installation, with the caveat that
> it remains accessible without the package-style import due to the
> PIL.pth file.

well, as I read that text, it describes two *different*
ways to install PIL.  the package support was mostly
added to help the Zopers...

>   When linking the Tk interface code into _imaging.so (which I think
> is a bad idea still)

in 1.0, you can link the Tk interface code into _tkinter.so
or _imaging.so.  in 1.0.1 (out soon), you can link it either
into _tkinter.so, or into _imagingtk.so.  it has to be some-
where, you know...

(maybe TEA will make this even easier, but we're not
there yet...)

> the X11 library also needs to be linked in (and must be
> dynamically linked so there's only one copy, shared with
> _tkinter); that's not done in the Setup.in as distributed.

last minute fix; we tested this with 8.1, and had no trouble
linking it (8.1 is built as a shared library by default).  before
shipping, I changed that to 8.0 and didn't test it on a clean
machine (8.0 is not built as a shared library by default...)

this has been fixed in 1.0.1.

</F>



From fredrik@pythonware.com  Thu Aug 26 11:18:02 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Thu, 26 Aug 1999 12:18:02 +0200
Subject: [Image-SIG] Re: Image-SIG digest, Vol 1 #169 - 8 msgs
References: <199908150501.BAA22645@python.org> <37B83316.5A259A19@fedex.com>
Message-ID: <002901beefac$4a256290$f29b12c2@secret.pythonware.com>

> Sorry if this question has been posted before: I couldn't work (open/save) with
> G4 Tif ? Is there anything I need to do?

umm.  someone with your name asked the same
question a while ago, to which I answered:

...

> I can't modify a G4 compressed TIF file, apparently the G4 is not supported, is
> that correct? 

that's correct.  PIL cannot read or write any of the
CCITT formats supported by TIFF.

various people have promised me interfaces to libtiff,
but a complete interface has still to appear (I have a
partial implementation by someone somewhere, but
no time to finish it -- at least not in time for 1.0).

...

contributions are still welcome or <plug> you can
purchase the support package and wait for this to
appear in the pil plus package...</plug>

</F>



From Fred L. Drake, Jr." <fdrake@acm.org  Thu Aug 26 15:08:27 1999
From: Fred L. Drake, Jr." <fdrake@acm.org (Fred L. Drake, Jr.)
Date: Thu, 26 Aug 1999 10:08:27 -0400 (EDT)
Subject: [Image-SIG] PIL 1.0 as a package
In-Reply-To: <002801beefab$fde434b0$f29b12c2@secret.pythonware.com>
References: <14274.43910.34124.240383@weyr.cnri.reston.va.us>
 <002801beefab$fde434b0$f29b12c2@secret.pythonware.com>
Message-ID: <14277.19035.26100.249967@weyr.cnri.reston.va.us>

Fredrik Lundh writes:
 > well, as I read that text, it describes two *different*
 > ways to install PIL.  the package support was mostly

  My bad; I must've misread.
  So, is the "package" version recommended, or not?  It sounds to me
like either PIL.pth *or* __init__.py* should be installed, but not
both (else both "import Image" and "import PIL.Image" work, and create 
two different modules, talking to two different instances of
_imaging.so, which means that things get fragile).
  It was not at all clear from the README that either usage is
preferred over the other, but I think it should be made clear so that
it is consistent across installations.

 > or _imaging.so.  in 1.0.1 (out soon), you can link it either
 > into _tkinter.so, or into _imagingtk.so.  it has to be some-
 > where, you know...

  Oh, you actually want the code in there!??!?!  Isn't this where
ld.so pops open a window to let you type in the bits of the executable 
code that were missing?  I'd prefer that method!  ;-)
  Seriously, I prefer the last option you offer: having a separate
module that does the interfacing between the two packages.

 > this has been fixed in 1.0.1.

  Thanks!


  -Fred

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


From N.B.Price@exeter.ac.uk  Fri Aug 27 00:00:12 1999
From: N.B.Price@exeter.ac.uk (N.B.Price@exeter.ac.uk)
Date: Fri, 27 Aug 1999 00:00:12 +0100 (BST)
Subject: [Image-SIG] pixmap error
Message-ID: <107503.199908262300@olib>

Heyho,

I'm a student and new to python, and I'm trying to learn some thing by using the PIL. I must say, to start with, that I'm finding both to be very groovy indeed.

One problem though; I've had this on several machines with verying version of python - Using PIL 1.0 and going through the installation steps under Linux, I can do everything in the compilation stages but when I try to import _imaging, I get an error saying that there's an undefined symbol XFreePixMap in the Tk lib. Is this something that should be obvious? I'd imagine so.. please point out to me as such :> If it's more obfuscated, well I'm sure there's a genius on this list somewhere :>

Many thanks,

-Nathan

-- 
/------------------------------------------\
|  Draco, The Cute & Sweet Copperdwaggin!  |
|      AKA Nathan Benedict Price,          |
|    Computer Science Undergraduate,       |
|         University of Exeter.            |
\------------------------------------------/
/                                          \
| Gee, I never saw a dragon like _that_... |
\------------------------------------------/


From schorsch@schorsch.com  Sun Aug 29 18:25:54 1999
From: schorsch@schorsch.com (Georg Mischler)
Date: Sun, 29 Aug 1999 13:25:54 -0400 (EDT)
Subject: [Image-SIG] floating point color with PIL again
Message-ID: <Pine.BSF.4.10.9908291304130.19540-100000@emancholl.pair.com>

Hi again,

I hate to follow up to my own message, but it looks like I
have no choice but to annoy this forum just until I get
*some* response.
(Yes, I know this is free software and I shouldn't complain,
but after investing lots of thought into the matter and
potentially even larger amounts of work, calling out
repeatedly without an echo is still frustrating.)


I wrote:
> The result are the floating point RGB radiance pixels.
> How should I store those? None of the image types I could
> see is big enough to handle this. Should I create a new
> "RGBf" (or whatever) image type?
> 
> In Storage.c this would look like:
> 
> 	...
> 	} else if (strcmp(mode, "RGBf") == 0) {
> 		/* 3x32-bit floating point images */
> 		im->bands = 3;
> 		im->pixelsize = 12; /* ?? */
> 		im->linesize = xsize * 3
> 		im->type = IMAGING_TYPE_FLOAT32;
> 	} ...
>
[...] 
> Did I miss anything that would make this break?
> Is there a way to get the same effect without messing with
> the PIL sources?

Reading more carefully through the sources, it dawns on me
that this would break almost everything.

Most functions in PIL silently assume that an image will
have a pixel size of either one or four bytes. This allows
for many optimisations, depending on the values of the
im->image8 and im->image32 members. The typical approach
is to loop first over im->ysize and then over im->xsize
with either UINT8 or UINT32 steps. This often already
breaks the experimental modes currently implemented, and
would leave 2/3 of a floating point color image untouched.

As a consequence, getting a PIL based solution for my
problem requires a more general approach for looping over
the image data. I can see several possible approaches:

a) Define eg. IMAGING_TYPE_FLOAT32x3 and modify the looping
   macros (where macros are used) to accept the xsize to
   loop over as an argument, set to im->xsize*im->bands for
   IMAGING_TYPE_FLOAT32x3.  This still breaks for functions
   that don't access or write the data in each line in
   forward direction (eg. FlipLeftRight()) and requires
   some additional work for those functions where the loop
   can't easily be substituted by a macro. The current
   experimental modes would also benefit from this approach.

b) Have all loops actually loop over im->ysize, im->xsize
   and finally im->bands in im->pixelsize/im->bands
   steps. This is be the most general approach, but 
   defeats all optimisations currently in place. Probably
   not a good idea.

c) Wrap the floating point color data in a "super image"
   data structure, actually containing three normal F type
   images. This object could use the existing procedures
   to have it's subimages treated seperately where possible,
   collecting the results and composing them into a new
   super image. Some of the interesting operations of course
   depend on the full color values and would have to be
   implemented completely from scratch. In any case, this
   rather looks like an ugly hack to me, and would only make
   some sense if there was no way to get my modifications
   back into the official PIL package (to prevent having
   to adapt my code to every new release).

d) Add another if/else clause to every function operating
   on images, and implement extra routines to handle just
   my special case. As a general solution, this looks ugly.
   In some special cases though, method a) probably
   requires to do this for real tricky procedures, and
   ImagingTransformFilter() is already implemented in a
   very flexible variation of this approach. 

e) Some genius will no doubt find a better way.


I am willing to implement one of the solutions above,
preferring a) or whatever the experts convince me to.
Yes, I realize that this means a mayor overhaul of
almost all of PIL. But this still looks far more 
attractive than having to start from scratch or not being
able to implement my image manipulation stuff at all.

I don't expect to cover everything in the first run
anyway. I will implement the changes to those functions
where I need them myself first, and possibly modify others
only to prevent potential disaster. There are several
areas where the floating point color images will not
support the standard ways to do things by principle.

First, translation to other formats will not be possible
through the normal convert() mechanisms, since there is no
direct mapping between radiance values and image brightness.
There will be an extra reduce(?) function, that takes
into account the desired exposure of the image, the gamma
of the target medium and the spectral lighting characteristics
under which the image was originally created. The internal
sequence of operations will be:
  rgb radiance(w/sr/m2) x spectral weight
     -> rgb luminance(cd/m2 or nits) x gamma x exposure
        -> image brightness (0-255 rgb or greyscale).

This also prevents direct display by any of the current
GUI options (Tkinter in my case). It will be necessary
to convert (reduce) the image to one of the shorter formats
before applying to a PhotoImage or similar. As an alternative,
this conversion might be encapsulated in the image object
itself, so it would look like a RGB, L or I image to the
functions that can only handle those, and do the conversion
on the fly. I don't see an easy way to implement this in
current PIL, but it's a theoretical concept for trading
memory consumption against cpu cycles.

I assume that the generalisations of method a) would also
prepare PIL for raster data that uses more than three bands.
If anyone is interested in this, please let me know.  Maybe
we could share some of the work, or I could at least try
not to sabotage your needs with my changes. Any other comments
or suggestions are highly welcome.


Ok, that's all I can currently offer, so let's see if
it finally stirs up some attention... ;)


Regards

-schorsch


PS:
Before the question comes up: Yes, I have considered buying
a support contract, but although my project has a very
commercial look (and I announced it this way), It's still
far from generating any revenues. Since I currently have
more time than money (I'm already about a year behind schedule,
so who cares), I need to stick to the do-it-yourself approach
for now.  We'll see what happens when (or if) I ever start
to sell any of my software.

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



From philwil@on-ramp.ior.com  Tue Aug 31 14:21:29 1999
From: philwil@on-ramp.ior.com (phil wilshire)
Date: Tue, 31 Aug 1999 06:21:29 -0700
Subject: [Image-SIG] ImageDraw not working ( for me )
Message-ID: <37CBD6D9.77612C2D@on-ramp.ior.com>

HI,
I am trying to replace my GD python package to 
fend off the gif patent problem.

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

I have started to trace through the package but I wondered if this
problem had 
already been solved.

Please reply via e-mail.

Many thanks
   Phil Wilshire


From lalo@webcom.com  Tue Aug 31 20:11:55 1999
From: lalo@webcom.com (Lalo Martins)
Date: Tue, 31 Aug 1999 16:11:55 -0300
Subject: [Image-SIG] Bezier, or any other way to draw closed pictures made of curves?
Message-ID: <19990831161155.A5466@webcom.com>

You probably know that, but...

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 :-)

As a milestone to follow, look for a comic book in your house
somewhere. If you can draw the 3 most used baloon types (for
spoken, thought and yelled text) then you have a versatile
drawing library.


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.

[]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