From herzog@online.de  Wed Feb  3 18:18:57 1999
From: herzog@online.de (Bernhard Herzog)
Date: Wed, 3 Feb 1999 19:18:57 +0100
Subject: [Image-SIG] PIL 1.0b1 can't read PCX files
Message-ID: <199902031818.TAA00320@greebo.nodomain.de>

PIL 1.0b1 can't read PCX files. This is the traceback:

Python 1.5.1 (#6, Nov 12 1998, 22:06:25)  [GCC 2.7.2.1] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import Image 
>>> Image.open('cork1c.pcx')
<PcxImagePlugin.PcxImageFile instance at 8164288>
>>> _.load()
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/site-packages/PIL/ImageFile.py", line 134, in load
    d = Image._getdecoder(self.mode, d, a, self.decoderconfig)
  File "/usr/local/lib/python1.5/site-packages/PIL/Image.py", line 225, in _getdecoder
    return apply(decoder, (mode,) + args + extra)
ValueError: unknown raw mode
>>> 


The earlier versions (e.g. 0.3b2) didn't have problems with this.

If necessary, I can mail you (Fredrik) the pcx file.




	Bernhard


From fredrik@pythonware.com  Thu Feb  4 19:36:55 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Thu, 4 Feb 1999 20:36:55 +0100
Subject: [Image-SIG] PIL 1.0b1 can't read PCX files
Message-ID: <001101be5075$c8d376d0$f29b12c2@pythonware.com>

Bernhard Herzog wrote:
>PIL 1.0b1 can't read PCX files. This is the traceback:
>
/.../
>  File "/usr/local/lib/python1.5/site-packages/PIL/Image.py", line 225, in _getdecoder
>    return apply(decoder, (mode,) + args + extra)
>ValueError: unknown raw mode

quick fix: in PcxImagePlugin.py:

            if ord(s[0]) == 12:
                self.palette = ImagePalette.raw("RGB", s[1:])
                self.mode = "P"

becomes

            if ord(s[0]) == 12:
                self.palette = ImagePalette.raw("RGB", s[1:])
                self.mode = rawmode = "P"

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




From bsavage@stanford.edu  Thu Feb  4 22:34:06 1999
From: bsavage@stanford.edu (Bob Savage)
Date: Thu, 04 Feb 1999 14:34:06 -0800
Subject: [Image-SIG] Transparency not supported on Mac?
Message-ID: <199902042234.OAA24578@smtp2.Stanford.EDU>

Hi,

I am not able to properly display with Tkinter, & PIL a GIF file which has
transparency turned on on my Mac. Is there anyone out there who can confirm
this for me?

This URL points to a .sit file which demonstrates my attempts to use both
straight Tkinter & PIL. The GIFs show properly if the transparency is not
turned on, but with transparency turned on (GIF89a export from PhotoShop)
they look really messed up. If you download the file and run it on your
system, and it looks fine, please let me know. I tried to run these tests
on a windows machine, but there seems to be some problem with the install
'cuz neither script will run. When I drag the transparent GIF into a
browser window with a non-white background I can clearly see the
transparent effect, so I don't believe it's the file.

<ftp://216.101.184.71/transparency.sit>

thanks for any help,

Bob
--
Bob Savage
Media Preservation Unit
Stanford University Libraries
Galvez Modular, #122
Stanford, CA 94305-6004

ph. (650) 723-3970


From fredrik@pythonware.com  Thu Feb  4 22:55:25 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Thu, 4 Feb 1999 23:55:25 +0100
Subject: [Image-SIG] now is the time...
Message-ID: <018d01be5091$77755210$f29b12c2@pythonware.com>

PIL 1.0 final isn't far away.  I'm pretty much waiting
for Guido to freeze 1.5.2 (to make sure 1.5.2 final
doesn't break PIL...)

so now is the right time to speak up if there's any-
thing in the current beta that's bothering you.

here's what's fixed right now:

-- BICUBIC on RGB images actually called BILINEAR
   (bug reported by Gary Herron and others)

-- 8-bit PCX images now works again
   (bug reported by Bernard Herzog, of Sketch
   fame).

-- speedups when pasting RGBA images on RGB

-- new experimental mode: RGBa which is similar
   to RGBA, but the colour components are pre-
   multiplied with the alpha.  you can convert
   RGBA => RGBa, and paste RGBa on RGB images
   (which is about twice as fast as pasting RGBA
   images...).  you cannot use RGBa for anything
   else -- it's only there to speed up compositing.

-- some optimizations and minor tweaks in the
   ImageDraw polygon renderer

-- color fixes in ImageDraw.text
   (hmm.  forgot who reported this).

-- minor tweaks to make Mac compilers happy
   (Jack Jansen, Rob Managan)

-- probably some more things I've forgotten about
   right now...

here's what's going to be fixed before the release:

-- improvements to the Tiff codec

-- under 1.5.2, PIL can hook itself into a standard
   version of Tk.  (if you're doing anything serious
   with Tk on Windows, you'll want the patched
   version anyway...).

-- maybe some more small windows-specific things,
   that I cannot talk about right now...

Cheers /F



From fredrik@pythonware.com  Fri Feb  5 12:02:05 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Fri, 5 Feb 1999 13:02:05 +0100
Subject: [Image-SIG] FYI53: How to create a palette image?
Message-ID: <003a01be50ff$59e9f520$f29b12c2@pythonware.com>

I've received several questions on this lately (off this
list, unfortunately), so I finally gave in and wrote a
short FYI on this topic:

http://www.pythonware.com/people/fredrik/fyi/fyi53.htm

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



From tsbarry@nortelnetworks.com  Fri Feb  5 12:54:27 1999
From: tsbarry@nortelnetworks.com (Barry Scott)
Date: Fri, 5 Feb 1999 12:54:27 -0000
Subject: [Image-SIG] now is the time...
Message-ID: <81C8165DD2A7D111AD700000F81F29CB02504A50@nwcwi19.europe.nortel.com>

MIME-version: 1.0
Content-type: text/plain; charset="iso-8859-1"

/F,
	One more bug report.

	

	I'm using PIL to create a GIF image with some text on it.

	The ImageFont code is taking up lots of time to do its work.

	I have started to optiomize ImageFont and hope contribute
	a speed up soon. The two things I noticed where:

	It read the font description using 256 reads of 20 bytes.
	Using 1 read of 20*256 gets a 5% speed up.

	The other thing that I'm still trying is to use struct rather them
i16
	and the lambda loop. (I made the change and made python use up
	all available memory and raise a memory exception. This is under
	FreeBSD and I'm going to investigate this weekend.)

	How fully you can include the speed up the release 1.0.

		Barry
p.s.
> -- color fixes in ImageDraw.text (hmm. forgot who reported this).



From tsbarry@nortelnetworks.com  Fri Feb  5 13:16:45 1999
From: tsbarry@nortelnetworks.com (Barry Scott)
Date: Fri, 5 Feb 1999 13:16:45 -0000
Subject: [Image-SIG] PIL Bug report and performance problem
Message-ID: <81C8165DD2A7D111AD700000F81F29CB02504A52@nwcwi19.europe.nortel.com>

/F,
	Opss... a draft of this message escaped before I finished
	it off, sorry.

	Bug report
	----------

	bdf2pil.py does not work. Python reports:

$ python ../tmp/Imaging-1.0b1/Scripts/bdf2pil.py courR10.bdf
BDF2PIL 1.0 -- Font compiler for X BDF fonts.
Copyright (c) Fredrik Lundh 1996.  All rights reserved.
courR10.bdf
# Adobe;Courier;Medium;Roman;Normal;;10;100;75;75;Monospaced;60;ISO8859;1
Traceback (innermost last):
  File "../tmp/Imaging-1.0b1/Scripts/bdf2pil.py", line 205, in ?
    image, srcbbox = font2image(font, ascent, descent)
  File "../tmp/Imaging-1.0b1/Scripts/bdf2pil.py", line 155, in font2image
    d = Image.core.hex_decoder("1")
TypeError: function requires exactly 2 arguments; 1 given

	This fix seems to work.

155c155
<           d = Image.core.hex_decoder("1")
---
>           d = Image.core.hex_decoder("1","1")         # BAS	

	Performance problem in Image font
	---------------------------------

	I'm using PIL to create a GIF image with some text on it.

	The ImageFont code is taking up lots of time to do its work.

	I have started to optiomize ImageFont and hope contribute
	a speed up soon. The two things I noticed where:

	It read the font description using 256 reads of 20 bytes.
	Using 1 read of 20*256 gets a 5% speed up.

	The other thing that I'm still trying is to use struct rather
	them i16 and the lambda loop. (I made the change but python
	use up all available memory and raise a memory exception. This
	is under FreeBSD and I'm going to investigate this weekend.)

	Hopefully you can include the speed up the release 1.0.

		Barry
p.s.
> -- color fixes in ImageDraw.text
>     (hmm. forgot who reported this).

	That was me.


From herzog@online.de  Fri Feb  5 13:41:26 1999
From: herzog@online.de (Bernhard Herzog)
Date: Fri, 5 Feb 1999 14:41:26 +0100
Subject: [Image-SIG] now is the time...
In-Reply-To: <018d01be5091$77755210$f29b12c2@pythonware.com>
 (fredrik@pythonware.com)
References: <018d01be5091$77755210$f29b12c2@pythonware.com>
Message-ID: <199902051341.OAA00372@greebo.nodomain.de>

> so now is the right time to speak up if there's any-
> thing in the current beta that's bothering you.

What I'd like to see in the final version of PIL is a standard way to
install the C headerfiles. I'd suggest to put them into a subdirectory
where the standard Python headers are installed (e.g.
/usr/local/include/python1.5/Extensions/).  

The maintainer of the debian PIL package seems to install the
headerfiles directly in /usr/include/python1.5 (at least that's what one
Sketch user told me about a debian 2.1 beta).

Sketch would be much easier to configure if this were implemented. A
very simple 'implementation' would be to add some notes to this effect
to the installation instructions in the README. 

The files Sketch needs are Imaging.h ImConfig.h and ImPlatform.h from
the libImaging subdirectory.

Other third party C-modules that have to access PIL images would also
benefit from this.


This issue of installing headerfiles for C-modules is not just limited
to PIL. Perhaps this should also be posted to the newsgroup and/or the
distutils SIG.


	  Bernhard


From kdart@cisco.com  Fri Feb  5 20:28:59 1999
From: kdart@cisco.com (Keith Dart)
Date: Fri, 5 Feb 1999 12:28:59 -0800 (PST)
Subject: [Image-SIG] Re: Problems with new image creation
In-Reply-To: <001301be50f6$87bbc7c0$f29b12c2@pythonware.com>
Message-ID: <Pine.LNX.4.05.9902051214380.23969-100000@kdart-pc.cisco.com>

Thanks a bunch for the helpful suggestion. That worked. Note that my
original attempt is exactly what is shown in the manual...

BTW, are you aware of any high-level graph/plotting functions/classes that
use PIL? I found one that uses the GD library, but not PIL.

Thanks again,
Keith Dart

On Fri, 5 Feb 1999, Fredrik Lundh wrote:

> >Hello, I'm trying to use the 1.0b1 PIL package to generate some GIF files
> >from scratch. This is for a web application. I'm trying to generate a new
> >.gif file where none existed before, with a color palette. However, I get
> >errors when trying to apply a new palette (it seems to default to
> >greyscale).  Here's the script:
> >
> >------------------------
> >#!/usr/bin/python
> >
> >import sys, os
> >import Image
> >import ImageDraw, ImagePalette
> >
> >im = Image.new('P', (640,480), 255)
> 
> ...
> 
> try setting the palette using "putpalette"
> instead (I doubt this is documented):
> 
> palette = []
> for i in range(256):
>     palette = palette + [i, i, i]
> im.putpalette(palette)




-- --------------------------------------------------------------------------
Keith Dart, Devtest Engineer, Linux Bigot        <mailto:kdart@cisco.com>
Cisco Systems                                    phone: +1.408.527.1391
Network to User Business Unit                    pager: +1.800.365.4578
internal web page: <http://kdart-pc.cisco.com/>
external web page: <http://www.employees.org/~kdart/>
=============================================================================



From fredrik@pythonware.com  Sun Feb  7 11:34:02 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sun, 7 Feb 1999 12:34:02 +0100
Subject: [Image-SIG] PIL Bug report and performance problem
Message-ID: <004f01be528d$c4148ca0$f29b12c2@pythonware.com>

Barry Scott wrote:
> bdf2pil.py does not work. Python reports:

bdf2pil.py is obsolete (shouldn't have been in the
distribution). Use pilfont.py instead.

> Performance problem in Image font

I just did some radical changes on this front in the
current codebase. First, there's a new internal "fill
with mask" primitive, which is used by several
functions:

-- the "paste" method can now take a colour value as
the source (well, it has supported this for a while, but
it then created a temporary image -- pretty slow, in
other words. The new version is really fast).

-- there's a new "bitmap" operation in the ImageDraw
interface that draws an "1" image in the current colour.
Also supports "antialiased" bitmaps; an "L" image is inter-
preted as an alpha layer (doesn't work for all target
modes, though).

-- and "text" uses this function, of course.

I've also moved some of the font functionality (getsize,
getmask) into C code for better speed.

This also means that there will probably be a very short
second beta (maybe labelled "release candidate 1" just
to make sure any build or platform dependent problems
are fixed before the final release).

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



From fredrik@pythonware.com  Tue Feb  9 11:15:27 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Tue, 9 Feb 1999 12:15:27 +0100
Subject: [Image-SIG] help wanted: new GIF encoder needs testing!
Message-ID: <017801be541d$861943a0$f29b12c2@pythonware.com>

By some odd reason, I wrote a PCX encoder for PIL this
weekend.  While PCX uses a simple run-length encoding
scheme, it still produced files that were much smaller
than the "uncompressed by legal reasons" GIF files you
get from the current version of PIL.

Anyway, when my good friend the Mad Scientist heard
about this, he asked me why I didn't use run-length
encoding also for the GIF files (while run-length en-
coding often gives smaller files, it's not even remotely
similar to LZW).

 After some experimentation, I've managed to write a new
GIF encoder which uses run-length encoding (this wasn't
entirely trivial ;-).  this gives files that are typically 30%-50%
of the size generated by earlier versions (ranging from
exactly the same size as before, down to files that are
actually smaller than the corresponding GIF files...)

But I need your help in testing this on a larger sample
of GIF files and GIF readers.  If you have some time to
spare, and a PIL 1.0b1 build within reach, you can grab
the "patch" from:

    http://www.pythonware.com/madscientist/gif-990208.zip

replace libImaging/Gif.h and libImaging/GifEncode.c with
the versions in this file, and rebuild.  You can then use
the checkgif.py script on a bunch of existing GIF files to
make sure it works on your data.

If you have some extra time to spare, you could also try
loading GIF files generated by this encoder with whatever
GIF-reading software you have.

Report your findings to me or to this list.  If I don't hear
anything at all, or if I only hear positive things, this will
go into the next release.

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



From cgw@pgt.com  Tue Feb  9 18:31:04 1999
From: cgw@pgt.com (Charles G Waldman)
Date: Tue, 9 Feb 1999 13:31:04 -0500 (EST)
Subject: [Image-SIG] Sun Rasterfile support broken in 1.0b1
Message-ID: <14016.32488.511623.974127@janus.pgt.com>


I just came across this, when running a script to batch-convert some
older Sun .RAS files to a different format:


janus:~> file eq.ras
eq.ras: Sun raster image data, 640 x 480, 8-bit, RGB colormap

janus:~> python
Python 1.5.2b2 (#2, Jan 12 1999, 16:00:44)  [GCC egcs-2.90.29 980515 (egc on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> import Image
>>> Image.VERSION
'1.0b1'
>>> x=Image.open("eq.ras")
>>> x.save("eq.png")
Traceback (innermost last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python1.5/site-packages/PIL/Image.py", line 654, in save
    self.load()
  File "/usr/local/lib/python1.5/site-packages/PIL/ImageFile.py", line 134, in load
    d = Image._getdecoder(self.mode, d, a, self.decoderconfig)
  File "/usr/local/lib/python1.5/site-packages/PIL/Image.py", line 225, in _getdecoder
    return apply(decoder, (mode,) + args + extra)
ValueError: unknown raw mode



I'm looking into the problem; I don't have a fix yet however.  In the
meanwhile I just wanted to bring it to your attention.


From tsbarry@nortelnetworks.com  Tue Feb  9 11:03:48 1999
From: tsbarry@nortelnetworks.com (Barry Scott)
Date: Tue, 9 Feb 1999 11:03:48 -0000
Subject: [Image-SIG] PIL Bug report and performance problem
Message-ID: <81C8165DD2A7D111AD700000F81F29CB02504A57@nwcwi19.europe.nortel.com>

/F wrote:

> bdf2pil.py is obsolete (shouldn't have been in the
> distribution). Use pilfont.py instead.

O.K. - Please make it clear in the docs how to make fonts
and where to get the BDF files from. I got them from the
XFree86 Source distribution.

	BArry


From fredrik@pythonware.com  Wed Feb 10 09:08:24 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 10 Feb 1999 10:08:24 +0100
Subject: [Image-SIG] Sun Rasterfile support broken in 1.0b1
Message-ID: <004e01be54d4$fb21d150$f29b12c2@pythonware.com>

>I just came across this, when running a script to batch-convert some
>older Sun .RAS files to a different format:

probably the same problem as with 8-bit PCX files (a
change in Unpack.c made it less tolerant for mode/raw-
mode mismatches -- I thought I'd fixed all of them before
the release, but I obviously missed a few...)

try changing:

	    if self.mode == "L":
		self.mode = "P"

to:

if self.mode == "L":
self.mode = rawmode = "P"

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



From cgw@alum.mit.edu  Wed Feb 10 14:08:34 1999
From: cgw@alum.mit.edu (Charles G Waldman)
Date: Wed, 10 Feb 1999 09:08:34 -0500 (EST)
Subject: [Image-SIG] Sun Rasterfile support broken in 1.0b1
In-Reply-To: <004e01be54d4$fb21d150$f29b12c2@pythonware.com>
References: <004e01be54d4$fb21d150$f29b12c2@pythonware.com>
Message-ID: <14017.37602.618254.298334@sirius>

Fredrik Lundh writes:

 > try changing:
 > 
 > 	    if self.mode == "L":
 > 		self.mode = "P"
 > 
 > to:
 > 
 > if self.mode == "L":
 > self.mode = rawmode = "P"

That indeed fixes the problem with Sun Rasterfiles.  
Thanks.




From fredrik@pythonware.com  Wed Feb 10 14:51:42 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 10 Feb 1999 15:51:42 +0100
Subject: [Image-SIG] now is the time...
Message-ID: <003f01be5504$e0613650$f29b12c2@pythonware.com>

Bernhard Herzog wrote:
>What I'd like to see in the final version of PIL is a standard way to
>install the C headerfiles. I'd suggest to put them into a subdirectory
>where the standard Python headers are installed (e.g.
>/usr/local/include/python1.5/Extensions/).

I agree, but I currently lack the time and clues needed to
do something intelligent about this.   Maybe someone else
could come up with a good solution, and a patch or two?

 Please? /F
fredrik@pythonware.com
http://www.pythonware.com



From fredrik@pythonware.com  Wed Feb 10 14:57:33 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 10 Feb 1999 15:57:33 +0100
Subject: [Image-SIG] raw decoder change 0.3a4 -> 1.0b1
Message-ID: <004f01be5505$b1caadc0$f29b12c2@pythonware.com>

Rob Hooft once wrote:
>With 0.3a4, I could do:
>
>        im=Image.fromstring("P",(self.h.xsize,self.h.ysize),
>                            data.astype(Numeric.Int8).tostring(),"raw","L")
>        im.palette=Palette(self.palette)
>
>This now gives a "ValueError" exception. I currently (1.0b1) have the code:
>
>        im=Image.fromstring("L",(self.h.xsize,self.h.ysize),
>                            data.astype(Numeric.Int8).tostring(),"raw","L")
>        im.mode="P"
>        im.palette=Palette(self.palette)
>
>Just to make sure: is this "proper-PIL" coding? Any cleaner alternatives?

Without testing your code, I think this is the PCX and Sun Raster
buglet once again.  The rawmode (here, the last argument to
fromstring) must be compatible with the mode (the first
argument).  "P" and "L" are two different things,  but earlier
versions didn't really care since the internal layout is the
same.

On the other hand, patching the mode attribute is really
dangerous.  Here's what I would try (untested):

>        im=Image.fromstring("P",(self.h.xsize,self.h.ysize),
>                            data.astype(Numeric.Int8).tostring(),"raw","P")
>        im.palette=Palette(self.palette)

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




From herzog@online.de  Wed Feb 10 19:26:07 1999
From: herzog@online.de (Bernhard Herzog)
Date: 10 Feb 1999 20:26:07 +0100
Subject: [Image-SIG] now is the time...
In-Reply-To: "Fredrik Lundh"'s message of Wed, 10 Feb 1999 15:51:42 +0100
References: <003f01be5504$e0613650$f29b12c2@pythonware.com>
Message-ID: <m3iudajc1c.fsf@greebo.nodomain.de>

"Fredrik Lundh" <fredrik@pythonware.com> writes:

> Bernhard Herzog wrote:
> >What I'd like to see in the final version of PIL is a standard way to
> >install the C headerfiles. I'd suggest to put them into a subdirectory
> >where the standard Python headers are installed (e.g.
> >/usr/local/include/python1.5/Extensions/).
> 
> I agree, but I currently lack the time and clues needed to
> do something intelligent about this.   Maybe someone else
> could come up with a good solution, and a patch or two?


I see two possible solutions for this:

1) extend Makefile.pre.in to install the package (the current install
   target would just install _imaging.so in the site-packages directory)
   This solution would probably be only useful for UNIX-like systems.

2) write an install script in Python for portability.


I'm in favor of 2) and I'd be willing to adapt the setup.py script I've
written for the new Sketch release.

So, my proposal would be a script install.py that installs PIL as a
package in

os.path.join(sys.prefix, 'lib', 'python' + sys.version[:3], 'site-packages')

and the header-files in 

os.path.join(sys.prefix, 'include', 'python' + sys.version[:3], 'Extensions')

The site-package directory could alternatively be determined from
sys.path or by grepping through the generated Makefile.

The script would, of course, have some command-line options to override
the defaults.

I think this would be enough for UNIX-like systems.



Questions:

1) How would this have to be done in Windows?

2) Which header-files have to be installed? Sketch only needs Imaging.h,
   ImConfig.h and ImPlatform.h.


The issue of the header files also raises the question of the public
C-interface of PIL. I.e. which structures and functions can be safely
used by third party modules such as Sketch and how to get the function
pointers?

I don't know whether it is really necessary to be able to access the
functions from C, in most cases it is much simpler and not significantly
slower to do that from Python code. Sketch at least only needs the
declarations of the image structs to access the data, it doesn't call
any PIL functions from C.


Any comments or other suggestions?


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


From KCAZA@cymbolic.com  Fri Feb 12 20:40:19 1999
From: KCAZA@cymbolic.com (Kevin Cazabon)
Date: Fri, 12 Feb 1999 12:40:19 -0800
Subject: [Image-SIG] Where to implement other resizing methods...
Message-ID: <s6c4287a.078@cymbolic.com>

I wish to add an interpolation algorythm to the resizing method of PIL... I'm just wondering where the current nearest-neighbour and antialias methods are implemented so that I can add INTERPOLATE to them.

Any hints/suggestions, or anyone currently have a working interpolation resizing method?


Thanks,

Kevin Cazabon
kcaza@cymbolic.com
kcazabon@rogers.wave.ca
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         


From lourette@localnet.com  Sat Feb 13 04:37:11 1999
From: lourette@localnet.com (Lourette)
Date: Fri, 12 Feb 1999 23:37:11 -0500
Subject: [Image-SIG] Where to implement other resizing methods...
In-Reply-To: <s6c4287a.078@cymbolic.com>
Message-ID: <3.0.1.32.19990212233711.006bbda4@mail.localnet.com>

There is an algorithm in the graphics Gems series (Graphics Gems III) that
I have used in the past. 'C' code is listed there and can be found in
archives on the Internet. Do a search for graphics gems.

Another algorithm, which is called "Image resampling with coefficient bins"
can be found in the book, "Digital Image Warping" by George Wolberg. The
original algorithm was developed at Kodak, but is in the public domain and
was published in the Procedings of the SPIE Digital Image Processing
Applications, vol. 1075, pp. 260-269, 1989. The article was entitled
"Resampling Algorithms for Image Resizing and Rotation". The Wolberg book
contains a 'C' code version.

At 12:40 PM 2/12/99 -0800, you wrote:
>I wish to add an interpolation algorythm to the resizing method of PIL...
I'm just wondering where the current nearest-neighbour and antialias
methods are implemented so that I can add INTERPOLATE to them.
>
>Any hints/suggestions, or anyone currently have a working interpolation
resizing method?
>
>
>Thanks,
>
>Kevin Cazabon
>kcaza@cymbolic.com
>kcazabon@rogers.wave.ca
>









                                  
>
>_______________________________________________
>Image-SIG maillist  -  Image-SIG@python.org
>http://www.python.org/mailman/listinfo/image-sig
>
>
>
--
Richard Lourette
lourette@localnet.com


From image_sig@opti.okdirect.com  Sat Feb 13 21:48:09 1999
From: image_sig@opti.okdirect.com (Daniel Walton)
Date: Sat, 13 Feb 1999 15:48:09 -0600
Subject: [Image-SIG] PIL 1.0b1 and GifImagePlugin.py
Message-ID: <4.1.19990213154036.00bac180@grunt.okdirect.com>

I'm having a problem with the GifImagePlugin module and figured someone one
this list would be able to patch it easily.  I looked over the source
briefly but don't have the time to go in depth to figure out a patch,
sorry.  Here's the traceback.  Looks like it might have something to do
with Gif global vs. local palettes but I could be wrong. A GIF image is
temporarily available at the following URL that exhibits the problem:

http://members.aol.com/HP2000c/pbe/banner1.gif 


Traceback (innermost last):
  File "/usr/home/cginet/www/services/orbitcycle/index.cgi", line 3, in ?
    import switch
  File "/usr/home/cginet/www/services/orbitcycle/switch.py", line 110, in ?
    func(form)
  File "/usr/home/cginet/www/services/orbitcycle/bannersets.py", line 2254,
in add_random_banner_submit_1
    (res, err) = get_banner_res(account, image_url)
  File "/usr/home/cginet/www/services/orbitcycle/bannersets.py", line 4058,
in get_banner_res
    im = Image.open(image_data)
  File "/usr/local/lib/python1.5/site-packages/PIL/Image.py", line 894, in open
    return factory(fp, filename)
  File "/usr/local/lib/python1.5/site-packages/PIL/ImageFile.py", line 64,
in __init__
    self._open()
  File "/usr/local/lib/python1.5/site-packages/PIL/GifImagePlugin.py", line
86, in _open
    self.seek(0) # get ready to read first frame
  File "/usr/local/lib/python1.5/site-packages/PIL/GifImagePlugin.py", line
109, in seek
    self.palette = self.global_palette
AttributeError: global_palette


If anyone comes up with a patch I would greatly appreciate a copy.

Daniel Walton




From Jack.Jansen@cwi.nl  Sun Feb 14 20:53:50 1999
From: Jack.Jansen@cwi.nl (Jack Jansen)
Date: Sun, 14 Feb 1999 21:53:50 +0100
Subject: [Image-SIG] Where to implement other resizing methods...
In-Reply-To: Message by Lourette <lourette@localnet.com> ,
 Fri, 12 Feb 1999 23:37:11 -0500 , <3.0.1.32.19990212233711.006bbda4@mail.localnet.com>
Message-ID: <UTC199902142053.VAA04060.jack@trawler.cwi.nl>

In img I use the resampling routine from the PBM package, which
produces very nice results for both upsampling and downsampling. It is 
however extremely slow (i.e. noticable on current hardware:-). The pbm 
package (in its "netpbm" incarnation) is available all over the net.
--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@cwi.nl      | ++++ if you agree copy these lines to your sig ++++
http://www.cwi.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm 


From fredrik@pythonware.com  Mon Feb 15 07:36:20 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Mon, 15 Feb 1999 08:36:20 +0100
Subject: [Image-SIG] Where to implement other resizing methods...
Message-ID: <006801be58b5$e590f5c0$f29b12c2@pythonware.com>

>I wish to add an interpolation algorythm to the resizing method
>of PIL... I'm just wondering where the current nearest-neighbour
>and antialias methods are implemented so that I can add INTER-
>POLATE to them.

the current resampling machinery is quite convoluted, so
if you cannot even find it on your own, you should probably
not try to modify it ;-)

here's how I would do it:

1. implement your interpolation method in a separate module,
operating on Imaging structure.

2. add a unique resampling filter code to Image.py

3. patch the resize/rotate/transform dispatchers in _imaging.c
so they call your version when that filter is used.

>Any hints/suggestions, or anyone currently have a working inter-
>polation resizing method?

how do you define "interpolation", btw?

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



From steve@websentric.com  Mon Feb 15 14:27:44 1999
From: steve@websentric.com (Stephen Purcell)
Date: Mon, 15 Feb 1999 15:27:44 +0100
Subject: [Image-SIG] Saving GIFs with added transparency
Message-ID: <36C82EE0.E2A791E6@websentric.com>

This is a cryptographically signed message in MIME format.

--------------msB0268718DE034B12D1617CE7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've been trying to do the following with the latest PIL beta release:

	1. Load a non-transparent GIF image
	2. Mark one of its colours as transparent
	3. Save as a new GIF

I tried doing this by setting the 'transparency' entry of the image's
'info' dictionary.  On saving, this information was ignored.  Maybe this
was the wrong way to do it, but if it's not, I have a patch to offer for
'GifImagePlugin.py'.

It involves the addition of the following lines before the 'return' of
the 'getheader' function:

    if im.info.has_key('transparency'):
        transparentIndex = im.info['transparency']
        s.append('!' + chr(0xf9) + chr(4) + chr(1) + chr(0) + chr(0) +
                 chr(transparentIndex) + chr(0))

Perhaps this is useful to someone else out there.

Regards,


-Steve P.

BTW, I based my patch/hack on:

	http://www.acme.com/resources/classes/Acme/JPM/Encoders/GifEncoder.java
--
Steve Purcell
Software Design Engineer
WebSentric Software AG
--------------msB0268718DE034B12D1617CE7
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIIHwYJKoZIhvcNAQcCoIIIEDCCCAwCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Bf4wggKuMIICF6ADAgECAgIsGDANBgkqhkiG9w0BAQQFADCByDELMAkGA1UEBhMCWkExFTAT
BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo
YXd0ZSBDb25zdWx0aW5nMTMwMQYDVQQLEypDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyBSU0EgSUsg
MTk5OC4yLjI1IDg6MzUxOzA5BgNVBAMTMlRoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBSU0Eg
SXNzdWluZyBLZXkgMTk5OC4yLjI1MB4XDTk4MDcwNzA3MzYwNFoXDTk5MDcwNzA3MzYwNFow
WzE0MDIGA1UEAxYrVGhhd3RlIEZyZWVtYWlsIE1lbWJlciBzdGV2ZUB3ZWJzZW50cmljLmNv
bTEjMCEGCSqGSIb3DQEJARYUc3RldmVAd2Vic2VudHJpYy5jb20wXDANBgkqhkiG9w0BAQEF
AANLADBIAkEAqGXOfNu76sfiriGkF/+S6YaeReHudcqYme9jsRlPjlixaRUCOwOYOkSCe2UU
VO/y4U1/i+b4ArkNmJ0YJJ93fQIDAQABo1cwVTAUBglghkgBhvhCAQEBAf8EBAMCBaAwDgYD
VR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFqAU7TQXbg4rXkuHmJG4N6eY
v5IfrHIwDQYJKoZIhvcNAQEEBQADgYEAJ0nMj/83Pw2S1fm3k4/7j1+LvJqLTf2wdmwGJRP+
9AiCeYGEoJSuOP6NMcbMFQLgIWPx7eQzcE0X7a12IzCvTKfc7drUVYxovL8sIRjO8wYSUpbU
kFSHcsaP5LDjhaK4TixXtV7uT3XmL6d49Te4B+wyNNtmpD1EYMwEbyyQPtIwggNIMIICsaAD
AgECAgEIMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5n
MSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtU
aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZy
ZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTgwMjI1MDgzNTMzWhcNMDAwMjI1MDgzNTMzWjCByDEL
MAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmls
bGUxGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMTMwMQYDVQQLEypDZXJ0aWZpY2F0ZSBT
ZXJ2aWNlcyBSU0EgSUsgMTk5OC4yLjI1IDg6MzUxOzA5BgNVBAMTMlRoYXd0ZSBQZXJzb25h
bCBGcmVlbWFpbCBSU0EgSXNzdWluZyBLZXkgMTk5OC4yLjI1MIGfMA0GCSqGSIb3DQEBAQUA
A4GNADCBiQKBgQDHMcPEG5kjctJRhZVM41mS5OhsgbX0G18J5sSts0RvqjjXV+Swxcu6dK5M
YSMkdgb42V0NiiiytCvtDbtSJPS3xUmng2P8CgSw74Eo9+aRxk2X7pJ2JmLIYzd2PLGSD9yt
UgaKccU3MWqG270IaShZ/O3HfSZn3U3e08UC/ne24QIDAQABozcwNTASBgNVHRMBAf8ECDAG
AQH/AgEAMB8GA1UdIwQYMBagFHJJwnM0xlX0C3ZygX539IfnxrIOMA0GCSqGSIb3DQEBBAUA
A4GBAELq7YthfqHUXFKpPL2enHnoCYsSga2PHVpG7fElJlvIrv16IRbNoB47lzOD+043KiiX
pkj1KBgCJHyAe1NQtftvmvxtqlwmRagvNiJY0xsCAx/ulDnw/jRaiEsbPYzz137Tn3BbdvbY
xOK2PCSdCSWMWbHUi/P8BIIOnimGbMX/MYIB6TCCAeUCAQEwgc8wgcgxCzAJBgNVBAYTAlpB
MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQK
ExFUaGF3dGUgQ29uc3VsdGluZzEzMDEGA1UECxMqQ2VydGlmaWNhdGUgU2VydmljZXMgUlNB
IElLIDE5OTguMi4yNSA4OjM1MTswOQYDVQQDEzJUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg
UlNBIElzc3VpbmcgS2V5IDE5OTguMi4yNQICLBgwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw05OTAyMTUxNDI3NDRaMCMGCSqGSIb3
DQEJBDEWBBSY5wKT30EW6Mrn3SzzlvWZ0TkqRzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3
DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0D
AgIBKDANBgkqhkiG9w0BAQEFAARAYSOYqxKToTqiNkNLzzp5Ames5NmnjA6o+GsICl0Vv3IW
6jAk9ODa0/3nmEXidb3H+fi9X0eXucWzAD6dLlNpbg==
--------------msB0268718DE034B12D1617CE7--



From Oliphant.Travis@mayo.edu  Mon Feb 15 15:49:54 1999
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Mon, 15 Feb 1999 09:49:54 -0600 (EST)
Subject: [Image-SIG] Undeliverable mail (fwd)
Message-ID: <Pine.LNX.4.04.9902150949080.4429-110000@us2.mayo.edu>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

--=_mh.ndn.4434.0002.36c7ba30_=
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.04.9902150949082.4429@us2.mayo.edu>

	

--=_mh.ndn.4434.0002.36c7ba30_=
Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.04.9902150949084.4429@us2.mayo.edu>
Content-Description: 

Return-Path: <olipt@mayo.edu>
Received: from daytona.mayo.edu by mhro1.mayo.edu with ESMTP; Mon, 15 Feb 1999 00:09:50 -0600
Received: from us2.mayo.edu (us2 [129.176.201.54]) by daytona.mayo.edu (980427.SGI.8.8.8/950213.SGI.AUTOCF) via ESMTP id AAA33824; Mon, 15 Feb 1999 00:09:50 -0600 (CST)
Date: Mon, 15 Feb 1999 00:07:39 -0600 (EST)
From: Travis Oliphant <Oliphant.Travis@mayo.edu>
To: images-sig@python.org
cc: matrix-sig@python.org
Subject: PIL and NumPy Relationship
Message-Id: <Pine.LNX.4.04.9902150000050.3878-100000@us2.mayo.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

PIL and/or NumPy users:

Thanks to F Lundh and all else who have contributed to the PIL.  It is
a very nice piece of work and a very useful tool for those of us who
use python to look at and display images.  

Since I have only been a python regular for under a year I wasn't
around when the PIL was just getting off the ground and I have a
couple of questions about the relationship between the PIL and
Numerical Python.

I come from a background of using other data analysis environments
like MATLAB and IDL which treat images as an array of numbers.  As a
result I'm a little surprised to see two different objects being
developed in Python that both serve as images.  The Image object in
PIL and the multiarray object in NumPy.  I wondered if someone could
enlighten me as to any advantage of having two separate objects for
the same kind of data.

Personally, I think this creates an unnecessary dichotomy and division
of scarce resources.  I know, for example, that people have written
and will write "image processing" routines that will work on the Image
object and that I would like to apply those same routines to my Array
object but will first have to get the data into an Image object and
then back into an Array object for further processing.  While not
difficult this is not really acceptable if one is trying to use Python
as an interactive analysis environment.

In many cases one deals with an image which is simply a slice through
or projection of a larger array data set.  With a separate Image
object, all of the methods people have and may develop for image
processing (including loading and saving of image types) are
unavailable unless the translation is made first.

What is the possibility of unifying the PIL and NumPy a bit more?  I
know you can translate between the two objects with fromstring and
tostring methods but this is wasteful in both mental effort (in
keeping track of the different objects and .  It would be better, I
think if the PIL were built around the multiarray object already.  I
guess I'm not sure what kind of work this would involve.  Another
possibility is to have the underlying image data be both an Image
object and Multiarray object at the same time (same data area
different headers? in the C-struct)

So, I'm basically asking users of the PIL to tell me if and why they
feel it is necessary to have two different objects to represent images.

I don't mean to sound critical at all.  I'm just offering my
thoughts.  I basically wouldn't care at all except I find the PIL to
be such a useful addition to Python and am also a heavy user of
Numerical Python.  Thanks again to all involved in
its development.

Thanks,

Travis Oliphant



----------------------------------------------------
Travis Oliphant            200 First St SW          
    	                   Rochester MN 55905       
Ultrasound Research Lab	   (507) 286-5293           
Mayo Graduate School	   Oliphant.Travis@mayo.edu 


--=_mh.ndn.4434.0002.36c7ba30_=--


From KCAZA@cymbolic.com  Tue Feb 16 20:08:46 1999
From: KCAZA@cymbolic.com (Kevin Cazabon)
Date: Tue, 16 Feb 1999 12:08:46 -0800
Subject: [Image-SIG] PIL module, auto-levels adjust
Message-ID: <s6c95fdd.013@cymbolic.com>

This is a MIME message. If you are reading this text, you may want to 
consider changing to a mail reader or gateway that understands how to 
properly handle MIME multipart messages.

--=_0A5DF84D.137211E7
Content-Type: text/plain
Content-Disposition: inline

I've written a handy little module for automatically fine-tuning image files.  It will work with RGB and CMYK files, and does the following:

-checks the histogram, determines the actual brightness range used in the image for each channel

-scales the data to fill the full 0-255 range either by scaling each channel individually, or by scaling them equally (to the lowest common denomonator)


Being a certified Adobe Photoshop 4.0 instructor (by Adobe), I find the BEST way to color/density correct an image is to first set the black/white point for each of the channels individually, so that you use the entire available dynamic range.  This is basically what the module does.

The usage is as follows:

###################################

import Image
import levels

file = Image.open('filename')

file = levels.levels(file, scale_same, clip)

###################################

scale_same:  0 = scale each channel individually, 1 = scale all channels the same

clip = (integer) = if there's less than this number of pixels at the minimum/maximum brightness level found, don't use them to calculate the levels adjustment (i.e. they get clipped off the image to pure black/white)  default is 0.  This is useful if you have a few 'dark' or 'bright' pixels that actually are not relevant detail and are causing the scaling to not properly fill up the histogram.

###################################

It's not the most glamourous code, but it works very well.  It's great for batch-processing scanned images to 'tweak' the dynamic range, and do a pretty decent job at color correction too.  (most of the time, optimizing the RGB/CMYK channels to each fill the entire dynamic range does a good color correction too).

If you find it useful... please let me know!

Kevin Cazabon, B.A.A.
kcazabon@rogers.wave.ca
kcaza@cymbolic.com
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               !
                                
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      

--=_0A5DF84D.137211E7
Content-Type: application/zip
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="levels.py.zip"
Content-Description: PKZIP (compressed) files

UEsDBBQAAAAIAMtgUCZsEXXuzQIAAA0KAAAJACQAbGV2ZWxzLnB5CgAgAAAAAAABABgAALOv0udZ
vgEAQMpZglm+AcCK9dHnWb4BrVVdb9o8FL5H4j8cqRckW5oCGl2L1qpaL6ZX1XaxuymKkBNM6sWJ
kRPY3v36+SMfthNYqw0JCPZznnOecx6bC0Db74eqBoqPmFZQM9gRSuGZVDXLOCqmkwt4wkdSwiP6
hRJWBrC4vb0NAfJULzxwlmFehT/QEYcpajYe0v+LhFGShikTJNMJqNd0ssW7Jpm3RTUKAFG6qVCB
4Q7mAaSU7OWTv26DyA4kMCzYFkPJahC1RLOvnz7OApg9fv72NIvXLT0Ax/WBlyqiX2xzy096qAV/
gXIsnpwSdHq/CdRfEiECVAl7RsraE3F+r2c0qZa5I+V280w2lMmYhryptRAq7uALK3HzG/20fttF
7xgHIoVzVGbYo7hUVfiGcNEmsRSRGO5VorXNo/MRezHhGOVum5xmhVwMi1fY6zT/u5qU5uVqBZev
rqxpuZAVSB63abL9VYoo9tJnVJaYVkGHbSvUTojiMTnQxZl6HMnL1bXvSDoiepBOlj7xiNAlkvpv
BHIVzq92lKHaExVcylXft0NFs3T0B5g7rCbz/ETUvWzkmTixa2/K2aL9HpdbT2GcckbbLWJag7dd
PnuSmnpIsWe8hv8KlI3au7tt2oPWLRiug7Gp8QCyAJIAcrUYGO+xRO1QBVj6tUvjX4lZTien3e2M
mred6xgiEhulZsN9wfDWwiRDzGqx7DFisn25d/DuVT7Mh+Tvr2/sAqzOmLNWB4Xr02ncYdy6HjOF
ygaozEIlCpUMUImFOiM1VwT5gCBvQkUIPgVfLG8C+THmBJGy/+MR0HXv6+7C3GiaiDdStRSdoG2R
boGWqBPHA46wYrw2naw9PHI/SXQ0j/vny0Xsq7IGag0zbky+RWAM0LSki+oHaJrSRfUD9K17/dS8
1BBckn4qg+M8PNKnbA5jPjcuMdUG+xi+jiD7W4JkSPCHTr2A38mRD3NIcwxjXnCJu6/fUEsBAhkA
FAAAAAgAy2BQJmwRde7NAgAADQoAAAkAAAAAAAAAAAAgAAAAAAAAAGxldmVscy5weVBLBQYAAAAA
AQABADcAAAAYAwAAAAA=

--=_0A5DF84D.137211E7--


From fredrik@pythonware.com  Wed Feb 17 08:19:07 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 17 Feb 1999 09:19:07 +0100
Subject: [Image-SIG] Undeliverable mail (fwd)
Message-ID: <012f01be5a4e$324193e0$f29b12c2@pythonware.com>

Travis Oliphant wrote:
> It would be better, I think if the PIL were built around the
> multiarray object already.  I guess I'm not sure what kind of
> work this would involve.

Agreed.  There's three big reasons why it isn't so right now:
1) NumPy didn't exist when the first PIL versions were written,
2) it's quite important that PIL can be used on its own, and 3)
a lot of PIL-related code depends on the current Imaging
structure layout.

Moving the multiarray stuff into the Python code would help
a lot...

> Another possibility is to have the underlying image data be
> both an Image object and Multiarray object at the same time
> (same data area different headers? in the C-struct)

PIL 1.1 will most likely support "access adaptors" which would
make it possible to treat NumPy arrays (and various other things)
as image memories.  (It's too early to ask "when"...)

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



From fredrik@pythonware.com  Wed Feb 17 08:22:21 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Wed, 17 Feb 1999 09:22:21 +0100
Subject: [Image-SIG] Saving GIFs with added transparency
Message-ID: <015001be5a4e$a4be0ca0$f29b12c2@pythonware.com>

by some odd reason (probably related to the certificate),
my mail program completely refuses to deal with this mail
(I see the subject, but that's all).

if noone else gets around to answer this, maybe someone
could send me a readable copy?

(yes, I will upgrade, but not today).

Thanks /F




From godzilla@netmeg.net (Les Schaffer)  Wed Feb 17 15:18:16 1999
From: godzilla@netmeg.net (Les Schaffer) (Les Schaffer)
Date: Wed, 17 Feb 1999 10:18:16 -0500 (EST)
Subject: [Image-SIG] Undeliverable mail (fwd)
In-Reply-To: <012f01be5a4e$324193e0$f29b12c2@pythonware.com>
References: <012f01be5a4e$324193e0$f29b12c2@pythonware.com>
Message-ID: <14026.56760.379880.704829@localhost>

Fred sed:

> Moving the multiarray stuff into the Python code would help a lot...

you can say that again.

hows bout "the tip" from the best pythoneer tipster around (and PIL
author): whats the best way (in the mean time) to jam an (NumPy) array
of pixel data into an image, and whats the best way to grab an (NumPy)
array of pixel data out of an image?

somewhere or other i got a copy of a file with this in it
(below). look good to you?

also, documentations on getdata() would be greatly appreciated; for
example:

getdata(). Returns the contents of a the image as a sequence object
containing pixel values. The sequence object is flattened, so that
values for line one follows directly after the values for line zero,
and so on.

---------
import Image
im = Image.open("c0368974139r.gif")
#im.show()

dat = im.getdata()

print dat
# <ImagingCore object at 8141798>

print dir(dat)

# ['chop_add', 'chop_add_modulo', 'chop_and', 'chop_darker',
# 'chop_difference', 'chop_invert', 'chop_lighter', 'chop_multiply',
# 'chop_or', 'chop_screen', 'chop_subtract', 'chop_subtract_modulo',
# 'chop_xor', 'convert', 'convert2', 'convert_matrix', 'copy',
# 'copy2', 'crop', 'draw_arc', 'draw_chord', 'draw_ellipse', 
....

------------

errrr wheres the DATA??????????


les schaffer





==================== found this somewhere on the net ===============

#!/usr/bin/python -O

import Image
def normalize(a):
    a = array(a, copy=1)
    a =1.0-(a - min(a.flat))/(max(a.flat) - min(a.flat)) 
    return a

def ArrayToImage(a, height=200, scale=1):
    if len(a.shape) == 2:
	a = (normalize(a)*254).astype('b')
	i = Image.new("L", (a.shape[1], a.shape[0]), color=255)
	i.fromstring(a.tostring())
    elif len(a.shape) == 1:
	a = 1-normalize(a)
	a = array(a*height).astype('i')
	i = Image.new("L", (a.shape[0], height), color=255)
	id = ImageDraw.ImageDraw(i)
	id.setink(0)
	def map_xandy_to_xy(x, y):
	    import _imaging
	    return _imaging.path(ravel(transpose(array((x, y)))).tolist())
	id.line(xy=map_xandy_to_xy(arange(a.shape[0]), a))
    if scale != 1:
	i = i.resize((i.size[0]*scale, i.size[1]*scale))
    return i

def ImageToArray(i):
    a = fromstring(i.tostring(), 'b')
    a.shape = i.im.size[1], i.im.size[0]
    return a


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


From jhauser@ifm.uni-kiel.de  Wed Feb 17 17:32:22 1999
From: jhauser@ifm.uni-kiel.de (jhauser@ifm.uni-kiel.de)
Date: Wed, 17 Feb 1999 18:32:22 +0100 (CET)
Subject: [Image-SIG] Undeliverable mail (fwd)
In-Reply-To: <14026.56760.379880.704829@localhost>
References: <012f01be5a4e$324193e0$f29b12c2@pythonware.com> <14026.56760.379880.704829@localhost>
Message-ID: <14026.64668.164457.912081@lisboa.ifm.uni-kiel.de>

Here is an old message from the list, which mentions putdata and
getdata.


>1:  Shouldn't PIL support conversion directly to/from arrays?  Using
>the intermediate string works, but seems like a hack...

Recent versions provide getdata and putdata methods (getdata is
even documented):

    data = im1.getdata()
    im2 = Image.new(im1.mode, im2.size)
    im3.putdata(data)

The sequence object returned by getdata is a bit fragile, at
least under 1.4.  If you get problems, explicitly convert it to
a list or tuple:

    data = list(im1.getdata())

>2:  Seems that if I start with an Array, make an Image, then convert
>back, the y-axis is inverted.  Is this a feature or a bug?

To be compatible with old versions of PIL, the fromstring/tostring
methods by default assumes that the data has the bottom-most line
first, and RGB data has an extra pad byte after each pixel.  To get
other behaviour, you need to specify codec arguments.

However, the recent fromstring *function* doesn't provide the same
default behaviour -- instead, it defaults to more reasonable top-most
line first, RGB data without padding settings.  The problem is that if
you pass the result from tostring directly to the fromstring *function*,
the image is turned upside down.  Again, you can modify this behaviour
using codec arguments.  See:

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

..

We're about to release a new version of PIL; I'm tempted to change
the method's default settings so that it matches the fromstring function.
If this would break a huge amount of code for anyone on this list, please
speak up!

Cheers /F





From hannu@trust.ee  Thu Feb 18 15:03:16 1999
From: hannu@trust.ee (Hannu Krosing)
Date: Thu, 18 Feb 1999 17:03:16 +0200
Subject: [Image-SIG] Saving GIFs with added transparency
References: <015001be5a4e$a4be0ca0$f29b12c2@pythonware.com>
Message-ID: <36CC2BB4.C28C51BE@trust.ee>

Fredrik Lundh wrote:
> 
> by some odd reason (probably related to the certificate),
> my mail program completely refuses to deal with this mail
> (I see the subject, but that's all).

It is a signed mail, maybe that confuses your mail program

> if noone else gets around to answer this, maybe someone
> could send me a readable copy?

This is it (obtained by copy/paste)

--8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<---
I've been trying to do the following with the latest PIL beta release:

        1. Load a non-transparent GIF image
        2. Mark one of its colours as transparent
        3. Save as a new GIF

I tried doing this by setting the 'transparency' entry of the image's
'info' dictionary.  On saving, this information was ignored.  Maybe this
was the wrong way to do it, but if it's not, I have a patch to offer for
'GifImagePlugin.py'.

It involves the addition of the following lines before the 'return' of
the 'getheader' function:

    if im.info.has_key('transparency'):
        transparentIndex = im.info['transparency']
        s.append('!' + chr(0xf9) + chr(4) + chr(1) + chr(0) + chr(0) +
                 chr(transparentIndex) + chr(0))

Perhaps this is useful to someone else out there.

Regards,


-Steve P.

BTW, I based my patch/hack on:

       
http://www.acme.com/resources/classes/Acme/JPM/Encoders/GifEncoder.java
--
Steve Purcell
Software Design Engineer
WebSentric Software AG
--8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<-----8<---
Hannu


From joe@strout.net  Thu Feb 18 18:33:49 1999
From: joe@strout.net (Joseph J. Strout)
Date: Thu, 18 Feb 1999 10:33:49 -0800
Subject: [Image-SIG] PIL on Mac doesn't work?
Message-ID: <v04020a0eb2f20cf88c39@[198.202.70.212]>

I'm trying to get a grip on the Image module of PIL under MacOS.  I was
able to open an image just fine using:

im = Image.open(pathname)

but whenever I try to do anything with this image -- even just get a pixel
value -- I get a traceback:

>>> im.getpixel( (0,0) )
Traceback (innermost last):
  File "<input>", line 1, in ?
  File "Birdsong:Users:Strout:tools:Python
1.5.2b1:Extensions:Imaging:PIL:Image.py", line 503, in getpixel
    self.load()
  File "Birdsong:Users:Strout:tools:Python
1.5.2b1:Extensions:Imaging:PIL:ImageFile.py", line 122, in load
    self.im = Image.core.new(self.mode, self.size)
  File "Birdsong:Users:Strout:tools:Python
1.5.2b1:Extensions:Imaging:PIL:Image.py", line 36, in __getattr__
    raise ImportError, "The _imaging C module is not installed"
ImportError: The _imaging C module is not installed


No mention of "_imaging" is made in the PIL 0.2b3 manual.  Can anyone
provide any insight here?  What must I do to get at the pixels loaded by
Image?

Thanks,
-- Joe
,------------------------------------------------------------------.
|    Joseph J. Strout           Biocomputing -- The Salk Institute |
|    joe@strout.net             http://www.strout.net              |
`------------------------------------------------------------------'


From KCAZA@cymbolic.com  Thu Feb 18 19:21:20 1999
From: KCAZA@cymbolic.com (Kevin Cazabon)
Date: Thu, 18 Feb 1999 11:21:20 -0800
Subject: [Image-SIG] ICC profiles...
Message-ID: <s6cbf7b6.016@cymbolic.com>

Just curious if there's any modules out there for PIL that will process an image through ICC profiles.

I couldn't find one, and have started writing one (so far, it reads the profiles, and extracts all the data, but doesn't do anything with the data just yet).  Just wondering if I'm re-inventing the wheel...

If not... any suggestions for feature sets for ICC processing options?  (I've got my own plan, but I'm always open to suggestion)

Kevin Cazabon
kcaza@cymbolic.com
kcazabon@rogers.wave.ca
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                               


From da@ski.org  Thu Feb 18 22:54:17 1999
From: da@ski.org (David Ascher)
Date: Thu, 18 Feb 1999 14:54:17 -0800 (Pacific Standard Time)
Subject: [Image-SIG] fastest jpeg conversion possible
Message-ID: <Pine.WNT.4.04.9902181451140.271-100000@rigoletto.ski.org>

I'm finding that 

  data = Image.open('bigfile.jpeg').tostring()

is a little slow, on large images.  Now, part of that is because it's a
big job.  I'm wondering if taking PIL out of the loop and writing a module
which just did the jpeg decode based on libjpeg would significantly reduce
the time (and/or temporary memory usage -- which impacts time on
memory-starved machines) of that operation.  I haven't looked enough at
the internals to know whether PIL is doing this efficiently or not.

Anyone have any ideas?

--david



From savageb@pacbell.net  Fri Feb 19 08:16:31 1999
From: savageb@pacbell.net (savageb)
Date: Fri, 19 Feb 1999 00:16:31 -0800
Subject: [Image-SIG] ICC profiles...
Message-ID: <199902190815.AAA11992@mail-gw2.pacbell.net>

> Just curious if there's any modules out there for PIL that will process an
> image through ICC profiles.
>
> I couldn't find one, and have started writing one (so far, it reads the
> profiles, and extracts all the data, but doesn't do anything with the data
> just yet).  Just wondering if I'm re-inventing the wheel...


Kevin,

Good idea!

To the best of my knowledge, the only thing out there now is that you can
generate a wrapper for the 'aete' resource of the ColorSync extension
(actually a faceless background application) on the Mac, to have it embed,
match and proof an image with an ICC profile. To do this look for the
'getaete.py' file in the contrib folder.

Bob

P.S. the Windows port of ColorSync is expected around June.


From phil@geog.ubc.ca  Fri Feb 19 17:18:29 1999
From: phil@geog.ubc.ca (Phil Austin)
Date: Fri, 19 Feb 1999 09:18:29 -0800
Subject: [Image-SIG] new open source remote sensing organization
Message-ID: <199902191718.JAA07404@brant.geog.ubc.ca>

Wired is running a story today about a new effort
to organize development of open source remote 
sensing software.  Their site is:

http://www.remotesensing.org

Phil

Phil Austin		INTERNET: phil@geog.ubc.ca
(604) 822-2175		FAX:	  (604) 822-6150

http://www.geog.ubc.ca/~phil
Atmospheric Sciences Programme
Geography #217
University of British Columbia
1984 W Mall
Vancouver, BC  V6T 1Z2
CANADA


From fredrik@pythonware.com  Sun Feb 21 19:38:40 1999
From: fredrik@pythonware.com (Fredrik Lundh)
Date: Sun, 21 Feb 1999 20:38:40 +0100
Subject: [Image-SIG] Undeliverable mail (fwd)
Message-ID: <041701be5dd1$fde9f970$f29b12c2@pythonware.com>

Les Schaffer wrote:
>also, documentations on getdata() would be greatly appreciated; for
>example:
>
>getdata(). Returns the contents of a the image as a sequence object
>containing pixel values. The sequence object is flattened, so that
>values for line one follows directly after the values for line zero,
>and so on.
>
/.../
>
>errrr wheres the DATA??????????

it's a sequence object, just as the doc says.
 "x[i]" and "len(x)" and "for pixel in x" and
"list(x)" etc works as they should.

but alright, a nice repr method would
be nice.  when I find the time...

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



From seant@iname.com  Tue Feb 23 03:48:54 1999
From: seant@iname.com (Sean True)
Date: Mon, 22 Feb 1999 22:48:54 -0500
Subject: [Image-SIG] Kodak PhotoCD
Message-ID: <3.0.5.32.19990222224854.00859ea0@pop.ne.mediaone.net>

The loading code seems fragile. Does it deal with portrait orientation?
I've had some trouble getting it to work at all. Anybody else?

-- Sean

==========
Sean True
seant@iname.com
http://striper.ne.mediaone.net


From Oliphant.Travis@mayo.edu  Thu Feb 25 23:15:40 1999
From: Oliphant.Travis@mayo.edu (Travis Oliphant)
Date: Thu, 25 Feb 1999 17:15:40 -0600 (EST)
Subject: [Image-SIG] Wiener filter using sigtools and Python
Message-ID: <Pine.LNX.4.04.9902251708590.11755-100000@us2.mayo.edu>

While this routine will go into the next addition of sigtools, I thought I
would show interested people, how easy it is to do image (volume) 
processing with Python.

Below find a function to do wiener filtering on an array of data.

from sigtools import *
from MLab import *

def wiener(im,mysize=None,noise=None):

    if mysize==None:
        mysize = 3*ones(len(a.shape))
    mysize = array(mysize);

    # Estimate the local mean
    lMean = convolveND(im,ones(mysize),1) / prod(mysize)

    # Estimate the local variance
    lVar = convolveND(im**2,ones(mysize),1) / prod(mysize) - lMean**2

    # Estimate the noise power if needed.
    if noise==None:
        noise = mean(ravel(lVar))

    # Compute result
    # out = lMean + (maximum(0, lVar - noise) ./
    #               maximum(lVar, noise)) * (im - lMean) 
    #
    out = im - lMean
    im = lVar - noise
    im = maximum(im,0)
    lVar = maximum(lVar,noise)
    out = out / lVar
    out = out * im
    out = out + lMean

    return out




Enjoy,

--Travis




From barry@scottb.demon.co.uk  Sun Feb 28 14:16:51 1999
From: barry@scottb.demon.co.uk (Barry Scott)
Date: Sun, 28 Feb 1999 14:16:51 -0000
Subject: [Image-SIG] When will the next PIL beta be released?
Message-ID: <000001be6324$fc69b0b0$060110ac@barrynt.private>

	The subject says it all.

		BArry