From martinb@egroups.net  Wed Dec  1 01:08:56 1999
From: martinb@egroups.net (Martin Baker)
Date: Tue, 30 Nov 1999 17:08:56 -0800 (PST)
Subject: [Image-SIG] a nice idea
Message-ID: <Pine.LNX.4.10.9911301608030.6912-100000@magrathea.egroups.net>

Having downloaded your cool PIL, I was dismayed to find that I needed more
libraries to write JPEG and PNG files. I was more dismayed to find I had
to go out on the net and search for them. It'd be really nice if you
included URLs for them in the README file. Here they are:

ZLIB:
http://www.cdrom.com/pub/infozip/zlib/

IJG JPEG library:
ftp://ftp.uu.net/graphics/jpeg/

Thanks,
Martin



From fredrik@pythonware.com  Wed Dec  1 07:58:40 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 1 Dec 1999 08:58:40 +0100
Subject: [Image-SIG] Docs for decoder
References: <3D62AB6FFC80D211A84700104B10CB2C025D8C3D@denver.quark.com>
Message-ID: <003301bf3bd1$e4cbac20$f29b12c2@secret.pythonware.com>

Alden Lavizzo <ALavizzio@quark.com> wrote:
> Is there any documentation on writing a decoder?  I am writing a decoder
> that decompresses a special type of image and cannot find any help on how to
> do this other than looking at source code.

really?  before you do, you might wish to read
the "writing your own file decoder" chapter in
the handbook.

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

it describes how the file format plugins work.
if you cannot use any of the built-in low-level
codecs, things get a little harder.  I suggest
that you take a close look at the raw codec.

if you find it too hard to write an incremental
decoder for your format, an easier solution is
to overload the "load" method and load the en-
tire image in one go (you still have to implement
register your plugin as usual, and implement the
_open method, but you don't have to set the tile
attribute).

</F>



From fredrik@pythonware.com  Thu Dec  2 00:11:44 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Thu, 2 Dec 1999 01:11:44 +0100
Subject: [Image-SIG] Twiddle screen pixels
References: <383AC64B.95059CF6@calibre-dd.com>
Message-ID: <006e01bf3c59$d53cf100$f29b12c2@secret.pythonware.com>

Stephen J King <king@calibre-dd.com> wrote:
> Forgive a relative PIL newbie if this is a trivial matter, but:
> 
> I want to use PIL as a framework for testing image processing algorithm
> prototypes written in python. I am trying to write something which will
> continuously update the screen image as data is generated. I've modified
> one of the PIL demos to this:

unfortunately, in the process of modifying the demo, you
removed all code involved in actually displaying the image...

> #
> # painter widget
> 
> class PaintCanvas(Canvas):
>     def __init__(self, master, image):
>                 Canvas.__init__(self, master, width=image.size[0],
> height=image.size[1])
>                 self.image = image
>                 self.bind("<B1-Motion>", self.paint)
> 
>     def paint(self, event):
>                 xy = event.x, event.y
>                 try:
>                         self.image.putpixel(xy,0)
>                 except:
>                         pass
>                 self.update_idletasks()
> 
> #
> # main
> 
> root = Tk()
> 
> size=(250,250)
> im = Image.new('RGB',size)
> 
> PaintCanvas(root, im).pack()
> 
> root.mainloop()
> 
> ###

I'd suggest you take another look at the original script,
and that you keep the important pieces.  if you want
to start with something simpler, use viewer.py instead
of painter.py

(but don't forget that painter.py uses tiling for a
reason -- see the comments in that file for details).

> I would rather not use tiling, as this would add an
> unnecessary layer of complexity.

why?  I mean, I've already written the code for you :-)

</F>



From fredrik@pythonware.com  Thu Dec  2 01:08:24 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Thu, 2 Dec 1999 02:08:24 +0100
Subject: [Image-SIG] Pasting with pixmaps broken in 1.0 final?
References: <Pine.GSO.4.05.9911171342330.13723-100000@inky>
Message-ID: <017c01bf3c61$bcbed320$f29b12c2@secret.pythonware.com>

Robert Kern <kern@its.caltech.edu> wrote:
> Under 1.0b1, the image is a square gradient going from red to green on a
> red background.  Under 1.0 final, the image has the left half of the
> gradient the same as previous, but the right half is a solid light blue,
> no gradient at all.
> 
> Something in ImagingFill2 perhaps?

I can repeat the problem it on other platforms, so
I guess I cannot blame your compiler ;-)

it's probably a signed/unsigned problem.  I'll look
into it as soon as I find some time to spare.

</F>



From akuchlin@mems-exchange.org  Thu Dec  2 21:45:17 1999
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Thu, 2 Dec 1999 16:45:17 -0500 (EST)
Subject: [Image-SIG] Patch for text chunks in PNGs
Message-ID: <199912022145.QAA04142@amarok.cnri.reston.va.us>

Here's a patch of mine from a while back that didn't make it into PIL
1.0; I just want it to get into a future release.  It adds support for
reading zTXt (compressed text) chunks and writes out the contents of
the .info dictionary as text chunks.

Being able to add metadata to an image is of great importance to me;
is there a list of which image plugins actually read in image metadata
and write it out?  (Where the image format supports it, of course.)

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
I am a sociologist, God help me.
    -- John O'Neill



*** PngImagePlugin.py	Mon Aug  2 18:39:56 1999
--- /tmp/PngImagePlugin.py	Thu Dec  2 11:45:55 1999
***************
*** 198,201 ****
--- 198,213 ----
  	return s
  
+     def chunk_zTXt(self, pos, len):
+         # compressed text
+         s = self.fp.read(len)
+         [k, v] = string.split(s, "\0")
+         comp_method = ord( v[0] ) ; v = v[1:]
+         if comp_method != 0:
+             raise SyntaxError, "Unknown compression method %i in zTXt chunk" % comp_method
+         # Deflate/inflate compression was used
+         import zlib
+         self.im_info[k] = zlib.decompress( v )
+         return s
+ 
  
  # --------------------------------------------------------------------
***************
*** 408,411 ****
--- 420,429 ----
  	chunk(fp, "gAMA", o32(int(gamma * 100000.0)))
  
+     # Write text chunks
+     for key, value in im.info.items():
+         # Skip PIL-internal keys
+         if key in ['interlace', 'gamma']: continue
+         chunk(fp, 'tEXt', key + chr(0) + value)
+         
      ImageFile._save(im, _idat(fp, chunk), [("zip", (0,0)+im.size, 0, rawmode)])
  


From fredrik@pythonware.com  Fri Dec  3 12:30:29 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 3 Dec 1999 13:30:29 +0100
Subject: [Image-SIG] Pasting with pixmaps broken in 1.0 final?
References: <Pine.GSO.4.05.9911171342330.13723-100000@inky> <017c01bf3c61$bcbed320$f29b12c2@secret.pythonware.com>
Message-ID: <007d01bf3d8a$30612fc0$f29b12c2@secret.pythonware.com>

I wrote:

> Robert Kern <kern@its.caltech.edu> wrote:
> > Under 1.0b1, the image is a square gradient going from red to green on a
> > red background.  Under 1.0 final, the image has the left half of the
> > gradient the same as previous, but the right half is a solid light blue,
> > no gradient at all.
> > 
> > Something in ImagingFill2 perhaps?
> 
> I can repeat the problem it on other platforms, so
> I guess I cannot blame your compiler ;-)
> 
> it's probably a signed/unsigned problem.  I'll look
> into it as soon as I find some time to spare.

a quick look reveals that the code in Paste.c
is completely braindead: filling with constant
colors and matte masks ("L" and "RGBA") simply
doesn't work.

filling with binary masks (mode "1") works fine,
though.

a rough workaround is to emulate what earlier
versions did: create a new image with the same
size as the pasted area and the fill colour, and
paste it. e.g:

    x0, y0, x1, y1 = bbox
    im.paste(
        Image.new("RGB", (x1-x0, y1-y0), color),
        bbox, mask
    )

I'll post patches for Paste.c during this weekend
(and update our regression test suite...)

</F>



From robert.klimek@grc.nasa.gov  Fri Dec  3 14:50:50 1999
From: robert.klimek@grc.nasa.gov (Bob Klimek)
Date: Fri, 03 Dec 1999 09:50:50 -0500
Subject: [Image-SIG] RPM file of PIL?
Message-ID: <3847D8CA.92264F85@grc.nasa.gov>

Hello All,

I just started looking at PIL and I have big plans for it. I'm running
Red Hat Linux and I'm looking for the latest RPM release. The one I
found was: "python-imaging-1.0b1-3.i386.rpm" which appears to be close
to a year old and a Beta. Is a newer release out there that anyone is
aware of?

Bob
-- 
---------------------
Robert B. Klimek
NASA Glenn Research Center
robert.klimek@grc.nasa.gov
---------------------


From fredrik@pythonware.com  Sat Dec  4 10:02:43 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sat, 4 Dec 1999 11:02:43 +0100
Subject: [Image-SIG] RPM file of PIL?
References: <3847D8CA.92264F85@grc.nasa.gov>
Message-ID: <013e01bf3e3e$b6431f90$f29b12c2@secret.pythonware.com>

Bob Klimek <robert.klimek@grc.nasa.gov> wrote:
> I just started looking at PIL and I have big plans for it. I'm running
> Red Hat Linux and I'm looking for the latest RPM release. The one I
> found was: "python-imaging-1.0b1-3.i386.rpm" which appears to be close
> to a year old and a Beta. Is a newer release out there that anyone is
> aware of?

nope.  looks like the debian folks are the only
ones who are tracking PIL tightly [1] at this time.

but on the other hand, PIL should build right out
of the box on your red hat box.   just make sure
you have the developer RPM's for Python on the
box, and the rest shouldn't be much harder than:

    ./configure
    make
    make install

and a little copying of PIL.pth and the PIL/*.py files
to a suitable place along the Python path.

</F>

http://www.debian.org/Packages/unstable/graphics/python-imaging.html
(matthias et al are even one step beyond the official release! ;-)



From oli@rz-online.net  Sat Dec  4 10:56:32 1999
From: oli@rz-online.net (Oliver Andrich)
Date: Sat, 4 Dec 1999 11:56:32 +0100
Subject: [Image-SIG] RPM file of PIL?
In-Reply-To: <3847D8CA.92264F85@grc.nasa.gov>; from robert.klimek@grc.nasa.gov on Fri, Dec 03, 1999 at 09:50:50AM -0500
References: <3847D8CA.92264F85@grc.nasa.gov>
Message-ID: <19991204115632.B2373@gothic.andrich.net>

Hi,

the Python4Linux people have packaged a current PIL release. This project is
the successor to the project I started with my python distirbution for Linux.
Go to

    http://starship.python.net/mailman/listinfo/python4linux

look at the archives or just go to

    http://www.2xtreme.net/chadn/python/

Best regards,

    Oliver

On Fri, Dec 03, 1999 at 09:50:50AM -0500, Bob Klimek wrote:
> Hello All,
> 
> I just started looking at PIL and I have big plans for it. I'm running
> Red Hat Linux and I'm looking for the latest RPM release. The one I
> found was: "python-imaging-1.0b1-3.i386.rpm" which appears to be close
> to a year old and a Beta. Is a newer release out there that anyone is
> aware of?
> 
> Bob
> -- 
> ---------------------
> Robert B. Klimek
> NASA Glenn Research Center
> robert.klimek@grc.nasa.gov
> ---------------------
> 
> _______________________________________________
> Image-SIG maillist  -  Image-SIG@python.org
> http://www.python.org/mailman/listinfo/image-sig
-- 
Oliver Andrich, KEVAG Telekom GmbH, Schlossstrasse 42, D-56068 Koblenz
Telefon: 0261-3921027 / Fax: 0261-3921033 / Web: http://rhein-zeitung.de



From robert.klimek@grc.nasa.gov  Tue Dec  7 14:25:21 1999
From: robert.klimek@grc.nasa.gov (Bob Klimek)
Date: Tue, 07 Dec 1999 09:25:21 -0500
Subject: [Image-SIG] PIL and PIL Plus
Message-ID: <384D18D1.364248CB@grc.nasa.gov>

Hello Fredrik,

I played around with PIL last few days and I really like it. But I found
it lacking some imaging operations which I will need on my next project,
such as some morphological operations. So I'm thinking about writing
them my self and then contributing them to the PIL package. However, I
have a few questions. Some of the questions arise from the apparent
conflict of interest between the free PIL and the PIL Plus which is not
free.

1. What happens if I contribute some imaging operations which you are
planning to add the PIL Plus library in the near future? Will you still
add them to free PIL?

2. What happens if I contribute some imaging operations which are
already in the PIL Plus library? Will you still add them to free PIL?

PIL Plus Questions

3. I am interested in using PIL with AVI files using either MJPEG,
INDEO, or DV codec. Any support for that in the PIL Plus package?

4. PIL Plus mentions support for the Matrox framegrabber. Will it be
possible to grab frames from the framegrabber?  How about display of
live video in a window or do you use a secondary monitor to display
video?

Take Care
Bob

-- 
---------------------
Robert B. Klimek
NASA Glenn Research Center
robert.klimek@grc.nasa.gov
---------------------


From pedro@www.nham.com  Tue Dec  7 16:11:12 1999
From: pedro@www.nham.com (Pedro Vale Lima)
Date: Tue, 7 Dec 1999 16:11:12 +0000 (WET)
Subject: [Image-SIG] Is PIL Windows broken?
Message-ID: <Pine.LNX.4.10.9912071606580.4101-100000@www.nham.com>

Is the binary for windows broken? I can't use it on my 1.5.2 instalation.
Does it need any extra files besides the download from pythonware?

could somenone help me please? 

pedro



From kuncej@mail.conservation.state.mo.us  Tue Dec  7 16:42:47 1999
From: kuncej@mail.conservation.state.mo.us (Jeffrey Kunce)
Date: Tue, 07 Dec 1999 10:42:47 -0600
Subject: [Image-SIG] Is PIL Windows broken?
Message-ID: <s84ce4db.080@mail.conservation.state.mo.us>

>Is the binary for windows broken? I can't use it on my 1.5.2 instalation.
>Does it need any extra files besides the download from pythonware?

It works for me fine on NT.=20
But I have troubles with it on Windows 98 - it has troubles locating the =
DLLs.

  --Jeff



From KCAZA@cymbolic.com  Tue Dec  7 21:40:08 1999
From: KCAZA@cymbolic.com (Kevin Cazabon)
Date: Tue, 07 Dec 1999 13:40:08 -0800
Subject: [Image-SIG] Is PIL Windows broken?
Message-ID: <s84d0e4a.062@cymbolic.com>

I've run into a small problem with it that's actually silly...

Python can use DLL files named either ".dll" or ".pyd".  It prefers ".pyd" files
however.

So, if your 'old' installation of PIL had ".pyd" files, but the new one has ".dll"s
(which are still hanging around because the didn't get overwritten when you
upgraded), you're hosed because it still loads the old ".pyd".

So, either delete the old "dll" files before installing the new PIL, or maybe we
should standardize on ".pyd" files.  Having both causes problems with both Tkinter
and _imaging.

Kevin Cazabon.

>>> "Jeffrey Kunce" <kuncej@mail.conservation.state.mo.us> 12/07/99 08:42AM >>>
>Is the binary for windows broken? I can't use it on my 1.5.2 instalation.
>Does it need any extra files besides the download from pythonware?

It works for me fine on NT. 
But I have troubles with it on Windows 98 - it has troubles locating the DLLs.

  --Jeff


_______________________________________________
Image-SIG maillist  -  Image-SIG@python.org 
http://www.python.org/mailman/listinfo/image-sig
                                                                                     
                                                                                     
                                                                                     
                                                                                     
                                                                                     
                                                                                     
                                                                                     
                                                                                     
                                                                                     
                                                                                     
                                                                                     
                                                                                     
                                                                                     
                                                                                     
                                                                                     
                                                                                     
                                                                                     
         


From fredrik@pythonware.com  Wed Dec  8 21:32:25 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 8 Dec 1999 22:32:25 +0100
Subject: [Image-SIG] Pasting with pixmaps broken in 1.0 final? [PATCH]
References: <Pine.GSO.4.05.9911171342330.13723-100000@inky> <017c01bf3c61$bcbed320$f29b12c2@secret.pythonware.com> <007d01bf3d8a$30612fc0$f29b12c2@secret.pythonware.com>
Message-ID: <087501bf41c3$b96b7a40$f29b12c2@secret.pythonware.com>

I wrote:
 
> > Robert Kern <kern@its.caltech.edu> wrote:
> > > Under 1.0b1, the image is a square gradient going from red to green on a
> > > red background.  Under 1.0 final, the image has the left half of the
> > > gradient the same as previous, but the right half is a solid light blue,
> > > no gradient at all.
> 
> I'll post patches for Paste.c during this weekend
> (and update our regression test suite...)

a little late, but here's the patch.  this will
be fixed in the upcoming 1.0.2 release.

</F>

--- libImaging/Paste.c.orig Mon Jul 26 23:02:14 1999
+++ libImaging/Paste.c Wed Dec 08 22:27:59 1999
@@ -13,6 +13,7 @@
  * 98-02-02 fl Fixed MULDIV255 macro for gcc
  * 99-02-02 fl Added "RGBa" mask support
  * 99-02-06 fl Rewritten.  Added support for masked fill operations.
+ * 99-12-03 fl Fixed matte fill.
  *
  * Copyright (c) Fredrik Lundh 1996-97.
  * Copyright (c) Secret Labs AB 1997-99.
@@ -345,7 +346,7 @@
 }
 
 static inline void
-fill_mask_L(Imaging imOut, const void* ink_, Imaging imMask,
+fill_mask_L(Imaging imOut, const UINT8* ink, Imaging imMask,
             int dx, int dy, int sx, int sy,
             int xsize, int ysize, int pixelsize)
 {
@@ -353,8 +354,6 @@
 
     int x, y, i;
     unsigned int tmp1, tmp2;
-    INT32 ink = 0L;
-    memcpy(&ink, ink_, pixelsize);
 
     if (imOut->image8) {
 
@@ -362,7 +361,7 @@
             UINT8* out = imOut->image8[y+dy]+dx;
             UINT8* mask = imMask->image8[y+sy]+sx;
             for (x = 0; x < xsize; x++) {
-                *out = BLEND(*mask, *out, ink, tmp1, tmp2);
+                *out = BLEND(*mask, *out, ink[0], tmp1, tmp2);
                 out++, mask++;
             }
         }
@@ -374,7 +373,7 @@
             UINT8* mask = (UINT8*) imMask->image[y+sy]+sx;
             for (x = 0; x < xsize; x++) {
                 for (i = 0; i < pixelsize; i++) {
-                    *out = BLEND(*mask, *out, ink, tmp1, tmp2);
+                    *out = BLEND(*mask, *out, ink[i], tmp1, tmp2);
                     out++;
                 }
                 mask++;
@@ -384,7 +383,7 @@
 }
 
 static inline void
-fill_mask_RGBA(Imaging imOut, const void* ink_, Imaging imMask,
+fill_mask_RGBA(Imaging imOut, const UINT8* ink, Imaging imMask,
                int dx, int dy, int sx, int sy,
                int xsize, int ysize, int pixelsize)
 {
@@ -392,8 +391,6 @@
 
     int x, y, i;
     unsigned int tmp1, tmp2;
-    INT32 ink = 0L;
-    memcpy(&ink, ink_, pixelsize);
 
     if (imOut->image8) {
 
@@ -402,7 +399,7 @@
             UINT8* out = imOut->image8[y+dy]+dx;
             UINT8* mask = (UINT8*) imMask->image[y+sy]+sx;
             for (x = 0; x < xsize; x++) {
-                *out = BLEND(*mask, *out, ink, tmp1, tmp2);
+                *out = BLEND(*mask, *out, ink[0], tmp1, tmp2);
                 out++, mask += 4;
             }
         }
@@ -416,7 +413,7 @@
             UINT8* mask = (UINT8*) imMask->image[y+sy]+sx;
             for (x = 0; x < xsize; x++) {
                 for (i = 0; i < pixelsize; i++) {
-                    *out = BLEND(*mask, *out, ink, tmp1, tmp2);
+                    *out = BLEND(*mask, *out, ink[i], tmp1, tmp2);
                     out++;
                 }
                 mask += 4;
@@ -426,7 +423,7 @@
 }
 
 static inline void
-fill_mask_RGBa(Imaging imOut, const void* ink_, Imaging imMask,
+fill_mask_RGBa(Imaging imOut, const UINT8* ink, Imaging imMask,
                int dx, int dy, int sx, int sy,
                int xsize, int ysize, int pixelsize)
 {
@@ -434,8 +431,6 @@
 
     int x, y, i;
     unsigned int tmp1;
-    INT32 ink = 0L;
-    memcpy(&ink, ink_, pixelsize);
 
     if (imOut->image8) {
 
@@ -444,7 +439,7 @@
             UINT8* out = imOut->image8[y+dy]+dx;
             UINT8* mask = (UINT8*) imMask->image[y+sy]+sx;
             for (x = 0; x < xsize; x++) {
-                *out = PREBLEND(*mask, *out, ink, tmp1);
+                *out = PREBLEND(*mask, *out, ink[0], tmp1);
                 out++, mask += 4;
             }
         }
@@ -458,7 +453,7 @@
             UINT8* mask = (UINT8*) imMask->image[y+sy]+sx;
             for (x = 0; x < xsize; x++) {
                 for (i = 0; i < pixelsize; i++) {
-                    *out = PREBLEND(*mask, *out, ink, tmp1);
+                    *out = PREBLEND(*mask, *out, ink[i], tmp1);
                     out++;
                 }
                 mask += 4;




From fredrik@pythonware.com  Wed Dec  8 21:43:58 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 8 Dec 1999 22:43:58 +0100
Subject: [Image-SIG] Patch for text chunks in PNGs
References: <199912022145.QAA04142@amarok.cnri.reston.va.us>
Message-ID: <08a001bf41c5$593f59f0$f29b12c2@secret.pythonware.com>

Andrew M. Kuchling <akuchlin@mems-exchange.org> wrote:
> Being able to add metadata to an image is of great importance to me;
> is there a list of which image plugins actually read in image metadata
> and write it out?  (Where the image format supports it, of course.)

image metadata is one big mess, and I'm afraid PIL
isn't doing much to make things better :-(

it would be great to do something about this in a
future version of PIL, but it's still just an item on
the (rather big) PIL wishlist...

until that happens, you may prefer to do like I do:
store the metadata *outside* the image file...

</F>



From akuchlin@mems-exchange.org  Wed Dec  8 21:45:01 1999
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Wed, 8 Dec 1999 16:45:01 -0500 (EST)
Subject: [Image-SIG] Patch for text chunks in PNGs
In-Reply-To: <08a001bf41c5$593f59f0$f29b12c2@secret.pythonware.com>
References: <199912022145.QAA04142@amarok.cnri.reston.va.us>
 <08a001bf41c5$593f59f0$f29b12c2@secret.pythonware.com>
Message-ID: <14414.53597.875817.795575@amarok.cnri.reston.va.us>

Fredrik Lundh writes:
>it would be great to do something about this in a
>future version of PIL, but it's still just an item on
>the (rather big) PIL wishlist...

Fair enough.  In my case, all I need is one format that supports it,
and with my patch, PNG fits the bill nicely...

>until that happens, you may prefer to do like I do:
>store the metadata *outside* the image file...

That would be doable, but it seems so much neater to embed the data
within the image file.  <shrug>

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
Anybody else on the list got an opinion? Should I change the language or not?
    -- Guido van Rossum, 28 Dec 91


From Anand.Kumria@eBioinformatics.com  Fri Dec 10 00:44:49 1999
From: Anand.Kumria@eBioinformatics.com (Anand.Kumria@eBioinformatics.com)
Date: Fri, 10 Dec 1999 11:44:49 +1100 (EST)
Subject: [Image-SIG] Compiling PIL 64 bit
Message-ID: <m11wEB4-000roOC@marine.internal.en-bio>

If you need to compile PIL on a 64 bit architectures then you will
probably want to add:

#include <unistd.h>

to encode.c (it uses the write syscall) if you are also using zlib.

zlib pulls in that header (unistd) and since on 64 bit architectures the
return type is defined (eventually) as long is conflicts with the
implicit int return value of write that a c compiler assumes.

Anand

PS : I am not subscribed to this list, so please CC any email to me



From fredrik@pythonware.com  Fri Dec 10 07:51:25 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 10 Dec 1999 08:51:25 +0100
Subject: [Image-SIG] Compiling PIL 64 bit
References: <m11wEB4-000roOC@marine.internal.en-bio>
Message-ID: <006001bf42e3$5cf06110$f29b12c2@secret.pythonware.com>

<Anand.Kumria@eBioinformatics.com> wrote:
> If you need to compile PIL on a 64 bit architectures then you will
> probably want to add:
> 
> #include <unistd.h>
> 
> to encode.c (it uses the write syscall) if you are also using zlib.

just curious -- but what 64 bit architecture?

(PIL builds out of the box on Digital Unix, so this
is maybe not a general problem for 64-bit boxes).

</F>



From Anand.Kumria@eBioinformatics.com  Fri Dec 10 09:00:38 1999
From: Anand.Kumria@eBioinformatics.com (Anand.Kumria@eBioinformatics.com)
Date: Fri, 10 Dec 1999 20:00:38 +1100 (EST)
Subject: [Image-SIG] Compiling PIL 64 bit
In-Reply-To: <006001bf42e3$5cf06110$f29b12c2@secret.pythonware.com>
Message-ID: <m11wLuu-000roOC@marine.internal.en-bio>

On 10 Dec, Fredrik Lundh wrote:
> <Anand.Kumria@eBioinformatics.com> wrote:
>> If you need to compile PIL on a 64 bit architectures then you will
>> probably want to add:
>> 
>> #include <unistd.h>
>> 
>> to encode.c (it uses the write syscall) if you are also using zlib.
> 
> just curious -- but what 64 bit architecture?

Oh, Solaris 2.7 sparc. I'm using the Sun Workshop compiler as well.

> (PIL builds out of the box on Digital Unix, so this
> is maybe not a general problem for 64-bit boxes).

It does? Great, I'll be testing some things out on that soon.

Anand
PS: Please CC any replies to me



From nessus@mit.edu  Sat Dec 11 01:27:22 1999
From: nessus@mit.edu (Douglas Alan)
Date: Fri, 10 Dec 1999 20:27:22 -0500
Subject: [Image-SIG] undefined symbol: XFreePixmap
Message-ID: <199912110127.UAA07928@gaffa.mit.edu>

Hi.  What does it mean if I get the following error message when I try
to import _imaging:

   ImportError: /usr/lib/libtk8.0.so: undefined symbol: XFreePixmap

Thanks for your help!

|>oug


From fredrik@pythonware.com  Sat Dec 11 13:19:10 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sat, 11 Dec 1999 14:19:10 +0100
Subject: [Image-SIG] undefined symbol: XFreePixmap
References: <199912110127.UAA07928@gaffa.mit.edu>
Message-ID: <010501bf43da$502f1e60$f29b12c2@secret.pythonware.com>

Douglas Alan <nessus@mit.edu> wrote:
> Hi.  What does it mean if I get the following error message when I try
> to import _imaging:
> 
>    ImportError: /usr/lib/libtk8.0.so: undefined symbol: XFreePixmap
> 
> Thanks for your help!

if there had been a FAQ, this question
would have been in it :-)

here's the standard answer:

    adding -lX11 to the Setup file should do the trick.

    (this is fixed in the upcoming 1.0.1)

</F>



From krt@krt.com.au  Wed Dec 15 10:49:55 1999
From: krt@krt.com.au (Kingsley Turner)
Date: Wed, 15 Dec 1999 21:49:55 +1100
Subject: [Image-SIG] PIL 1.0 (beta?) - Problem saving JPEG
Message-ID: <38577253.932ABD85@krt.com.au>

G'day,

I've got this occasional problem.

I have an image database,
we use http upload to get an image,
it's stored as a local file.

All this works fine, I've binary compared the upload
with what we get, and it's a 100% match.

So now _some_image_ is sitting in a known filename.
We use PIL to load the image, resize it to
some acceptable limit, and then save it as the master copy.

###
### Get some stats from the uploaded image
###
im = Image.open(pict_file_path)
pict_hires_x = im.size[0]
pict_hires_y = im.size[1]

###
### If the image is too big, resize it to 600x450ish
###
if pict_hires_x > 640 or pict_hires_y > 480:
    newx = 600
    newy = 450
    if pict_hires_x > pict_hires_y:
        newy = pict_hires_y * newx / pict_hires_x
    else:
        newx = pict_hires_x * newy / pict_hires_y
        pict_hires_x = newx
        pict_hires_y = newy
        im = im.resize((newx,newy))
###
### Save a reference copy
###
im.save(pict_file_path+".orig","JPEG",quality=80,optimize=1)

Now the problem...

In the last line of the code, *sometimes* if
quality=80, the save fails with the error - 
(depends entirely on the image uploaded)

Traceback (innermost last):
  File "/home/httpd/cgi-bin/picture_add.py", line 104, in ?
    im.save(pict_file_path+".orig","JPEG",quality=80,optimize=1)
  File "/usr/local/lib/python1.5/PIL/Image.py", line 665, in save
    SAVE[string.upper(format)](self, fp, filename)
  File "/usr/local/lib/python1.5/PIL/JpegImagePlugin.py", line 307, in
_save
    ImageFile._save(im, fp, [("jpeg", (0,0)+im.size, 0, rawmode)])
  File "/usr/local/lib/python1.5/PIL/ImageFile.py", line 223, in _save
    raise IOError, "encoder error %d when writing image file" % s
IOError: encoder error -2 when writing image file


At first I figured it must be some sort of image file format
problem, so I opened it in GIMP, resized it, saved it,
tried again - exactly the same.

When I changed the quality=70 the problem (at least for the
test image in question) disappeared.
Test image: http://MadDogsBreakfast.com/crocus.jpg

Does anyone have a clue as to what might be going on here ?

cheers,
-kt 

-- 
Kingsley Turner, mailto:kingsley@krt.com.au
Network R&D, KRT P/L
Mobile: +61 2419621568


From fredrik@pythonware.com  Wed Dec 15 12:35:42 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 15 Dec 1999 13:35:42 +0100
Subject: [Image-SIG] PIL 1.0 (beta?) - Problem saving JPEG
References: <38577253.932ABD85@krt.com.au>
Message-ID: <000901bf46f8$e796d9c0$f29b12c2@secret.pythonware.com>

Kingsley Turner <krt@krt.com.au> wrote:
> In the last line of the code, *sometimes* if
> quality=80, the save fails with the error - 
> (depends entirely on the image uploaded)

> Does anyone have a clue as to what might
> be going on here ?

it's probably a bug in PIL (or in the jpeg library, depending
on how you see it).  optimize simply doesn't work well if the
output file is larger than PIL's encoder block size (which is
64k by default).

possible workarounds (besides switching off optimization
completely):

1) increase the block size, e.g:

    import ImageFile
    ImageFile.MAXBLOCK = 1000000

2) fall back on an "unoptimized save" if it fails with
   optimization:

    try:
        im.save(pict_file_path+".orig","JPEG",quality=80,optimize=1)
    except IOError:
        # try again, without optimization
        im.save(pict_file_path+".orig","JPEG",quality=80)

</F>



From jessw@loop.com  Sat Dec 18 15:43:23 1999
From: jessw@loop.com (Jesse W)
Date: Sat, 18 Dec 1999 15:43:23 +0000
Subject: [Image-SIG] Help!  I cannot install PIL!
Message-ID: <199912182346.PAA02167@stevie.loop.com>

	I am new at compileing programs and addons, and I do not understand 
how Dll's and other wild Windows things work.  I have downloaded *a* 
PIL instellation(Imaging-0_2b4-win32.zip), but I am not sure if it is 
the newest, or why I would want the newest, or even what version it 
is.  In the readme file it says it is: PIL 0.2b4 for Windows 95/NT.  
I have followed the install instructions in the readme file, looked 
in Image-Sig archives, and followed any instructions I found, and I 
still get the same errror message.  When I run viewer.py, I get:

Traceback (innermost last):
  File "C:\Python\Programs\Imaging-2b4\Scripts\viewer.py", line 7, in  ?
    import Image, ImageTk
ImportError: No module named Image

I don't know what to do.

							Jesse Weinstein


From akuchlin@mems-exchange.org  Tue Dec 21 16:07:53 1999
From: akuchlin@mems-exchange.org (Andrew M. Kuchling)
Date: Tue, 21 Dec 1999 11:07:53 -0500 (EST)
Subject: [Image-SIG] PXC200 frame grabber support
Message-ID: <199912211607.LAA04814@amarok.cnri.reston.va.us>

The wrangling with the lawyers is now over, and I can release a module
that adds support for the Linux PXC-200 frame grabber driver to PIL.
Like the SANE module, the module lets you acquire images from the
device, returning them as PIL Image objects that can be scaled,
transformed, converted to different formats, or whatever you like.
Performance is pretty good; on a 450MHz Pentium machine running Linux,
PIL can acquire around 27 frames per second.

http://www.mems-exchange.org/software/python/pxc200/

(/F, feel free to add the code into the PIL source tree if you like.)

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
Earth... the most awful place you can imagine, if you live in Los Angeles.
Other than that, it's pretty neat.
    -- STANLEY AND HIS MONSTER #1



From fredrik@pythonware.com  Mon Dec 27 09:39:50 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Mon, 27 Dec 1999 10:39:50 +0100
Subject: [Image-SIG] PIL
References: <NABBIJCJEKDELBNPDHAPGEBGGNAA.mednikov@netvision.net.il>
Message-ID: <01fb01bf504e$52fb5f20$f29b12c2@secret.pythonware.com>

> I've downloaded PIL. After installation on my Linux Mandrake OS
> I have this problem:
> When I write 
> import _imaging
> I get the error:
> ImportError: /usr/lib/libtk.8.0.so: undefined symbol: XFreePixmap 

recently seen on this mailing list:

    if there had been a FAQ, this question
    would have been in it :-)

    here's the standard answer:

        adding -lX11 to the Setup file should do the trick.

        (this is fixed in the upcoming 1.0.1)

hope this helps!

</F>



From jblaine@shore.net  Thu Dec 30 18:29:31 1999
From: jblaine@shore.net (Jeff Blaine)
Date: Thu, 30 Dec 1999 13:29:31 -0500 (EST)
Subject: [Image-SIG] PIL 1.0 palette
Message-ID: <Pine.SOL.4.10.9912301324020.29811-100000@shell2>

Hi folks,

I've gotten up to speed so far to do everything I want (make pie charts)
with PIL.  Yay!

However, my charts are very drab from using the default palette for mode
"P" (I am writing GIFs).

I have read through the PIL 1.0 handbook and cannot figure out how to
change my palette properly.

If I do:

  im = Image.new("P", (ImageWidth, ImageHeight))
  im.palette = ImagePalette.ImagePalette("RGB")

I get:

    File "/jblaine/mylocal/lib/python15/Image.py", line 375, in load
      if self.im and self.palette and self.palette.rawmode:
  AttributeError: rawmode

and aside from that, I can't figure out how to just get a "simple"
"rainbow" palette (wow, I'm pretty imaging-lingo savvy, eh?).

Maybe I can kill 2 birds with one stone here and also mention that I
want "Black" to be transparent in my output images."

Anyone have any pointers or code I can look at?  PIL comes with no
demos that perform ImageDraw.* things that I can find.

Thanks for your time



From benoitde@bigfoot.com  Fri Dec 31 02:28:22 1999
From: benoitde@bigfoot.com (Denis Benoit)
Date: Thu, 30 Dec 1999 21:28:22 -0500 (EST)
Subject: [Image-SIG] PIL 1.0 palette
In-Reply-To: <Pine.SOL.4.10.9912301324020.29811-100000@shell2>
Message-ID: <Pine.LNX.4.21.9912302101270.1199-100000@lbdev001.idb>

On Thu, 30 Dec 1999, Jeff Blaine wrote:

> Hi folks,
> 
> I've gotten up to speed so far to do everything I want (make pie charts)
> with PIL.  Yay!
> 
> However, my charts are very drab from using the default palette for mode
> "P" (I am writing GIFs).
> 
> I have read through the PIL 1.0 handbook and cannot figure out how to
> change my palette properly.
> 
> If I do:
> 
>   im = Image.new("P", (ImageWidth, ImageHeight))
>   im.palette = ImagePalette.ImagePalette("RGB")
> 
> I get:
> 
>     File "/jblaine/mylocal/lib/python15/Image.py", line 375, in load
>       if self.im and self.palette and self.palette.rawmode:
>   AttributeError: rawmode
> 
> and aside from that, I can't figure out how to just get a "simple"
> "rainbow" palette (wow, I'm pretty imaging-lingo savvy, eh?).
> 
> Maybe I can kill 2 birds with one stone here and also mention that I
> want "Black" to be transparent in my output images."
> 
> Anyone have any pointers or code I can look at?  PIL comes with no
> demos that perform ImageDraw.* things that I can find.
> 
> Thanks for your time
> 
> 
> _______________________________________________
> Image-SIG maillist  -  Image-SIG@python.org
> http://www.python.org/mailman/listinfo/image-sig

Hi,

I recently faced the same problem, generating pie charts in "GIF" format, on
a "transparent" backround.  Here is my findings, I must say I'm NOT a python
expert or a PIL expert, I've been using python for less than a week and PIL
for about the same time!

First on the "palette" problem:

Somewhere in the docs, or is it on the site, it says that the proper way to
change palette, is to use the "putpalette" method of the Image object.  So
your code should read something like that:

	im = Image.new("P", (ImageWidth, ImageHeight))
	palette = ImagePalette.ImagePalette("RGB")
	im.putpalette(palette.palette)

But you'll get the same "drab" palette you're reporting.  It seems the palette
is just a list of integers.  I have found that each group of three integers in
the palette will generate a "colour".  For example, the colour of index 0 is
coded by the elements 0, 1 and 2 of the palette.  If you put the following:

	palette.palette[0] = 0
	palette.palette[1] = 0
	palette.palette[2] = 0

Then the colour #0 of your palette will be black (Red = 0, Green = 0, Blue =
0).  Now if you follow with:

	palette.palette[3] = 255
	palette.palette[4] = 255
	palette.palette[5] = 255

	palette.palette[6] = 255
	palette.palette[7] = 0
	palette.palette[8] = 0

The colour #1 of your palette would be white (Red = 255, Green = 255, Blue =
255), and the colour #2 of your palette would be red (Red = 255, Green = 0,
Blue = 0).

Second the "transparency" problem:

This one is a little tougher.  The "GIF" plugin does recognize the
"transparency" feature on a "GIF" but it does not save it on output.  I'm no
expert on "GIF", I simply reversed engineered what it does on input to put
"transparency" support on output.

If you do modify the GifImagePlugin.py, save a copy first so you can restore
it if you mess things up.

I haven't figured out how to add transparency support on the "save()" method
call of the Image object, so I only add a "transparency" entry into the
"info" dictionary of the image, like this:

	im.info["transparency"] = 125

So the colour #125 in my palette is used for the transparency colour.

I then modified the method of GifImagePlugin.py:

def _save(im, fp, filename):

	<...>
    try:
        interlace = im.encoderinfo["interlace"]
    except:
        # default is on (since we're writing uncompressed images)
        interlace = 1
        flags = flags | 64


    ########################################################################
    # 1999.12.26 Denis Benoit:
    #
    # Write transparency:
    # "! <249>" Gif Extension intro
    # "<4>" extension length
    # "<1>" Flags: transparency palette info present
    # "<0> <0>" duration of the image (multi-image)
    # "chr(<transparency>)" Transparency index in the palette
    # "<0>" End of additional headers
    ########################################################################
    try:
        transparency = im.info["transparency"]
        fp.write("!" + chr(249) + chr(4) + chr(1) +
                 chr(0) + chr(0) + chr(transparency) + chr(0))
    except:
        # No transparency info
        pass

    # local image header
    fp.write("," +
             o16(0) + o16(0) +          # bounding box
             o16(im.size[0]) +          # size
             o16(im.size[1]) +
             chr(flags) +               # flags
             chr(8))                    # bits

The "new" code is just between the "interlace" support and the "header" code.
It should be around line 248 of the file.  It worked for me!

Hope this info helps you.

Denis Benoit