From amartin8 at illinois.edu  Fri May  1 03:51:13 2009
From: amartin8 at illinois.edu (amartin8 at illinois.edu)
Date: Thu, 30 Apr 2009 20:51:13 -0500 (CDT)
Subject: [Image-SIG] import tk module error
Message-ID: <20090430205113.BTV99099@expms2.cites.uiuc.edu>

hello,
i am working on a project for school using tkinter and the python imaging library. i would like to create a PhotoImage and display it in my GUI. i am able to use all of the functions from the Image module, but whenever i try to use the ImageTk module, i receive import errors. specifically
ImportError: No module named _imagingtk
i am using a school computer and thus do not have root access, however the other modules i have tried to use are working. is there anything i can do to get this module to work?
thanks
austin

From fredrik at pythonware.com  Mon May  4 11:58:13 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 4 May 2009 11:58:13 +0200
Subject: [Image-SIG] import tk module error
In-Reply-To: <20090430205113.BTV99099@expms2.cites.uiuc.edu>
References: <20090430205113.BTV99099@expms2.cites.uiuc.edu>
Message-ID: <368a5cd50905040258h7e2a46b3x229b0c3a4e11c070@mail.gmail.com>

_imagingtk is a binary extension.  On Linux systems, it's usually
available as a separate package called "python-imaging-tk".

Check with your system administrators if they can install it for you
(or if you feel adventurous, install a local copy of python-imaging
and python-imaging-tk in your home directory).

</F>

On Fri, May 1, 2009 at 3:51 AM,  <amartin8 at illinois.edu> wrote:
> hello,
> i am working on a project for school using tkinter and the python imaging library. i would like to create a PhotoImage and display it in my GUI. i am able to use all of the functions from the Image module, but whenever i try to use the ImageTk module, i receive import errors. specifically
> ImportError: No module named _imagingtk
> i am using a school computer and thus do not have root access, however the other modules i have tried to use are working. is there anything i can do to get this module to work?
> thanks
> austin
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>

From agagne at genome.med.harvard.edu  Mon May  4 16:08:15 2009
From: agagne at genome.med.harvard.edu (Andrew)
Date: Mon, 04 May 2009 10:08:15 -0400
Subject: [Image-SIG] PIL - Tiff problems
Message-ID: <49FEF6CF.2030505@genome.med.harvard.edu>

I've been having a problem with my tiff. When converting to a PNG or a 
JPEG the colors get messed up (black becomes white). I belive it has 
todo with the tiff being little endian. I noticed that in 1.1.7 the 
following was added to the change log.

    Added limited support for I;16L mode (explicit little endian).
      

Would someone be able to assist me in utilizing this? I've installed 
1.1.7 but am unsure of how to utilize this feature.

If i print information about the image this is what i see:
code:

      im = Image.open("C:\\test\\test.tif")
      print im.format
      print im.mode
      print im.palette
      print im.info
      print im.getbands()

output:

    TIFF
    I;16
    None
    {'resolution': (1, 1), 'compression': 'raw'}
    I

I'm a novice at this, any help would be apprciated.
-andrew

changelog for pil 1.1.7:
http://bitbucket.org/effbot/pil-2009-raclette/src/tip/CHANGES

From bhupendra_solanki_3007 at yahoo.co.in  Mon May  4 17:12:11 2009
From: bhupendra_solanki_3007 at yahoo.co.in (bhupendra solanki)
Date: Mon, 4 May 2009 20:42:11 +0530 (IST)
Subject: [Image-SIG] want to convert an image text into editable text
Message-ID: <787493.35677.qm@web95206.mail.in2.yahoo.com>

Hi,
     If anyone knows how to convert an image file(.tif) into editable text file.
Please tell me the way to do it.

Or any related software for it?

Bhupendra Singh Solanki



      Now surf faster and smarter ! Check out the new Firefox 3 - Yahoo! Edition http://downloads.yahoo.com/in/firefox/?fr=om_email_firefox
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090504/998261c9/attachment.htm>

From fredrik at pythonware.com  Mon May  4 17:57:31 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 4 May 2009 17:57:31 +0200
Subject: [Image-SIG] PIL - Tiff problems
In-Reply-To: <49FEF6CF.2030505@genome.med.harvard.edu>
References: <49FEF6CF.2030505@genome.med.harvard.edu>
Message-ID: <368a5cd50905040857rb994dc4gf8267226896b5d04@mail.gmail.com>

On Mon, May 4, 2009 at 4:08 PM, Andrew <agagne at genome.med.harvard.edu> wrote:
> I've been having a problem with my tiff. When converting to a PNG or a JPEG
> the colors get messed up (black becomes white). I belive it has todo with
> the tiff being little endian. I noticed that in 1.1.7 the following was
> added to the change log.
>
> ? Added limited support for I;16L mode (explicit little endian).
>
> Would someone be able to assist me in utilizing this? I've installed 1.1.7
> but am unsure of how to utilize this feature.

Can you provide a sample in some way??  (you can mail it directly to
me if you don't want everyone to have access to the file; I never
redistribute sample files without permission).

</F>

From evan.kaufman at gmail.com  Mon May  4 18:01:27 2009
From: evan.kaufman at gmail.com (Evan Kaufman)
Date: Mon, 4 May 2009 11:01:27 -0500
Subject: [Image-SIG] want to convert an image text into editable text
In-Reply-To: <787493.35677.qm@web95206.mail.in2.yahoo.com>
References: <787493.35677.qm@web95206.mail.in2.yahoo.com>
Message-ID: <c18252740905040901l3d93e82qfdc7ca2bfeeddd0f@mail.gmail.com>

Sounds like you'd want some kind of OCR (optical character
recognition)...Maybe PyTesser, it uses the Tesseract OCR engine:
http://code.google.com/p/pytesser/

On Mon, May 4, 2009 at 10:12 AM, bhupendra solanki
<bhupendra_solanki_3007 at yahoo.co.in> wrote:
> Hi,
> ???? If anyone knows how to convert an image file(.tif) into editable text
> file.
> Please tell me the way to do it.
>
> Or any related software for it?
>
> Bhupendra Singh Solanki
>
> ________________________________
> Own a website.Get an unlimited package.Pay next to nothing.* Click here!.
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>
>

From agagne at genome.med.harvard.edu  Mon May  4 19:44:38 2009
From: agagne at genome.med.harvard.edu (Andrew)
Date: Mon, 04 May 2009 13:44:38 -0400
Subject: [Image-SIG] PIL - Tiff problems
In-Reply-To: <368a5cd50905040857rb994dc4gf8267226896b5d04@mail.gmail.com>
References: <49FEF6CF.2030505@genome.med.harvard.edu>
	<368a5cd50905040857rb994dc4gf8267226896b5d04@mail.gmail.com>
Message-ID: <49FF2986.3010309@genome.med.harvard.edu>

In reality the tif will be ~7 mb, but i was able to use pil to shrink 
the image size. The problem comes with converting to a png.

I open the tif then call

im = im.convert("L")
im = im.convert("P")
im.save("C:\\test\\test2.png","PNG")

To view the tif, I would generally use irfanview.

thanks,
andrew

Fredrik Lundh wrote:
> On Mon, May 4, 2009 at 4:08 PM, Andrew <agagne at genome.med.harvard.edu> wrote:
>   
>> I've been having a problem with my tiff. When converting to a PNG or a JPEG
>> the colors get messed up (black becomes white). I belive it has todo with
>> the tiff being little endian. I noticed that in 1.1.7 the following was
>> added to the change log.
>>
>>   Added limited support for I;16L mode (explicit little endian).
>>
>> Would someone be able to assist me in utilizing this? I've installed 1.1.7
>> but am unsure of how to utilize this feature.
>>     
>
> Can you provide a sample in some way??  (you can mail it directly to
> me if you don't want everyone to have access to the file; I never
> redistribute sample files without permission).
>
> </F>
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.png
Type: image/png
Size: 9362 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090504/121b05d1/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test1.tif
Type: image/tiff
Size: 18266 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090504/121b05d1/attachment-0001.tif>

From dave.lajoie at autodesk.com  Wed May  6 23:11:01 2009
From: dave.lajoie at autodesk.com (Dave Lajoie)
Date: Wed, 6 May 2009 14:11:01 -0700
Subject: [Image-SIG] Setting DPI field when saving a PNG file
Message-ID: <C6277525.B872%dave.lajoie@autodesk.com>

Hello Everyone!
I am attempting to save a PNG file, where the source file doesn't have dpi fields.
What is the proper way to enforce a new DPI with .save() function?

I have attempted to modify the .info dictionary by adding a dpi entry, but it never gets saved for some reason.
I am missing something really obvious here. :)

import Image
print "Loading Demo.png"
im = Image.open("C:\\Demo.png")
print "Demo.png Info:\n"
print im.info
print "________________________"
print "Changing Demo.png dpi to 72"
im.info["dpi"]=(72,72)
print "________________________"
print "Demo.png Info:\n"
print im.info
im.save("C:\\Demo_dpi.png")


Thanks for your help.
Dave.

From fredrik at pythonware.com  Thu May  7 03:17:47 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 7 May 2009 03:17:47 +0200
Subject: [Image-SIG] Setting DPI field when saving a PNG file
In-Reply-To: <C6277525.B872%dave.lajoie@autodesk.com>
References: <C6277525.B872%dave.lajoie@autodesk.com>
Message-ID: <368a5cd50905061817g3bec391byc116a3dc51d1a6ee@mail.gmail.com>

On Wed, May 6, 2009 at 11:11 PM, Dave Lajoie <dave.lajoie at autodesk.com> wrote:
> Hello Everyone!
> I am attempting to save a PNG file, where the source file doesn't have dpi fields.
> What is the proper way to enforce a new DPI with .save() function?
>
> I have attempted to modify the .info dictionary by adding a dpi entry, but it never gets saved for some reason.
> I am missing something really obvious here. :)

PIL doesn't preserve the contents of the info attribute when you do
image operations, since it's pretty much impossible to know how the
change affects the contents of the dictionary.  All you can use it for
is to access information provided by the file reader, directly after
open.

> import Image
> print "Loading Demo.png"
> im = Image.open("C:\\Demo.png")
> print "Demo.png Info:\n"
> print im.info
> print "________________________"
> print "Changing Demo.png dpi to 72"
> im.info["dpi"]=(72,72)
> print "________________________"
> print "Demo.png Info:\n"
> print im.info
> im.save("C:\\Demo_dpi.png")

try:

im.save(filename, dpi=(72, 72))

</F>

From davidyan6 at gmail.com  Sun May 10 12:45:41 2009
From: davidyan6 at gmail.com (David Yan)
Date: Sun, 10 May 2009 22:45:41 +1200
Subject: [Image-SIG] Lanczos interpolation
Message-ID: <2fede7f50905100345n58232bc2va0f00ea0c876c425@mail.gmail.com>

I want to resize an image Lanczos interpolation but I haven't found any
python module that can do so.  Also, I'm not knowledgeable enough to write
one myself.  What's the best way I can do this?  I use PIL currently but the
resampling filters don't suit my needs (antialias is too slow, bilinear and
bicubic produce aliasing when downsampling).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090510/067c3f56/attachment.htm>

From wrybread at gmail.com  Tue May 12 05:11:06 2009
From: wrybread at gmail.com (Alec Bennett)
Date: Mon, 11 May 2009 20:11:06 -0700
Subject: [Image-SIG] question about DPI
Message-ID: <cab7082b0905112011u610b552bm45741f24f8008ef9@mail.gmail.com>

I'm pasting a few images onto a canvas, resizing them, and saving the canvas
in 300 dpi. The idea that even though I'm resizing those pictures, I'd like
to preserve as much of their data as possible. In other words I'd like them
to be very high quality.

I'm not sure I'm doing this correctly, however. I think I'm losing a lot of
quality in the resizing stage. Can anyone see room for improvement in my
code?

If it matters, the pictures that I'm pasting in are from a digital camera.

Here's the stripped down relevant bits:


import Image

canvas = Image.new("RGBA", (1800, 1200), "black" ) # 6"x4" printed

im1 = Image.open("test1.jpg").convert('RGBA') # this would be larger than
3000 pixels wide, very large
im1 = im1.resize ( (800, 600) )
canvas.paste(im1, (0, 0), im1 )

im2 = Image.open("test2.jpg").convert('RGBA')
im2 = im2.resize ( (800, 600) )
canvas.paste(im2, (900, 0), im2 )

canvas.save("output.jpg", quality=100, dpi = (300, 300))
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090511/3381293d/attachment.htm>

From dynaturtle.cai at gmail.com  Tue May 12 07:11:55 2009
From: dynaturtle.cai at gmail.com (Cai Xiao(dynaturtle))
Date: Tue, 12 May 2009 13:11:55 +0800
Subject: [Image-SIG] problem with putdata function
Message-ID: <448f7bd20905112211s4ab0fae4u1e53665a5f6c3f15@mail.gmail.com>

Hey, I am new to PIL. And I have a problem with putdata function when I try
to load some data to the image objectThe code is as following:


   1.     mode = 'RGB'
   2.     size = (sregion.right - sregion.left, sregion.top -
   sregion.bottom)
   3.     im = Image.new(mode, size)
   4.
   5.     if type == 'dem':
   6.         minV = band.GetMinimum()
   7.         maxV = band.GetMaximum()
   8.         imData = []
   9.         for j in range(size[1]):
   10.             for i in range(size[0]):
   11.                 heightValue = int((rasterTuple[i * size[0] + j] -
   minV) * 255 / (maxV - minV))
   12.                 pixelValue = (i,j,heightValue)
   13.                 imData.append(pixelValue)
   14.
   15.         im.putdata(imData)

    I got a error when the program run to line 15, the error information is
as following:
          OverflowError: 'long int too large to convert to int'
    the imData length is 981760, and my computer memory is 2GB

Can anyone help me fix the problem?
Thanks

-- 
Department of Spatial Information Science&Technology,
School of Earth&Space Science, Peking University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090512/9353be31/attachment.htm>

From cannon.el at gmail.com  Mon May  4 20:28:24 2009
From: cannon.el at gmail.com (Laura & Edward Cannon)
Date: Mon, 4 May 2009 11:28:24 -0700
Subject: [Image-SIG] PIL - Tiff problems
In-Reply-To: <49FF2986.3010309@genome.med.harvard.edu>
References: <49FEF6CF.2030505@genome.med.harvard.edu>
	<368a5cd50905040857rb994dc4gf8267226896b5d04@mail.gmail.com>
	<49FF2986.3010309@genome.med.harvard.edu>
Message-ID: <b986b290905041128h356648ebudd8e6bfe47ad3fd2@mail.gmail.com>

You don't need to convert to mode P for png, and that might be some of the
issue. PNG supports mode L.

On Mon, May 4, 2009 at 10:44 AM, Andrew <agagne at genome.med.harvard.edu>wrote:

> In reality the tif will be ~7 mb, but i was able to use pil to shrink the
> image size. The problem comes with converting to a png.
>
> I open the tif then call
>
> im = im.convert("L")
> im = im.convert("P")
> im.save("C:\\test\\test2.png","PNG")
>
> To view the tif, I would generally use irfanview.
>
> thanks,
> andrew
>
>
> Fredrik Lundh wrote:
>
>> On Mon, May 4, 2009 at 4:08 PM, Andrew <agagne at genome.med.harvard.edu>
>> wrote:
>>
>>
>>> I've been having a problem with my tiff. When converting to a PNG or a
>>> JPEG
>>> the colors get messed up (black becomes white). I belive it has todo with
>>> the tiff being little endian. I noticed that in 1.1.7 the following was
>>> added to the change log.
>>>
>>>  Added limited support for I;16L mode (explicit little endian).
>>>
>>> Would someone be able to assist me in utilizing this? I've installed
>>> 1.1.7
>>> but am unsure of how to utilize this feature.
>>>
>>>
>>
>> Can you provide a sample in some way??  (you can mail it directly to
>> me if you don't want everyone to have access to the file; I never
>> redistribute sample files without permission).
>>
>> </F>
>>
>>
>
> _______________________________________________
> Image-SIG maillist  -  Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090504/894d8666/attachment.htm>

From fredrik at pythonware.com  Tue May 12 14:35:41 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 12 May 2009 14:35:41 +0200
Subject: [Image-SIG] Lanczos interpolation
In-Reply-To: <2fede7f50905100345n58232bc2va0f00ea0c876c425@mail.gmail.com>
References: <2fede7f50905100345n58232bc2va0f00ea0c876c425@mail.gmail.com>
Message-ID: <368a5cd50905120535y56292766n7565ddacfe818c16@mail.gmail.com>

On Sun, May 10, 2009 at 12:45 PM, David Yan <davidyan6 at gmail.com> wrote:
> I want to resize an image Lanczos interpolation but I haven't found any
> python module that can do so.? Also, I'm not knowledgeable enough to write
> one myself.? What's the best way I can do this?? I use PIL currently but the
> resampling filters don't suit my needs (antialias is too slow, bilinear and
> bicubic produce aliasing when downsampling).

ANTIALIAS is a Lanczos interpolation written in C, so it's not
entirely obvious to me how you expect a Python version to be faster...

</F>

From fredrik at pythonware.com  Tue May 12 14:44:12 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 12 May 2009 14:44:12 +0200
Subject: [Image-SIG] problem with putdata function
In-Reply-To: <448f7bd20905112211s4ab0fae4u1e53665a5f6c3f15@mail.gmail.com>
References: <448f7bd20905112211s4ab0fae4u1e53665a5f6c3f15@mail.gmail.com>
Message-ID: <368a5cd50905120544m4f10157dg22fc370104761041@mail.gmail.com>

On Tue, May 12, 2009 at 7:11 AM, Cai Xiao(dynaturtle)
<dynaturtle.cai at gmail.com> wrote:
> Hey, I am new to PIL. And I have a problem with putdata function when I try
> to load some data to the image object
> The code is as following:
>
> ?? ?mode = 'RGB'
> ?? ?size = (sregion.right - sregion.left, sregion.top - sregion.bottom)
> ?? ?im = Image.new(mode, size)
>
> ?? ?if type == 'dem':
> ?? ? ? ?minV = band.GetMinimum()
> ?? ? ? ?maxV = band.GetMaximum()
> ?? ? ? ?imData = []
> ?? ? ? ?for j in range(size[1]):
> ?? ? ? ? ? ?for i in range(size[0]):
> ?? ? ? ? ? ? ? ?heightValue = int((rasterTuple[i * size[0] + j] - minV) *
> 255 / (maxV - minV))
> ?? ? ? ? ? ? ? ?pixelValue = (i,j,heightValue)
> ?? ? ? ? ? ? ? ?imData.append(pixelValue)
>
> ?? ? ? ?im.putdata(imData)
>
> ?? ?I got a error when the program run to line 15, the error information is
> as following:
> ?? ? ? ? ?OverflowError: 'long int too large to convert to int'
> ?? ?the imData length is 981760, and my computer memory is 2GB

This means that you have pixels with RGB values bigger than 255 (and
unless you've hit a buglet, they're a *lot* bigger than 255).

Try doing this before the putdata call:

    print max(pixel[0] for pixel in imData) # max red
    print max(pixel[1] for pixel in imData) # max green
    print max(pixel[2] for pixel in imData) # max blue

and make sure the values are in the expected range.

</F>

From fredrik at pythonware.com  Tue May 12 14:39:18 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 12 May 2009 14:39:18 +0200
Subject: [Image-SIG] question about DPI
In-Reply-To: <cab7082b0905112011u610b552bm45741f24f8008ef9@mail.gmail.com>
References: <cab7082b0905112011u610b552bm45741f24f8008ef9@mail.gmail.com>
Message-ID: <368a5cd50905120539t48815cadtbba39879dcc56cac@mail.gmail.com>

On Tue, May 12, 2009 at 5:11 AM, Alec Bennett <wrybread at gmail.com> wrote:
> I'm pasting a few images onto a canvas, resizing them, and saving the canvas
> in 300 dpi. The idea that even though I'm resizing those pictures, I'd like
> to preserve as much of their data as possible. In other words I'd like them
> to be very high quality.
>
> I'm not sure I'm doing this correctly, however. I think I'm losing a lot of
> quality in the resizing stage. Can anyone see room for improvement in my
> code?
>
> If it matters, the pictures that I'm pasting in are from a digital camera.
>
> Here's the stripped down relevant bits:
>
> import Image
>
> canvas = Image.new("RGBA", (1800, 1200), "black" ) # 6"x4" printed
>
> im1 = Image.open("test1.jpg").convert('RGBA') # this would be larger than
> 3000 pixels wide, very large
> im1 = im1.resize ( (800, 600) )

Try:

im1 = im1.resize ( (800, 600), Image.ANTIALIAS )

or, more efficient if the source image is a lot larger than the result:

im1.thumbnail ( (800, 600), Image.ANTIALIAS )

(when used directly after open, the latter tells the JPEG decoder to
downsample during decoding, and then updates the image in place).

</F>

From dynaturtle.cai at gmail.com  Tue May 12 14:46:06 2009
From: dynaturtle.cai at gmail.com (Cai Xiao(dynaturtle))
Date: Tue, 12 May 2009 20:46:06 +0800
Subject: [Image-SIG] problem with putdata function
In-Reply-To: <368a5cd50905120544m4f10157dg22fc370104761041@mail.gmail.com>
References: <448f7bd20905112211s4ab0fae4u1e53665a5f6c3f15@mail.gmail.com>
	<368a5cd50905120544m4f10157dg22fc370104761041@mail.gmail.com>
Message-ID: <448f7bd20905120546q5fc00cedy5cb638b1ebf38f3c@mail.gmail.com>

Thanks for your suggestion. And I find where the problem is.

On Tue, May 12, 2009 at 8:44 PM, Fredrik Lundh <fredrik at pythonware.com>wrote:

> On Tue, May 12, 2009 at 7:11 AM, Cai Xiao(dynaturtle)
> <dynaturtle.cai at gmail.com> wrote:
> > Hey, I am new to PIL. And I have a problem with putdata function when I
> try
> > to load some data to the image object
> > The code is as following:
> >
> >     mode = 'RGB'
> >     size = (sregion.right - sregion.left, sregion.top - sregion.bottom)
> >     im = Image.new(mode, size)
> >
> >     if type == 'dem':
> >         minV = band.GetMinimum()
> >         maxV = band.GetMaximum()
> >         imData = []
> >         for j in range(size[1]):
> >             for i in range(size[0]):
> >                 heightValue = int((rasterTuple[i * size[0] + j] - minV) *
> > 255 / (maxV - minV))
> >                 pixelValue = (i,j,heightValue)
> >                 imData.append(pixelValue)
> >
> >         im.putdata(imData)
> >
> >     I got a error when the program run to line 15, the error information
> is
> > as following:
> >           OverflowError: 'long int too large to convert to int'
> >     the imData length is 981760, and my computer memory is 2GB
>
> This means that you have pixels with RGB values bigger than 255 (and
> unless you've hit a buglet, they're a *lot* bigger than 255).
>
> Try doing this before the putdata call:
>
>    print max(pixel[0] for pixel in imData) # max red
>    print max(pixel[1] for pixel in imData) # max green
>    print max(pixel[2] for pixel in imData) # max blue
>
> and make sure the values are in the expected range.
>
> </F>
>



-- 
Department of Spatial Information Science&Technology,
School of Earth&Space Science, Peking University

ADD: Room 3028, Building 46, Peking University, Beijing, P.R. China
Zip Code: 100871
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090512/207d18a3/attachment.htm>

From janssen at parc.com  Wed May 13 02:25:26 2009
From: janssen at parc.com (Bill Janssen)
Date: Tue, 12 May 2009 17:25:26 PDT
Subject: [Image-SIG] JPEG2000 and PIL
Message-ID: <15556.1242174326@parc.com>

Is there any particular reason not to include a JPEG 2000 module in PIL?
Is anyone working on this?
Using Jasper, for instance?

Thanks.

Bill

From wrybread at gmail.com  Thu May 14 13:02:32 2009
From: wrybread at gmail.com (Alec Bennett)
Date: Thu, 14 May 2009 04:02:32 -0700
Subject: [Image-SIG] how to draw a stroke/outline around text with PIL?
Message-ID: <cab7082b0905140402w28fef0ccr4dd2f401160ffbd3@mail.gmail.com>

I'm trying to draw an outline (what Photoshop calls a stroke) around
some text. Does anyone have any pointers?

Here's the code I'm using to draw the basic text:

import Image, ImageFont, ImageDraw

import win32api

im = Image.open("test.jpg")
pointsize = 30
textcolor = "red"
font = win32api.GetWindowsDirectory() + "\\Fonts\\ARIALBD.TTF"
draw = ImageDraw.Draw(im)
font = ImageFont.truetype(font, pointsize)
draw.text((10, 10), "hi there", font=font, fill=textcolor)
im.save("test2.jpg")

From wrybread at gmail.com  Thu May 14 13:16:23 2009
From: wrybread at gmail.com (Alec Bennett)
Date: Thu, 14 May 2009 04:16:23 -0700
Subject: [Image-SIG] how to draw a stroke/outline around text with PIL?
In-Reply-To: <cab7082b0905140402w28fef0ccr4dd2f401160ffbd3@mail.gmail.com>
References: <cab7082b0905140402w28fef0ccr4dd2f401160ffbd3@mail.gmail.com>
Message-ID: <cab7082b0905140416l171a0071t6dd5ef078bf85b32@mail.gmail.com>

For anyone else who comes down this road, I found a way to do this in
the videocapture.py module. Seems to work well. Here's my code
adapted:


import Image, ImageFont, ImageDraw

import win32api, os

x, y = 10, 10

fname1 = "c:/test.jpg"
im = Image.open(fname1)
pointsize = 30
fillcolor = "red"
shadowcolor = "yellow"

text = "hi there"

font = win32api.GetWindowsDirectory() + "\\Fonts\\ARIALBD.TTF"
draw = ImageDraw.Draw(im)
font = ImageFont.truetype(font, pointsize)

# thin border
draw.text((x-1, y), text, font=font, fill=shadowcolor)
draw.text((x+1, y), text, font=font, fill=shadowcolor)
draw.text((x, y-1), text, font=font, fill=shadowcolor)
draw.text((x, y+1), text, font=font, fill=shadowcolor)

# thicker border
draw.text((x-1, y-1), text, font=font, fill=shadowcolor)
draw.text((x+1, y-1), text, font=font, fill=shadowcolor)
draw.text((x-1, y+1), text, font=font, fill=shadowcolor)
draw.text((x+1, y+1), text, font=font, fill=shadowcolor)

# now draw the text over it
draw.text((x, y), text, font=font, fill=fillcolor)

fname2 = "c:/test2.jpg"
im.save(fname2)

os.startfile(fname2)

From wrybread at gmail.com  Fri May 15 07:19:16 2009
From: wrybread at gmail.com (Alec Bennett)
Date: Thu, 14 May 2009 22:19:16 -0700
Subject: [Image-SIG] Filter Factory filters in PIL?
Message-ID: <cab7082b0905142219y2e7caad1wf12d3f4d7d4ec954@mail.gmail.com>

Does anyone know if its possible to use Filter Factory (aka 8bf) files
in PIL, or any other way from Python or commandline? Apparently
there's a plugin for Gimp:

http://registry.gimp.org/node/10902

But I'd really like to be able to use these filters from Python if possible.

For anyone who doesn't know, Filter Factory files are generally known
as Photoshop filters, but they're super easy to create and there's
lots and lots of them available for free online.

From jesper.webmail at gmail.com  Mon May 18 10:15:30 2009
From: jesper.webmail at gmail.com (Jesper Larsen)
Date: Mon, 18 May 2009 10:15:30 +0200
Subject: [Image-SIG] Quantization of PNG images
Message-ID: <fa493d130905180115w6c19ce68s6e528397feb0c9f5@mail.gmail.com>

Hi image-sig,
I am producing some png images for a web application. Some of the
images are cached and reused for other requests. I am using matplotlib
to produce the images. Unfortunately the images are quite large (up to
~300 kb). I therefore tried using the Linux utilities pngcrush and
pngnq for compressing the images. pngnq gave by far the best results
(~300 kb -> ~90 kb in 0.4-0.5 seconds on my laptop; combining the two
tools did not yield further improvements). It reduces the color depth
to 8 bits (from 24) without any apparent image quality problems using
color quantization (http://en.wikipedia.org/wiki/Color_quantization).

Is it possible to do this in PIL directly or will I have to code it
myself? At present I am considering just calling pngnq from my Python
code but I would rather not do that.

Another thing is that for performance reasons I might want later to
reuse the colormap (since the image colors are pretty much the same).
Neither pngnq nor pngquant (which pngnq is based on) supports this
yet.

Best regards,
Jesper

(Thanks to Jouni K. Sepp?nen on the matplotlib mailing list for
suggesting looking at PIL for this)

From fredrik at pythonware.com  Mon May 18 13:10:45 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 18 May 2009 13:10:45 +0200
Subject: [Image-SIG] Quantization of PNG images
In-Reply-To: <fa493d130905180115w6c19ce68s6e528397feb0c9f5@mail.gmail.com>
References: <fa493d130905180115w6c19ce68s6e528397feb0c9f5@mail.gmail.com>
Message-ID: <368a5cd50905180410l50e97c72h685db41289ded5a0@mail.gmail.com>

On Mon, May 18, 2009 at 10:15 AM, Jesper Larsen
<jesper.webmail at gmail.com> wrote:

> I am producing some png images for a web application. Some of the
> images are cached and reused for other requests. I am using matplotlib
> to produce the images. Unfortunately the images are quite large (up to
> ~300 kb). I therefore tried using the Linux utilities pngcrush and
> pngnq for compressing the images. pngnq gave by far the best results
> (~300 kb -> ~90 kb in 0.4-0.5 seconds on my laptop; combining the two
> tools did not yield further improvements). It reduces the color depth
> to 8 bits (from 24) without any apparent image quality problems using
> color quantization (http://en.wikipedia.org/wiki/Color_quantization).
>
> Is it possible to do this in PIL directly or will I have to code it
> myself? At present I am considering just calling pngnq from my Python
> code but I would rather not do that.
>
> Another thing is that for performance reasons I might want later to
> reuse the colormap (since the image colors are pretty much the same).
> Neither pngnq nor pngquant (which pngnq is based on) supports this
> yet.

If you convert the image to mode "P" before you save it, you get a
fixed 8-bit palette by default (based on "web safe colors").  To have
PIL pick an "optimal" palette instead, use convert("P",
palette=Image.ADAPTIVE).  See

    http://effbot.org/tag/PIL.Image.Image.convert

for more options.

The algorithm used by pngnq seems to be a bit better (though a lot
slower) than PIL's median cut algorithm, so you might not get quite as
good results as you get with pngnq.

</F>

From fredrik at pythonware.com  Mon May 18 13:14:59 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Mon, 18 May 2009 13:14:59 +0200
Subject: [Image-SIG] Quantization of PNG images
In-Reply-To: <368a5cd50905180410l50e97c72h685db41289ded5a0@mail.gmail.com>
References: <fa493d130905180115w6c19ce68s6e528397feb0c9f5@mail.gmail.com> 
	<368a5cd50905180410l50e97c72h685db41289ded5a0@mail.gmail.com>
Message-ID: <368a5cd50905180414t72af3a5ev3ea5ae6540c99d2b@mail.gmail.com>

On Mon, May 18, 2009 at 1:10 PM, Fredrik Lundh <fredrik at pythonware.com> wrote:

> If you convert the image to mode "P" before you save it, you get a
> fixed 8-bit palette by default (based on "web safe colors"). ?To have
> PIL pick an "optimal" palette instead, use convert("P",
> palette=Image.ADAPTIVE). ?See
>
> ? ?http://effbot.org/tag/PIL.Image.Image.convert
>
> for more options.

And yes, make sure you pass optimize=True to the save method, to force
PIL to work a bit harder when compressing the image:

   http://effbot.org/imagingbook/format-png.htm

</F>

From zac256 at gmail.com  Mon May 18 18:49:46 2009
From: zac256 at gmail.com (Zac Burns)
Date: Mon, 18 May 2009 09:49:46 -0700
Subject: [Image-SIG] PIL - Opens tga as WbmpImageFile
Message-ID: <333edbe80905180949h329847ccuf4abd89e456d7f42@mail.gmail.com>

I have a script that is attempting to verify that an image is square.

This is accomplished using PIL.Image.open(filename).size

Within the context that the script is being run it is opening a tga as
a WbmpImageFile and reporting the size to be (2, 0).
However, printing repr(filename), copying the filename, and running
the line with that file from a fresh Python interpreter gives the
correct results.


PIL version is 1.1.6
Python version is 2.5.1

--
Zachary Burns
(407)590-4814
Aim - Zac256FL
Production Engineer (Digital Overlord)
Zindagi Games

From zac256 at gmail.com  Mon May 18 20:05:54 2009
From: zac256 at gmail.com (Zac Burns)
Date: Mon, 18 May 2009 11:05:54 -0700
Subject: [Image-SIG] PIL - Opens tga as WbmpImageFile
In-Reply-To: <333edbe80905180949h329847ccuf4abd89e456d7f42@mail.gmail.com>
References: <333edbe80905180949h329847ccuf4abd89e456d7f42@mail.gmail.com>
Message-ID: <333edbe80905181105w5092b3bcg68140a6a7d39fcef@mail.gmail.com>

On Mon, May 18, 2009 at 9:49 AM, Zac Burns <zac256 at gmail.com> wrote:
> I have a script that is attempting to verify that an image is square.
>
> This is accomplished using PIL.Image.open(filename).size
>
> Within the context that the script is being run it is opening a tga as
> a WbmpImageFile and reporting the size to be (2, 0).
> However, printing repr(filename), copying the filename, and running
> the line with that file from a fresh Python interpreter gives the
> correct results.
>
>
> PIL version is 1.1.6
> Python version is 2.5.1
>
> --
> Zachary Burns
> (407)590-4814
> Aim - Zac256FL
> Production Engineer (Digital Overlord)
> Zindagi Games
>

I locally patched the PIL.Image.open function to fix the bug and made
some other improvements along the way.

I'm not familiar with the PIL patch process and am not sure that the
changes will be accepted by the community so I'll just post the code
here.

Chages:
   1. More informative error message
   2. Optimization: Moved import __builtin__ to top of file. (I'm not
sure why but importing is relatively slow on my machine)
   3. Factored shared code into an inline function
   4. Does preinit and init before trying any plugins
   5. Prefers the extension of the filepath

I presume there were reasons for doing it the other way before, which
is why the patch might not be accepted.

One problem right now is that the "preferredID" is only implemented if
fp is given as a string. I would like "preferredID =
os.path.splitext(filename)[1]" to read like "preferredID =
os.path.splitext(filename or getattr(fp, name))[1]" except that name
might be of the form "<...>" which doesn't play well with
os.path.splitext.

###########################################
def open(fp, mode="r"):
	"Open an image file, without loading the raster data"

	if mode != "r":
		raise ValueError("bad mode")

	if isStringType(fp):
		filename = fp
		fp = __builtin__.open(fp, "rb")
	else:
		filename = ""

	prefix = fp.read(16)

	preinit()
	init()

	def _open(id_):
		factory, accept = OPEN[id_]
		if not accept or accept(prefix):
			fp.seek(0)
			return factory(fp, filename)

	_open_errors = (SyntaxError, IndexError, TypeError)

	# Prefer extension of filename if given.
	preferredID = os.path.splitext(filename)[1]
	if preferredID:
		preferredID = preferredID[1:].upper() # OPEN keys are uppercase without a '.'
		if preferredID in OPEN:
			try:
				return _open(preferredID)
			except _open_errors:
				pass

	# Try each ID in order
	for i in ID:
		try:
			return _open(i)
		except _open_errors:
			pass

	raise IOError("cannot identify image file %s" % repr(filename or fp))
###########################################

--
Zachary Burns
(407)590-4814
Aim - Zac256FL
Production Engineer (Digital Overlord)
Zindagi Games

From fredrik at pythonware.com  Tue May 19 01:11:03 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 19 May 2009 01:11:03 +0200
Subject: [Image-SIG] PIL - Opens tga as WbmpImageFile
In-Reply-To: <333edbe80905181105w5092b3bcg68140a6a7d39fcef@mail.gmail.com>
References: <333edbe80905180949h329847ccuf4abd89e456d7f42@mail.gmail.com> 
	<333edbe80905181105w5092b3bcg68140a6a7d39fcef@mail.gmail.com>
Message-ID: <368a5cd50905181611x63a3838eg9dbfbfcd794443dd@mail.gmail.com>

On Mon, May 18, 2009 at 8:05 PM, Zac Burns <zac256 at gmail.com> wrote:
> On Mon, May 18, 2009 at 9:49 AM, Zac Burns <zac256 at gmail.com> wrote:
>> I have a script that is attempting to verify that an image is square.
>>
>> This is accomplished using PIL.Image.open(filename).size
>>
>> Within the context that the script is being run it is opening a tga as
>> a WbmpImageFile and reporting the size to be (2, 0).
>> However, printing repr(filename), copying the filename, and running
>> the line with that file from a fresh Python interpreter gives the
>> correct results.
>>
>>
>> PIL version is 1.1.6
>> Python version is 2.5.1
>>
>> --
>> Zachary Burns
>> (407)590-4814
>> Aim - Zac256FL
>> Production Engineer (Digital Overlord)
>> Zindagi Games
>>
>
> I locally patched the PIL.Image.open function to fix the bug and made
> some other improvements along the way.
>
> I'm not familiar with the PIL patch process and am not sure that the
> changes will be accepted by the community so I'll just post the code
> here.
>
> Chages:
> ? 1. More informative error message
> ? 2. Optimization: Moved import __builtin__ to top of file. (I'm not
> sure why but importing is relatively slow on my machine)
> ? 3. Factored shared code into an inline function
> ? 4. Does preinit and init before trying any plugins
> ? 5. Prefers the extension of the filepath

This will change the open semantic enough to risk breaking tons of
stuff, and also slow PIL down a lot for people using only common file
formats (and if importing the builtin module is slow on your machine,
something's fishy with your interpreter - that module is built into
the Python core).

The right way to fix this would be to make the TGA accept function
smarter to avoid false positives.  Do you have any samples of the
problematic WBMP files that you can share? (feel free to mail them
directly to me; I won't make them public without explicit permission)

</F>

From zac256 at gmail.com  Tue May 19 02:33:03 2009
From: zac256 at gmail.com (Zac Burns)
Date: Mon, 18 May 2009 17:33:03 -0700
Subject: [Image-SIG] PIL - Opens tga as WbmpImageFile
In-Reply-To: <368a5cd50905181611x63a3838eg9dbfbfcd794443dd@mail.gmail.com>
References: <333edbe80905180949h329847ccuf4abd89e456d7f42@mail.gmail.com>
	<333edbe80905181105w5092b3bcg68140a6a7d39fcef@mail.gmail.com>
	<368a5cd50905181611x63a3838eg9dbfbfcd794443dd@mail.gmail.com>
Message-ID: <333edbe80905181733j738cf722p88ee38d1228b2e09@mail.gmail.com>

On Mon, May 18, 2009 at 4:11 PM, Fredrik Lundh <fredrik at pythonware.com> wrote:
> On Mon, May 18, 2009 at 8:05 PM, Zac Burns <zac256 at gmail.com> wrote:
>> On Mon, May 18, 2009 at 9:49 AM, Zac Burns <zac256 at gmail.com> wrote:
>>> I have a script that is attempting to verify that an image is square.
>>>
>>> This is accomplished using PIL.Image.open(filename).size
>>>
>>> Within the context that the script is being run it is opening a tga as
>>> a WbmpImageFile and reporting the size to be (2, 0).
>>> However, printing repr(filename), copying the filename, and running
>>> the line with that file from a fresh Python interpreter gives the
>>> correct results.
>>>
>>>
>>> PIL version is 1.1.6
>>> Python version is 2.5.1
>>>
>>> --
>>> Zachary Burns
>>> (407)590-4814
>>> Aim - Zac256FL
>>> Production Engineer (Digital Overlord)
>>> Zindagi Games
>>>
>>
>> I locally patched the PIL.Image.open function to fix the bug and made
>> some other improvements along the way.
>>
>> I'm not familiar with the PIL patch process and am not sure that the
>> changes will be accepted by the community so I'll just post the code
>> here.
>>
>> Chages:
>> ? 1. More informative error message
>> ? 2. Optimization: Moved import __builtin__ to top of file. (I'm not
>> sure why but importing is relatively slow on my machine)
>> ? 3. Factored shared code into an inline function
>> ? 4. Does preinit and init before trying any plugins
>> ? 5. Prefers the extension of the filepath
>
> This will change the open semantic enough to risk breaking tons of
> stuff, and also slow PIL down a lot for people using only common file
> formats (and if importing the builtin module is slow on your machine,
> something's fishy with your interpreter - that module is built into
> the Python core).
>
> The right way to fix this would be to make the TGA accept function
> smarter to avoid false positives. ?Do you have any samples of the
> problematic WBMP files that you can share? (feel free to mail them
> directly to me; I won't make them public without explicit permission)
>
> </F>
>

Please explain the case that it would be slower. I'm not sure I
follow. It seems to me that the change would for many people actually
make loading images faster because rather than try each accept
function in succession (in some cases twice over) we take a 'best
guess' approach first, then go to the other functions (once over). The
worst case appears to be one extra check. Best case we go straight for
the correct loader.

About the example, I think it's reversed - WBMP is the one giving the
false positive because it opens the .tga file, which is using targa
compression, as a WBMP. If I have time after work I'll try and figure
out a little more about what is causing this before sending an example
because like I said in the original e-mail it's something about the
context which is causing this - if I simply run the code in a fresh
interpreter it opens as a tga just fine.

About the importing of __builtin__, it's a very small speed
improvement - only a couple of milliseconds. Which, is slow enough
that I've started putting all my imports at the top of all files as a
habit - even if it's not a huge difference in this case. This is also
part of the python style guide.


--
Zachary Burns
(407)590-4814
Aim - Zac256FL
Production Engineer (Digital Overlord)
Zindagi Games

From fredrik at pythonware.com  Tue May 19 09:52:16 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 19 May 2009 09:52:16 +0200
Subject: [Image-SIG] PIL - Opens tga as WbmpImageFile
In-Reply-To: <333edbe80905181733j738cf722p88ee38d1228b2e09@mail.gmail.com>
References: <333edbe80905180949h329847ccuf4abd89e456d7f42@mail.gmail.com> 
	<333edbe80905181105w5092b3bcg68140a6a7d39fcef@mail.gmail.com> 
	<368a5cd50905181611x63a3838eg9dbfbfcd794443dd@mail.gmail.com> 
	<333edbe80905181733j738cf722p88ee38d1228b2e09@mail.gmail.com>
Message-ID: <368a5cd50905190052m1901cc77x27e9a4e6f5148faa@mail.gmail.com>

On Tue, May 19, 2009 at 2:33 AM, Zac Burns <zac256 at gmail.com> wrote:

> Please explain the case that it would be slower. I'm not sure I
> follow. It seems to me that the change would for many people actually
> make loading images faster because rather than try each accept
> function in succession (in some cases twice over) we take a 'best
> guess' approach first, then go to the other functions (once over). The
> worst case appears to be one extra check. Best case we go straight for
> the correct loader.

Your code pulls in codecs for all programs.  That's a *lot* slower for
people using only standard file formats (why do you think the init was
split up in to parts in the first place?)

> About the example, I think it's reversed - WBMP is the one giving the
> false positive because it opens the .tga file, which is using targa
> compression, as a WBMP. If I have time after work I'll try and figure
> out a little more about what is causing this before sending an example
> because like I said in the original e-mail it's something about the
> context which is causing this - if I simply run the code in a fresh
> interpreter it opens as a tga just fine.

Looking at the actual code, it's pretty clear that WBMP support
shouldn't be enabled by default; that file format has no usable magic
code at the beginning of the file (neither has TGA, but at least was
their first).  I also notice that WBMP is not included in the 1.1.7
code base at all, and it's not listed in the CONTENTS file for 1.1.6;
it is present in the windows installer, at least, so this might be a
bug in the installer build process...

> About the importing of __builtin__, it's a very small speed
> improvement - only a couple of milliseconds. Which, is slow enough
> that I've started putting all my imports at the top of all files as a
> habit - even if it's not a huge difference in this case. This is also
> part of the python style guide.

A couple of milliseconds?

> python -m timeit "import __builtin__"
1000000 loops, best of 3: 1.1 usec per loop

Looks like something's wrong with your Python installation.

</F>

From fredrik at pythonware.com  Tue May 19 09:52:41 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 19 May 2009 09:52:41 +0200
Subject: [Image-SIG] PIL - Opens tga as WbmpImageFile
In-Reply-To: <368a5cd50905190052m1901cc77x27e9a4e6f5148faa@mail.gmail.com>
References: <333edbe80905180949h329847ccuf4abd89e456d7f42@mail.gmail.com> 
	<333edbe80905181105w5092b3bcg68140a6a7d39fcef@mail.gmail.com> 
	<368a5cd50905181611x63a3838eg9dbfbfcd794443dd@mail.gmail.com> 
	<333edbe80905181733j738cf722p88ee38d1228b2e09@mail.gmail.com> 
	<368a5cd50905190052m1901cc77x27e9a4e6f5148faa@mail.gmail.com>
Message-ID: <368a5cd50905190052y8f118e0q44b10b7398c52499@mail.gmail.com>

On Tue, May 19, 2009 at 9:52 AM, Fredrik Lundh <fredrik at pythonware.com> wrote:

> Your code pulls in codecs for all programs. ?That's a *lot* slower for
> people using only standard file formats (why do you think the init was
> split up in to parts in the first place?)

All codecs for all programs, that is.

</F>

From fredrik at pythonware.com  Tue May 19 10:52:51 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 19 May 2009 10:52:51 +0200
Subject: [Image-SIG] PIL - Opens tga as WbmpImageFile
In-Reply-To: <368a5cd50905190052y8f118e0q44b10b7398c52499@mail.gmail.com>
References: <333edbe80905180949h329847ccuf4abd89e456d7f42@mail.gmail.com> 
	<333edbe80905181105w5092b3bcg68140a6a7d39fcef@mail.gmail.com> 
	<368a5cd50905181611x63a3838eg9dbfbfcd794443dd@mail.gmail.com> 
	<333edbe80905181733j738cf722p88ee38d1228b2e09@mail.gmail.com> 
	<368a5cd50905190052m1901cc77x27e9a4e6f5148faa@mail.gmail.com> 
	<368a5cd50905190052y8f118e0q44b10b7398c52499@mail.gmail.com>
Message-ID: <368a5cd50905190152q2a7b1ed2u6da79c9cdd7200e8@mail.gmail.com>

>  but at least was their first

(Eh?  I did switch from machine with a German "kezboard" to one with a
Swedish keyboard just before writing that mail, but I'm not sure how
that explains the typos.  Probably caffeine-related...)

From gtaylor at clemson.edu  Tue May 19 21:52:43 2009
From: gtaylor at clemson.edu (Greg Taylor)
Date: Tue, 19 May 2009 15:52:43 -0400
Subject: [Image-SIG] Group4 Tiff Decoder?
Message-ID: <8de369d70905191252g7e2fe70ayeeb9c9847509b628@mail.gmail.com>

Hello all,

Googling around, I keep seeing mention over the years that PIL has no Group4
tiff decoder. I saw mention of a patch for PIL 1.1.4, but it doesn't look
like this ever made it into upstream. Perhaps I haven't dug deep enough, but
can anyone enlighten me to what the situation is currently with Group4 Tiff
decoding? I'd love to be able to use PIL for some mission critical stuff at
work, but this is a show-stopper due to our setup.

Thanks in advance,
Greg

-- 
Greg Taylor
Clemson University, Class of 2009
Cell: (864) 888-7964
http://gc-taylor.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090519/ea823da3/attachment.htm>

From glenn at nevcal.com  Tue May 19 23:05:45 2009
From: glenn at nevcal.com (Glenn Linderman)
Date: Tue, 19 May 2009 14:05:45 -0700
Subject: [Image-SIG] Group4 Tiff Decoder?
In-Reply-To: <8de369d70905191252g7e2fe70ayeeb9c9847509b628@mail.gmail.com>
References: <8de369d70905191252g7e2fe70ayeeb9c9847509b628@mail.gmail.com>
Message-ID: <4A131F29.9010902@nevcal.com>

On approximately 5/19/2009 12:52 PM, came the following characters from 
the keyboard of Greg Taylor:
> Hello all,
>
> Googling around, I keep seeing mention over the years that PIL has no 
> Group4 tiff decoder. I saw mention of a patch for PIL 1.1.4, but it 
> doesn't look like this ever made it into upstream. Perhaps I haven't 
> dug deep enough, but can anyone enlighten me to what the situation is 
> currently with Group4 Tiff decoding? I'd love to be able to use PIL 
> for some mission critical stuff at work, but this is a show-stopper 
> due to our setup.

I'm currently using command-line ImageMagick and (when on Windows) 
command-line IrfanView (which is way faster than ImageMagick for Group4 
TIFF filse) because PIL doesn't do Group4 decoding or encoding, and 
because the wrapper for direct use of TIFF lib is arcane (which is no 
surprise, because TIFF lib's API is arcane to start with).

What I would dearly like is a simple API that would read a Group4 TIFF 
and convert it to an array of memory bitmaps (one per internal image) in 
a format (a PIL format, or otherwise) that could be manipulated, and 
preferably each array entry converted to/from QtImage format, and 
another API that writes it back out in Group4 TIFF format.

David Boddie provided a source Qt image extension of some sort some time 
back that might do the job, Qt-wise, at least for a single page file, 
but I haven't had time to figure out how to compile my own versions of 
Qt, PyQt, SIP, etc., to figure out how to make that work, nor to figure 
out if it handles multiple page images.

So, this awaits someone providing it, or a large rasher of tuits 
provided, for me to figure out the TIFF lib API and code it myself.

-- 
Glenn
------------------------------------------------------------------------
?Everyone is entitled to their own opinion, but not their own facts. In 
turn, everyone is entitled to their own opinions of the facts, but not 
their own facts based on their opinions.? -- Guy Rocha, retiring NV 
state archivist

From michele.petrazzo at unipex.it  Wed May 20 12:46:31 2009
From: michele.petrazzo at unipex.it (Michele Petrazzo - Unipex)
Date: Wed, 20 May 2009 12:46:31 +0200
Subject: [Image-SIG] Group4 Tiff Decoder?
In-Reply-To: <4A131F29.9010902@nevcal.com>
References: <8de369d70905191252g7e2fe70ayeeb9c9847509b628@mail.gmail.com>
	<4A131F29.9010902@nevcal.com>
Message-ID: <4A13DF87.8030605@unipex.it>

Glenn Linderman wrote:
>> but can anyone enlighten me to what the situation is currently with
>>  Group4 Tiff decoding? I'd love to be able to use PIL for some 
>> mission critical stuff at work, but this is a show-stopper due to 
>> our setup.
> 

Some times ago I develop freeimagepy due to this PIL "limitation" for a
my fax python project and release it, so you can use it for load
transform it into a pil image:

import FreeImagePy as FIPY
F = FIPY.Image()
F.load(imagePath)
  pil =F.convertToPil()

It's not so well developed as I would, but do its work!

Michele

From fredrik at pythonware.com  Wed May 20 14:34:58 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 20 May 2009 14:34:58 +0200
Subject: [Image-SIG] Group4 Tiff Decoder?
In-Reply-To: <8de369d70905191252g7e2fe70ayeeb9c9847509b628@mail.gmail.com>
References: <8de369d70905191252g7e2fe70ayeeb9c9847509b628@mail.gmail.com>
Message-ID: <368a5cd50905200534x6578b887kb8b86bd648b53c2@mail.gmail.com>

On Tue, May 19, 2009 at 9:52 PM, Greg Taylor <gtaylor at clemson.edu> wrote:

> Googling around, I keep seeing mention over the years that PIL has no Group4
> tiff decoder. I saw mention of a patch for PIL 1.1.4, but it doesn't look
> like this ever made it into upstream. Perhaps I haven't dug deep enough, but
> can anyone enlighten me to what the situation is currently with Group4 Tiff
> decoding? I'd love to be able to use PIL for some mission critical stuff at
> work, but this is a show-stopper due to our setup.

The patch depended on too many libtiff internals for me to feel
confident that it was a good idea to add it to PIL's standard
distribution; there are a few other bindings, but none that feels
complete enough.

In addition to the solution already posted, you can use "tiffcp -c
none -r -1 %s %s" % (myfilename, tempfilename) to unpack to a
temporary file; this is fairly efficient since PIL can then memory map
the resulting image file.  The tiffcp utility is shipped with libtiff.

</F>

From luke at liftinteractive.com  Fri May 22 20:19:18 2009
From: luke at liftinteractive.com (Luke Hutscal)
Date: Fri, 22 May 2009 12:19:18 -0600
Subject: [Image-SIG] Reading title EXIF data
Message-ID: <6a8d94bd0905221119n682a2868t96f640aec5addea7@mail.gmail.com>

Hello, all.


I am currently working on a Django application that stores photos as users
upload them.


One of the cooler features that we'd like to add is automatic EXIF reading -
so instead of users having to go through and update their photo's
information again after uploading them, the EXIF data on the uploaded photos
can get automatically read into certain fields - title, caption, and so on.


I have been using the Image._getexif() method to retrieve the EXIF data for
the photos that are being uploaded - but it seems that the "title" attribute
is missing. Here's an example of what _getexif() returns:


http://liftslice3.com/getexif.txt

However, when I run ExifTool(http://www.sno.phy.queensu.ca/~phil/exiftool/)
on the image with the -d flag, this is what is output:

http://liftslice3.com/exiftool.txt

As you can see, there's definitely a title attribute present on the image in
question. I took a look at the EXIF tags list at
http://www.element-it.com/StandardImageTags.ASPX, and noticed that the
ImageTitle EXIF tag isn't present in PIL's ExifTags.py - is there a reason
for this? I tried adding a key for 0x0320 with the value "ImageTitle" to the
TAGS dict, but PIL still doesn't seem to be reading the ImageTitle attribute
out of my images.

Is there something I've missed that is keeping PIL from reading the title
attribute?

Thanks,

Luke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090522/0335f326/attachment.htm>

From v+python at g.nevcal.com  Mon May 25 22:26:41 2009
From: v+python at g.nevcal.com (Glenn Linderman)
Date: Mon, 25 May 2009 13:26:41 -0700
Subject: [Image-SIG] Group4 Tiff Decoder?
In-Reply-To: <368a5cd50905200534x6578b887kb8b86bd648b53c2@mail.gmail.com>
References: <8de369d70905191252g7e2fe70ayeeb9c9847509b628@mail.gmail.com>
	<368a5cd50905200534x6578b887kb8b86bd648b53c2@mail.gmail.com>
Message-ID: <4A1AFF01.4060804@g.nevcal.com>

On approximately 5/20/2009 5:34 AM, came the following characters from 
the keyboard of Fredrik Lundh:
> On Tue, May 19, 2009 at 9:52 PM, Greg Taylor <gtaylor at clemson.edu> wrote:
>   
>> Googling around, I keep seeing mention over the years that PIL has no Group4
>> tiff decoder. I saw mention of a patch for PIL 1.1.4, but it doesn't look
>> like this ever made it into upstream. Perhaps I haven't dug deep enough, but
>> can anyone enlighten me to what the situation is currently with Group4 Tiff
>> decoding? I'd love to be able to use PIL for some mission critical stuff at
>> work, but this is a show-stopper due to our setup.
>>     
>
> The patch depended on too many libtiff internals for me to feel
> confident that it was a good idea to add it to PIL's standard
> distribution; 

So if a patch were produced that depended only on published libtiff 
APIs, would it be likely to be accepted?  I'm not sure I'm capable of 
producing such a patch, unfortunately, because I've never looked at PIL 
internals, and I've shuddered every time I've looked at libtiff APIs... 
but if it would be considered a useful addition to PIL, perhaps someone 
would, or perhaps someday I would.  I mean, it would certainly be useful 
to me, but there is no point in thinking further along this line if it 
is already known that the any TIFF G4 patch would be rejected because of 
some negative perspective regarding the utility of adding support for G4 
to PIL.


> there are a few other bindings, but none that feels
> complete enough.
>   

I don't understand this remark.  What are the other bindings, and what 
feels incomplete about them?  Were someone to want to follow up, to 
produce a PIL-G4 capability, to see if it would be better to start from 
scratch, or start from one of these bindings, it would be good to better 
understand these "feelings".

> In addition to the solution already posted, you can use "tiffcp -c
> none -r -1 %s %s" % (myfilename, tempfilename) to unpack to a
> temporary file; this is fairly efficient since PIL can then memory map
> the resulting image file.  The tiffcp utility is shipped with libtiff.

This solution seems to produce a way to read TIFF G4 files, but not to 
write them; clearly one could write a temporary TIFF, and then construct 
a tiffcp command to compress it.  But does that then mean shipping 
tiffcp with the application, or depending on its separate installation 
and being able to find it from the application?  If so, that is somewhat 
cumbersome, and error prone.  Also, it adds a requirement for extra disk 
storage, since the compressed files are quite small compared to the 
uncompressed files... I'm not sure I can endorse the "fairly efficient" 
comment, because of the need to write the large uncompressed files to 
disk, if using such a technique.  Of course, for small files (a few 
letter size pages at 300-600 dpi), one at a time, it is not noticeable 
compared to user interaction, but when doing batch processing of book 
files containing hundreds of pages, it is definitely noticeable.

I'm presently using this sort of technique, but only for my own use on 
my own computer, and using ImageMagick which is probably less efficient 
than using tiffcp (but since ImageMagick has a decent Perl API, and I'm 
coming from that background, in Perl I could use ImageMagick APIs rather 
than file manipulations via the command line and the system API).  From 
Python, I should likely convert to using tiffcp for these conversions, 
for a bit of increased performance, but that doesn't solve the 
cumbersome API nor the temporary file issues.

-- 
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking


From lubensch.proletariat.inc at gmail.com  Mon May 25 23:23:03 2009
From: lubensch.proletariat.inc at gmail.com (Chris Ps)
Date: Tue, 26 May 2009 00:23:03 +0300
Subject: [Image-SIG] PIL vs Numpy in raster calculations
Message-ID: <f01b5ba60905251423t33edac7fr7be14e5664a89155@mail.gmail.com>

Hi,
Lately I'm dealing with image statistics with PIL (1.1.6). After I've read
that numpy (1.2.1) is very fast, I've also tried this library to make the
same calculations. I noticed something I would like your opinion about since
I'm not an experienced user.
With a 2000x2000 RGB tif image (~11.0mb) I tried the following with PIL and
numpy:

from numpy import *
from PIL import Image,ImageStat

imga = Image.open("a.tif")
imgar = asarray(imga)

for i in range(1,3):
    stats = ImageStat.Stat(imga)
    stats.mean

for j in range(1,3):
    mean(imgar[:,:,0])
    mean(imgar[:,:,1])
    mean(imgar[:,:,2])

When I timed the for loops I discovered that PIL is about 50 times faster
than numpy!
Since I'm mostly interested in calculating statistics for sub-windows of the
original image I've also tried the same using the crop function from PIL.
This resluted in something like the following:

box = (10,10,20,20)
for i in range(1,1000):
    stats = ImageStat.Stat(imga.crop(box))
    stats.mean

box = imgar[10:21,10:21,:]
for i in range(1,1000):
    mean(box[:,:,0])
    mean(box[:,:,1])
    mean(box[:,:,2])

The thing is that this time numpy was about 10 times faster than PIL!
I figured that the crop function could be slow so I did the initial test,
only this time the image (a.tif) was reduced to 10x10 pixels. In this test
numpy still performed 80 times faster than PIL, so I guess tha crop is
rather fast. The situation changed again when I tried an image 100x100
pixels large. In this test PIL was 2 times faster than numpy.
After all these tests I conclude that the problem is when numpy has to
calculate the stats for large images. Probably mean() copies the image
before calculations take place so this copy action costs considerable time.
On the other hand when you have to deal with small sub-images of an original
large image, then this copy action is fast and the calculations with numpy
are performed extremely fast.
Is this the case? Is something wrong in the above code that I could avoid?
Thank you and sorry for the long post.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090526/fb88594e/attachment.htm>

From Chris.Barker at noaa.gov  Tue May 26 19:54:45 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Tue, 26 May 2009 10:54:45 -0700
Subject: [Image-SIG] PIL vs Numpy in raster calculations
In-Reply-To: <f01b5ba60905251423t33edac7fr7be14e5664a89155@mail.gmail.com>
References: <f01b5ba60905251423t33edac7fr7be14e5664a89155@mail.gmail.com>
Message-ID: <4A1C2CE5.4020905@noaa.gov>

Chris Ps wrote:
> Lately I'm dealing with image statistics with PIL (1.1.6). After I've 
> read that numpy (1.2.1) is very fast, I've also tried this library to 
> make the same calculations.

In general, I'm not sure there's any reason to expect better performance 
from numpy for things that are built in to (and done in C code) in PIL. 
numpy does give you access to more full featured manipulation, though.

Interesting results, just the same.

> After all these tests I conclude that the problem is when numpy has to 
> calculate the stats for large images. Probably mean() copies the image 
> before calculations take place so this copy action costs considerable 
> time.

I don't think mean() copies -- it certainly shouldn't have to.

However, this does:

mean(box[:,:,0])

indexing creates a copy, slicing does not, so you can do:

mean(box[:,:,0:1])

instead. That may be quite a bit faster.

However, numpy is vectorized, so I'd compute all three means at once:

image_array.reshape(-1,3).mean(axis=0)

what that does is reshape (without copying) the array into WxHx3 array, 
then do the mean over each band independently. I think that's about as 
fast as it can get.

For more ideas, try the numpy list.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From ss at konstellation.dk  Tue May 26 20:32:54 2009
From: ss at konstellation.dk (Seph Soliman)
Date: Tue, 26 May 2009 20:32:54 +0200
Subject: [Image-SIG] Bump: Problem with JPEG and CMYK color space
Message-ID: <C6D8CC62-A259-4D10-B89B-F5E99A5FE86C@konstellation.dk>

Hi

Any news on this thread?
http://mail.python.org/pipermail/image-sig/2006-April/003871.html

I am building a site that needs to support uploading of photographic  
material and apparently our client has CMYK images.
The acient PS2 fix seems a bit outdated by now so is there any hope  
for an official fix for this issue?

Best regards
Seph

From fredrik at pythonware.com  Tue May 26 23:14:14 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Tue, 26 May 2009 23:14:14 +0200
Subject: [Image-SIG] Bump: Problem with JPEG and CMYK color space
In-Reply-To: <C6D8CC62-A259-4D10-B89B-F5E99A5FE86C@konstellation.dk>
References: <C6D8CC62-A259-4D10-B89B-F5E99A5FE86C@konstellation.dk>
Message-ID: <368a5cd50905261414x18ea4ebbucbfd25f4a9880c64@mail.gmail.com>

This is fixed in 1.1.7. See the list archives for pointers to the latest
beta.

</F>

On May 26, 2009 11:12 PM, "Seph Soliman" <ss at konstellation.dk> wrote:

Hi

Any news on this thread?
http://mail.python.org/pipermail/image-sig/2006-April/003871.html

I am building a site that needs to support uploading of photographic
material and apparently our client has CMYK images.
The acient PS2 fix seems a bit outdated by now so is there any hope for an
official fix for this issue?

Best regards
Seph
_______________________________________________
Image-SIG maillist  -  Image-SIG at python.org
http://mail.python.org/mailman/listinfo/image-sig
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090526/92f0fbfa/attachment.htm>

From ss at konstellation.dk  Tue May 26 23:53:53 2009
From: ss at konstellation.dk (Seph Soliman)
Date: Tue, 26 May 2009 23:53:53 +0200
Subject: [Image-SIG] Overriding 1.1.6 with 1.1.7 in local dir
Message-ID: <E6C8B391-A8D8-4DC0-944A-409BC95704FB@konstellation.dk>

Would it be possible to compile and run a local version of PIL 1.1.7  
with Django even if 1.1.6 is installed in site-packages in the python  
installation? We're running Django through Apache with mod_python  
currently.

Thank you for the quick response previously on the CMYK issue.

Best regards
Seph


From fredrik at pythonware.com  Wed May 27 10:44:51 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 27 May 2009 10:44:51 +0200
Subject: [Image-SIG] Overriding 1.1.6 with 1.1.7 in local dir
In-Reply-To: <E6C8B391-A8D8-4DC0-944A-409BC95704FB@konstellation.dk>
References: <E6C8B391-A8D8-4DC0-944A-409BC95704FB@konstellation.dk>
Message-ID: <368a5cd50905270144l4ae11b0apcac19ccb54a94b53@mail.gmail.com>

On Tue, May 26, 2009 at 11:53 PM, Seph Soliman <ss at konstellation.dk> wrote:
> Would it be possible to compile and run a local version of PIL 1.1.7 with
> Django even if 1.1.6 is installed in site-packages in the python
> installation? We're running Django through Apache with mod_python currently.

Yes, you can install it locally and then make sure the installation
directory comes before site-packages in sys.path (e.g. by adding it to
PYTHONPATH, or by manipulating sys.path in settings.py).

If you install it in DIR, you may want to add both DIR and DIR/PIL to
the path to make sure that both "import Image" and "from PIL import
Image" works properly (if you always use the latter form, you only
need DIR in the path).

</F>

From fredrik at pythonware.com  Wed May 27 10:47:24 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 27 May 2009 10:47:24 +0200
Subject: [Image-SIG] Bump: Problem with JPEG and CMYK color space
In-Reply-To: <92EFED7C-3B58-4A4A-BDD8-57B345940FCD@konstellation.dk>
References: <C6D8CC62-A259-4D10-B89B-F5E99A5FE86C@konstellation.dk> 
	<368a5cd50905261414x18ea4ebbucbfd25f4a9880c64@mail.gmail.com> 
	<92EFED7C-3B58-4A4A-BDD8-57B345940FCD@konstellation.dk>
Message-ID: <368a5cd50905270147g45a790bbuc30c2a383cfd7748@mail.gmail.com>

On Tue, May 26, 2009 at 11:15 PM, Seph Soliman <ss at konstellation.dk> wrote:
> On 26/05/2009, at 23.14, Fredrik Lundh wrote:
>
> This is fixed in 1.1.7. See the list archives for pointers to the latest
> beta.
>
> Thanks.
> Any plans on a release date?

Any day now.  The latest beta can be considered as a release
candidate, so unless you have a company policy to never push anything
not labelled "final" into production, you can just grab the beta:

    http://effbot.org/zone/motd-20090414.htm

</F>

From seb.haase at gmail.com  Wed May 27 10:52:46 2009
From: seb.haase at gmail.com (Sebastian Haase)
Date: Wed, 27 May 2009 10:52:46 +0200
Subject: [Image-SIG] Will 1.1.7 be true-division safe ?
Message-ID: <bc657ead0905270152o65919587p6928f438e7a8d5a2@mail.gmail.com>

Hi,

short question:  Since I usually like running Python with "python2.5
-Qnew" , I was wondering if patches were applied that substituted '/'
for '//' in some places were it appeared necessary ?

Some places I patches in my 1.1.6 version are:
PIL/GifImagePlugin.py:                if not (chr(i//3) == p[i] ==
p[i+1] == p[i+2]):
PIL/TiffImagePlugin.py:                    count = count // 2        #
adjust for rational data field
PIL/TiffImagePlugin.py:                palette = map(lambda a: chr(a
// 256), self.tag[COLORMAP])
PIL/TiffImagePlugin.py:                palette = map(lambda a: chr(a
// 256), range(256))
PIL/TiffImagePlugin.py:            #palette = map(lambda a: chr(a //
256), self.tag[COLORMAP])
PIL/TiffImagePlugin.py:    stride = len(bits) * ((im.size[0]*bits[0]+7)//8)
PIL/XVThumbImagePlugin.py:            PALETTE = PALETTE +
(chr((r*255)//7)+chr((g*255)//7)+chr((b*255)//3))

(These can of course be found using "python -Qwarn")

Thanks,
Sebastian Haase

From fredrik at pythonware.com  Wed May 27 11:14:25 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Wed, 27 May 2009 11:14:25 +0200
Subject: [Image-SIG] Will 1.1.7 be true-division safe ?
In-Reply-To: <bc657ead0905270152o65919587p6928f438e7a8d5a2@mail.gmail.com>
References: <bc657ead0905270152o65919587p6928f438e7a8d5a2@mail.gmail.com>
Message-ID: <368a5cd50905270214w512d94b6tf0e7bdc21bb3773e@mail.gmail.com>

PIL 1.1.7 works with all Python versions back to 1.5.2, so this won't
ever go into the 1.1.X mainline (and division behaviour won't ever be
changed in the Python 2.X series either, so it doesn't really matter).

</F>

On Wed, May 27, 2009 at 10:52 AM, Sebastian Haase <seb.haase at gmail.com> wrote:
> Hi,
>
> short question: ?Since I usually like running Python with "python2.5
> -Qnew" , I was wondering if patches were applied that substituted '/'
> for '//' in some places were it appeared necessary ?
>
> Some places I patches in my 1.1.6 version are:
> PIL/GifImagePlugin.py: ? ? ? ? ? ? ? ?if not (chr(i//3) == p[i] ==
> p[i+1] == p[i+2]):
> PIL/TiffImagePlugin.py: ? ? ? ? ? ? ? ? ? ?count = count // 2 ? ? ? ?#
> adjust for rational data field
> PIL/TiffImagePlugin.py: ? ? ? ? ? ? ? ?palette = map(lambda a: chr(a
> // 256), self.tag[COLORMAP])
> PIL/TiffImagePlugin.py: ? ? ? ? ? ? ? ?palette = map(lambda a: chr(a
> // 256), range(256))
> PIL/TiffImagePlugin.py: ? ? ? ? ? ?#palette = map(lambda a: chr(a //
> 256), self.tag[COLORMAP])
> PIL/TiffImagePlugin.py: ? ?stride = len(bits) * ((im.size[0]*bits[0]+7)//8)
> PIL/XVThumbImagePlugin.py: ? ? ? ? ? ?PALETTE = PALETTE +
> (chr((r*255)//7)+chr((g*255)//7)+chr((b*255)//3))
>
> (These can of course be found using "python -Qwarn")
>
> Thanks,
> Sebastian Haase
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>

From ss at konstellation.dk  Wed May 27 11:28:15 2009
From: ss at konstellation.dk (Seph Soliman)
Date: Wed, 27 May 2009 11:28:15 +0200
Subject: [Image-SIG] Overriding 1.1.6 with 1.1.7 in local dir
In-Reply-To: <368a5cd50905270144l4ae11b0apcac19ccb54a94b53@mail.gmail.com>
References: <E6C8B391-A8D8-4DC0-944A-409BC95704FB@konstellation.dk>
	<368a5cd50905270144l4ae11b0apcac19ccb54a94b53@mail.gmail.com>
Message-ID: <D17120DB-9B38-4F1A-A641-420264353DC7@konstellation.dk>

On 27/05/2009, at 10:44, Fredrik Lundh wrote:

> On Tue, May 26, 2009 at 11:53 PM, Seph Soliman <ss at konstellation.dk>  
> wrote:
>> Would it be possible to compile and run a local version of PIL  
>> 1.1.7 with
>> Django even if 1.1.6 is installed in site-packages in the python
>> installation? We're running Django through Apache with mod_python  
>> currently.
>
> Yes, you can install it locally and then make sure the installation
> directory comes before site-packages in sys.path (e.g. by adding it to
> PYTHONPATH, or by manipulating sys.path in settings.py).
>
> If you install it in DIR, you may want to add both DIR and DIR/PIL to
> the path to make sure that both "import Image" and "from PIL import
> Image" works properly (if you always use the latter form, you only
> need DIR in the path).
Very thourough answer. I appreciate it, thank you. :-)

Regards
Seph


From geert at nznl.com  Wed May 27 12:14:26 2009
From: geert at nznl.com (Geert Dekkers)
Date: Wed, 27 May 2009 12:14:26 +0200
Subject: [Image-SIG] Python Core Graphics Question
Message-ID: <79CBD871-06F5-4290-9F90-C8A89A61D2D3@nznl.com>

Hi all
Below is a piece of code that I found over in the quartz-dev list.  
I've been using this function unchanged in a batch processor, and it  
appears to leak memory quite substantially. So much so that my test  
machine (1Gb memory) , a mac mini, and my production xserve (2 Gb  
memory) both crashed using it. My dev machine, an imac (4Gb memory)  
slowed, but stayed up.
I think I have the problem down to "croppedimg =  
srcimg.createWithImageInRect(cliprect)". If used with an image of  
suffient size, it quickly sucks up all available memory.
Has anyone experienced similar problems using this method? Its Obj-C  
name is "CGContextCreateWithImageInRect". And I should think that one  
would only see something bad happening in some sort of batch processing.
Incidentally, my workaround was to lower the size of the source image.  
But the process is still quite unstable. It brought down my xserve  
after processing 7000 of the 7600 odd items.
I've pasted the original post below. And sorry for any cross - posting.
Cheers, Geert
----------------------------------------------------------------------------------------------
Geert Dekkers Web Studio | 2e Keucheniusstraat 8HS 1051VR Amsterdam |  
+31(0)627224301 | http://nznl.net
----------------------------------------------------------------------------------------------


>> Thanks for you detailed reply Glen - much appreciated.
>> You helped me to solve what i was trying to do by using  
>> CGImageCreateWithImageinRect as suggested.
>>
>> For anyone else interested here is some simple python code for  
>> making cropped thumbnails of any proportion and not loosing the  
>> aspect ratio of the original image.
>> ...and its damn fast!
>>
>> ----------- #!/usr/bin/python
>>
>> from __future__ import division import CoreGraphics
>>
>> def resizeimage(srcimage,targetimage, tw, th):
>>
>> srcimg =  
>> CoreGraphics 
>>  .CGImageImport 
>> (CoreGraphics.CGDataProviderCreateWithFilename(srcimage))
>>
>> sw = srcimg.getWidth()
>> sh = srcimg.getHeight()
>>
>> aspect = tw/th
>>
>> widthfactor = tw/sw	
>> heightfactor = th/sh
>>
>> if widthfactor < heightfactor:
>> #src height stays the same
>> #src width gets cropped
>> cropwidth = sh * aspect
>> x1 = ((sw-cropwidth)/2)
>> y1 = 0
>> x2 = sw-((sw-cropwidth))
>> y2 = sh
>> else:
>> #src height gets cropped
>> #src width stays the same
>> cropheight = sw / aspect
>> x1 = 0
>> y1 = ((sh-cropheight)/2)
>> x2 = sw
>> y2 = sh-((sh-cropheight))	
>>
>> cliprect = CoreGraphics.CGRectMake(x1, y1, x2, y2)
>> croppedimg = srcimg.createWithImageInRect(cliprect)	
>>
>> cs = CoreGraphics.CGColorSpaceCreateDeviceRGB()
>> c = CoreGraphics.CGBitmapContextCreateWithColor(tw, th, cs,  
>> (0,0,0,0))
>>
>> c.setInterpolationQuality(CoreGraphics.kCGInterpolationLow)
>> newRect = CoreGraphics.CGRectMake(0, 0, tw, th)
>> c.drawImage(newRect, croppedimg)
>> c.writeToFile(targetimage, CoreGraphics.kCGImageFormatJPEG)
>>
>> resizeimage("/users/adam/Desktop/bootlogo4pa8.jpg", "/users/adam/  
>> Desktop/aaaaa.jpg" , 80,80)	
>>
>>
>>
>>
>>
>>
>>
>>> On Aug 12, 2008, at 3:41 AM, Glenn Cole wrote:
>>>
>>> Hi, Adam --
>>>
>>> I'm no expert, but until others more knowledgeable respond, here's  
>>> my understanding.
>>>
>>> First, I suspect the fact that you're using Python won't matter at  
>>> all here. (It does in other circumstances, but I don't think so  
>>> here.)
>>>
>>> It sounds like you're looking for more support from Quartz for  
>>> your task than what's really there. In the end, I think it's going  
>>> to be more a choice of algorithm on your part.
>>>
>>> For example, given different aspect ratios, the new image could  
>>> either:
>>>
>>> 1. ignore the difference (i.e., the current behaviour)
>>> 2. show the entire original image within the new target,  
>>> respecting the aspect ratio
>>> 3. clip the original image to match the new aspect ratio
>>>
>>> For #2, you could shrink the target rect to match the aspect ratio  
>>> of the original image.
>>>
>>> For #3 (your goal), you could clip the original image to match the  
>>> target aspect ratio. However, page 250 of the outstanding  
>>> Programming With Quartz notes a few downsides to this, and  
>>> suggests using CGImageCreateWithImageInRect instead (first  
>>> available in Tiger) to define a "subimage" of the original image.  
>>> Again, though, you would need to determine yourself that the  
>>> subimage should ignore 100 pixels from the left and right sides of  
>>> the original image.
>>>
>>> At least, that's my take on things. We'll see what others say  
>>> (though they've tended to ignore Python questions in the past).
>>>
>>> Incidentally, the subject line says "Core Image resize question."  
>>> The code below has no reference to Core Image, and I'm pretty sure  
>>> that Core Image need not be involved in this task at all. (Perhaps  
>>> you mentioned Core Image because of the existence of its CICrop  
>>> filter, but I think that's not the best direction for the task at  
>>> hand.)
>>>
>>> --Glenn
>>>
>>>
>>> On Aug 11, 2008, at 5:33 AM, Adam Jones wrote:
>>>
>>> Hi there i am wondering if someone can help me with this. Below is  
>>> the code i am using to resize and save a jpeg image.
>>>
>>> It works mint as but it obviously scales the image with no respect  
>>> for the aspect ratio.
>>>
>>> i want to be able to take an image and scale it proportionaly to a  
>>> square thumbnail. so for example a 800x600 image scaled to 80x80  
>>> would need to loose 100pixels off the left and 100 pixels on the  
>>> right before scaling.
>>>
>>> Does any one know how to crop using python quartz or can i draw  
>>> the rec with the image off the canvas to achieve the same?
>>>
>>> Thanks Adam
>>>
>>>
>>> ----------- #!/usr/bin/python
>>>
>>> import CoreGraphics
>>>
>>> def resizeimage(srcimage,targetimage, w, h):
>>>
>>> origImage = CoreGraphics .CGImageImport  
>>> (CoreGraphics.CGDataProviderCreateWithFilename(srcimage))
>>>
>>> origwidth = origImage.getWidth() # not used yet but will be once i  
>>> work out how to crop
>>> origheight = origImage.getHeight() # not used yet but will be once  
>>> i work out how to crop
>>>
>>> cs = CoreGraphics.CGColorSpaceCreateDeviceRGB()
>>> c = CoreGraphics.CGBitmapContextCreateWithColor(w, h, cs, (0,0,0,0))
>>>
>>> c.setInterpolationQuality(CoreGraphics.kCGInterpolationLow)
>>> newRect = CoreGraphics.CGRectMake(0, 0, w, h)
>>> c.drawImage(newRect, origImage)
>>> c.writeToFile(targetimage, CoreGraphics.kCGImageFormatJPEG)
>>>
>>>
>>> resizeimage(uploadedfile, "/svr/data/images/listings/%s/  
>>> %s_160x90.jpg" % (str(listing_id), newimagename), 160,90)
>>>
>>> -------------
>>>
>>>
>>> _______________________________________________ Do not post admin  
>>> requests to the list. They will be ignored. Quartz-dev mailing  
>>> list (email at hidden) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/quartz-dev/email at hidden
>>>
>>> This email sent to email at hidden
>>






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090527/3bdc1b2d/attachment.htm>

From lubensch.proletariat.inc at gmail.com  Wed May 27 17:00:52 2009
From: lubensch.proletariat.inc at gmail.com (cp)
Date: Wed, 27 May 2009 15:00:52 +0000 (UTC)
Subject: [Image-SIG] PIL vs Numpy in raster calculations
References: <f01b5ba60905251423t33edac7fr7be14e5664a89155@mail.gmail.com>
	<4A1C2CE5.4020905@noaa.gov>
Message-ID: <loom.20090527T144804-115@post.gmane.org>

Christopher Barker <Chris.Barker <at> noaa.gov> writes:

> In general, I'm not sure there's any reason to expect better performance 
> from numpy for things that are built in to (and done in C code) in PIL. 
> numpy does give you access to more full featured manipulation, though.

That's right and that's exactly why I tried numpy in the first place.

> Interesting results, just the same.
> For more ideas, try the numpy list.

I will try the code you proposed and post the updated code to the numpy list as
well and see what comes up.

> image_array.reshape(-1,3).mean(axis=0)
> what that does is reshape (without copying) the array into WxHx3 array

I have just one question considering importing the PIL image with asarray.
Suppose my initial image is an RGB image with 1600 pixels height and 1900 width.

>>>img.size
(1900,1600)
>>>arr=asarray(img)
>>>arr.shape
(1600,1900,3)

In numpy syntax I would expect the last one to be (3,1900,1600). Now the
returned array seems to have 1600 layers and not one for each color channel,
leading to the reshape function you propose. Any idea why is that?




From Chris.Barker at noaa.gov  Wed May 27 19:29:16 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Wed, 27 May 2009 10:29:16 -0700
Subject: [Image-SIG] PIL vs Numpy in raster calculations
In-Reply-To: <loom.20090527T144804-115@post.gmane.org>
References: <f01b5ba60905251423t33edac7fr7be14e5664a89155@mail.gmail.com>
	<4A1C2CE5.4020905@noaa.gov> <loom.20090527T144804-115@post.gmane.org>
Message-ID: <4A1D786C.8060000@noaa.gov>

cp wrote:
>> image_array.reshape(-1,3).mean(axis=0)
>> what that does is reshape (without copying) the array into WxHx3 array
> 
> I have just one question considering importing the PIL image with asarray.
> Suppose my initial image is an RGB image with 1600 pixels height and 1900 width.
> 
>>>> img.size
> (1900,1600)
>>>> arr=asarray(img)
>>>> arr.shape
> (1600,1900,3)
> 
> In numpy syntax I would expect the last one to be (3,1900,1600). Now the
> returned array seems to have 1600 layers and not one for each color channel,
> leading to the reshape function you propose. Any idea why is that?

it looks like you've followed up on the lumpy list, but:

I misspoke a bit above:

image_array.reshape(-1,3)

means: "make this a 2-d array, making the first dimension whatever it 
needs to be so that the second dimension is three". In this case, that 
flattens out the width and height, while keeping the color separate, 
which I think is what you wanted -- the mean of each of red, green and blue.

from the reshape doc string:

reshaped_array : disarrays
         This will be a new view object if possible; otherwise, it will
         be a copy.


as your array was created from a PEEL image, it may need to make a copy 
to do this -- I'm not sure.

You might try the slice method I proposed -- if it can prevent a data 
copy, the extra loop may be worth it.

IIUC, PIL and numpy don't share exactly the same data model, so you may 
have to make a memory copy to go from one to the other -- that may the 
source of your performance decrease.

If you really want to know, you could profile the code doing one step at 
a time (not the mean, for instance) to see where the time is going.

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From lubensch.proletariat.inc at gmail.com  Thu May 28 10:36:31 2009
From: lubensch.proletariat.inc at gmail.com (cp)
Date: Thu, 28 May 2009 08:36:31 +0000 (UTC)
Subject: [Image-SIG] PIL vs Numpy in raster calculations
References: <f01b5ba60905251423t33edac7fr7be14e5664a89155@mail.gmail.com>
	<4A1C2CE5.4020905@noaa.gov>
	<loom.20090527T144804-115@post.gmane.org>
	<4A1D786C.8060000@noaa.gov>
Message-ID: <loom.20090528T082106-988@post.gmane.org>

> IIUC, PIL and numpy don't share exactly the same data model, so you may 
> have to make a memory copy to go from one to the other -- that may the 
> source of your performance decrease.
> 
> If you really want to know, you could profile the code doing one step at 
> a time (not the mean, for instance) to see where the time is going.

Following your advice I wrote three different scripts and profiled them.

#Script 1 - indexing
for i in range(10):
    imarr[:,:,0].mean()
    imarr[:,:,1].mean()
    imarr[:,:,2].mean()

#Script 2 - slicing
for i in range(10):
    imarr[:,:,0:1].mean()
    imarr[:,:,1:2].mean()
    imarr[:,:,2:3].mean()

#Script 3 - reshape
for i in range(10):
    imarr.reshape(-1,3).mean(axis=0)

For an RGB image 2000x2000 of ~11mb the times were:
script 1: 5.432sec
script 2: 10.234sec
script 3: 4.980sec

I tried the same without the mean(), but for 1000 loops, and the results were:
script 1: 0.463sec (~6mb of RAM)
script 2: 0.465sec (~3mb of RAM)
script 3: 0.462sec (~2mb of RAM)

Script 3, you proposed, has the best performance, while script 2 is very slow. I
can't make a conclusion, but I'll use the third approach. I'll post my results
back to the numpy list to see if they have an idea. 


From Chris.Barker at noaa.gov  Thu May 28 19:05:29 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Thu, 28 May 2009 10:05:29 -0700
Subject: [Image-SIG] PIL vs Numpy in raster calculations
In-Reply-To: <loom.20090528T082106-988@post.gmane.org>
References: <f01b5ba60905251423t33edac7fr7be14e5664a89155@mail.gmail.com>
	<4A1C2CE5.4020905@noaa.gov> <loom.20090527T144804-115@post.gmane.org>
	<4A1D786C.8060000@noaa.gov> <loom.20090528T082106-988@post.gmane.org>
Message-ID: <4A1EC459.4060201@noaa.gov>

cp wrote:
> Following your advice I wrote three different scripts and profiled them.
> 
> #Script 1 - indexing
> for i in range(10):
>     imarr[:,:,0].mean()
>     imarr[:,:,1].mean()
>     imarr[:,:,2].mean()
> 
> #Script 2 - slicing
> for i in range(10):
>     imarr[:,:,0:1].mean()
>     imarr[:,:,1:2].mean()
>     imarr[:,:,2:3].mean()
> 
> #Script 3 - reshape
> for i in range(10):
>     imarr.reshape(-1,3).mean(axis=0)
> 
> For an RGB image 2000x2000 of ~11mb the times were:
> script 1: 5.432sec
> script 2: 10.234sec
> script 3: 4.980sec
> 
> I tried the same without the mean(), but for 1000 loops, and the results were:
> script 1: 0.463sec (~6mb of RAM)
> script 2: 0.465sec (~3mb of RAM)
> script 3: 0.462sec (~2mb of RAM)
> 
> Script 3, you proposed, has the best performance, while script 2 is very slow.

I think this is because with slicing, the resulting array is 
discontiguous in memory -- this may slow down the mean() computation. 
The fact that all three run at the same speed when not calculating the 
mean supports that concept.

Shows you that you need to profile.

Script 3 is probably as fast as you can get with numpy -- it's probably 
slower than the PIL version because it does need to copy memory one way 
or the other.

-CHB

-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From colorpyen at gmail.com  Thu May 28 22:22:57 2009
From: colorpyen at gmail.com (Peter Yen)
Date: Thu, 28 May 2009 13:22:57 -0700
Subject: [Image-SIG] remove an image background using PIL
Message-ID: <e74b0a060905281322n656db91bna2bed0a57eaf0638@mail.gmail.com>

Hi,

Is there any sample code to use PIL to remove the image background and make
it transparent? Any help and advice is highly appreciated.

-peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090528/bedc85de/attachment.htm>

From colorpyen at gmail.com  Thu May 28 22:53:22 2009
From: colorpyen at gmail.com (Peter Yen)
Date: Thu, 28 May 2009 13:53:22 -0700
Subject: [Image-SIG] remove an image background using PIL
In-Reply-To: <368a5cd50905281343w7da41753u9e18a137963e5d1b@mail.gmail.com>
References: <e74b0a060905281322n656db91bna2bed0a57eaf0638@mail.gmail.com>
	<368a5cd50905281343w7da41753u9e18a137963e5d1b@mail.gmail.com>
Message-ID: <e74b0a060905281353la147723m6d2cec27127b151c@mail.gmail.com>

Hi Fredrik,

Thanks for your quick response. The background is unknown at the time of
processing. Actually I don't need a very accurate methodology to remove all
background, removing partially is good enough.

imagick has method like floodfill, curious how to do that with PIL.

thanks a lot

-peter

On Thu, May 28, 2009 at 1:43 PM, Fredrik Lundh <fredrik at pythonware.com>wrote:

> On Thu, May 28, 2009 at 10:22 PM, Peter Yen <colorpyen at gmail.com> wrote:
>
> > Is there any sample code to use PIL to remove the image background and
> make
> > it transparent? Any help and advice is highly appreciated.
>
> Depends on what the background is.  The further it is from "a single
> known color", the harder it gets.
>
> </F>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/image-sig/attachments/20090528/08490633/attachment.htm>

From fredrik at pythonware.com  Thu May 28 22:43:13 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 28 May 2009 22:43:13 +0200
Subject: [Image-SIG] remove an image background using PIL
In-Reply-To: <e74b0a060905281322n656db91bna2bed0a57eaf0638@mail.gmail.com>
References: <e74b0a060905281322n656db91bna2bed0a57eaf0638@mail.gmail.com>
Message-ID: <368a5cd50905281343w7da41753u9e18a137963e5d1b@mail.gmail.com>

On Thu, May 28, 2009 at 10:22 PM, Peter Yen <colorpyen at gmail.com> wrote:

> Is there any sample code to use PIL to remove the image background and make
> it transparent? Any help and advice is highly appreciated.

Depends on what the background is.  The further it is from "a single
known color", the harder it gets.

</F>

From fredrik at pythonware.com  Thu May 28 22:46:15 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Thu, 28 May 2009 22:46:15 +0200
Subject: [Image-SIG] Will 1.1.7 be true-division safe ?
In-Reply-To: <368a5cd50905270214w512d94b6tf0e7bdc21bb3773e@mail.gmail.com>
References: <bc657ead0905270152o65919587p6928f438e7a8d5a2@mail.gmail.com> 
	<368a5cd50905270214w512d94b6tf0e7bdc21bb3773e@mail.gmail.com>
Message-ID: <368a5cd50905281346o4ba9408eq81146385441bf3b9@mail.gmail.com>

On Wed, May 27, 2009 at 11:14 AM, Fredrik Lundh <fredrik at pythonware.com> wrote:
> PIL 1.1.7 works with all Python versions back to 1.5.2, so this won't
> ever go into the 1.1.X mainline (and division behaviour won't ever be
> changed in the Python 2.X series either, so it doesn't really matter).

To clarify, the above refers to the 1.1.7 main release.  There will be
a version of 1.1.7 available for 3.X later this year, with this fix
and many others...

</F>

From seb.haase at gmail.com  Fri May 29 10:07:19 2009
From: seb.haase at gmail.com (Sebastian Haase)
Date: Fri, 29 May 2009 10:07:19 +0200
Subject: [Image-SIG] Will 1.1.7 be true-division safe ?
In-Reply-To: <368a5cd50905281346o4ba9408eq81146385441bf3b9@mail.gmail.com>
References: <bc657ead0905270152o65919587p6928f438e7a8d5a2@mail.gmail.com> 
	<368a5cd50905270214w512d94b6tf0e7bdc21bb3773e@mail.gmail.com> 
	<368a5cd50905281346o4ba9408eq81146385441bf3b9@mail.gmail.com>
Message-ID: <bc657ead0905290107i168e199as96791e339a1c5626@mail.gmail.com>

On Thu, May 28, 2009 at 10:46 PM, Fredrik Lundh <fredrik at pythonware.com> wrote:
> On Wed, May 27, 2009 at 11:14 AM, Fredrik Lundh <fredrik at pythonware.com> wrote:
>> PIL 1.1.7 works with all Python versions back to 1.5.2, so this won't
>> ever go into the 1.1.X mainline (and division behaviour won't ever be
>> changed in the Python 2.X series either, so it doesn't really matter).
>
> To clarify, the above refers to the 1.1.7 main release. ?There will be
> a version of 1.1.7 available for 3.X later this year, with this fix
> and many others...
>
One more comment :
I was only asking for the use of the '//' operator, which is "at
least" backwards compatible to Python 2.2  -- I don't know the exact
version when it was introduced....
Are you saying that 1.5.2 did not know about it and you "need" to
support those ?

(I'm asking because in the mathematical community using true-division
behavior is quite beneficial, even for Python 2.x )

Regards,

Sebastian Haase

From fredrik at pythonware.com  Fri May 29 11:45:58 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Fri, 29 May 2009 11:45:58 +0200
Subject: [Image-SIG] Will 1.1.7 be true-division safe ?
In-Reply-To: <bc657ead0905290107i168e199as96791e339a1c5626@mail.gmail.com>
References: <bc657ead0905270152o65919587p6928f438e7a8d5a2@mail.gmail.com> 
	<368a5cd50905270214w512d94b6tf0e7bdc21bb3773e@mail.gmail.com> 
	<368a5cd50905281346o4ba9408eq81146385441bf3b9@mail.gmail.com> 
	<bc657ead0905290107i168e199as96791e339a1c5626@mail.gmail.com>
Message-ID: <368a5cd50905290245i4d7ff0c4gba24ddf8437f9620@mail.gmail.com>

On Fri, May 29, 2009 at 10:07 AM, Sebastian Haase <seb.haase at gmail.com> wrote:

> I was only asking for the use of the '//' operator, which is "at
> least" backwards compatible to Python 2.2 ?-- I don't know the exact
> version when it was introduced....
> Are you saying that 1.5.2 did not know about it and you "need" to
> support those ?

Yeah, but what I'm saying is that there's no point changing existing
code that's targeting the 2.x series -- the existing code already
works, a change would break compatibility with versions supported
today, and division is just one of a *huge* list of things that needs
to be changed to get a library like PIL running under 3.X.  And this
is already fixed in the 3.X branch, of course.

> (I'm asking because in the mathematical community using true-division
> behavior is quite beneficial, even for Python 2.x )

"True division" can also be spelled "float(x) / y", and that spelling
works in all Python versions (and is used in plenty of places in PIL).

</F>

From lubensch.proletariat.inc at gmail.com  Fri May 29 17:07:59 2009
From: lubensch.proletariat.inc at gmail.com (cp)
Date: Fri, 29 May 2009 15:07:59 +0000 (UTC)
Subject: [Image-SIG] PIL vs Numpy in raster calculations
References: <f01b5ba60905251423t33edac7fr7be14e5664a89155@mail.gmail.com>
	<4A1C2CE5.4020905@noaa.gov>
	<loom.20090527T144804-115@post.gmane.org>
	<4A1D786C.8060000@noaa.gov>
	<loom.20090528T082106-988@post.gmane.org>
	<4A1EC459.4060201@noaa.gov>
Message-ID: <loom.20090529T143348-373@post.gmane.org>

> Script 3 is probably as fast as you can get with numpy -- it's probably 
> slower than the PIL version because it does need to copy memory one way 
> or the other.

After all this talk and tests I definitely agree with you. This is the only
logical explanation of why numpy is faster than PIL when dealing with small
images, but slower when trying to calculate statistics of large images. 

I also received a message from a user of the numpy list. He suggested that "PIL
stores it's images as pointers-to-rows (or cols), i.e. to access a new row you
need to dereference a pointer. NumPy on the other hand always stores its memory
in blocks. When N grows larger, the N pointer lookups needed in PIL doesn't
matter, but they do for low N".

I couldn't find something that supports this, do you know anything about it?
If it is true, then it might provide an additional explanation for the
phenomenon, although I believe that the impact it should be limited. 
Concluding, I believe that on the basis of speed, the following are important:
Statistics calculations for images larger than 200x200 pixels? Go with PIL
Repeated statistics calculations for images smaller than 200x200 pixels? Go with
numpy. 



From Chris.Barker at noaa.gov  Sat May 30 00:50:07 2009
From: Chris.Barker at noaa.gov (Christopher Barker)
Date: Fri, 29 May 2009 15:50:07 -0700
Subject: [Image-SIG] Will 1.1.7 be true-division safe ?
In-Reply-To: <368a5cd50905290245i4d7ff0c4gba24ddf8437f9620@mail.gmail.com>
References: <bc657ead0905270152o65919587p6928f438e7a8d5a2@mail.gmail.com>
	<368a5cd50905270214w512d94b6tf0e7bdc21bb3773e@mail.gmail.com>
	<368a5cd50905281346o4ba9408eq81146385441bf3b9@mail.gmail.com>
	<bc657ead0905290107i168e199as96791e339a1c5626@mail.gmail.com>
	<368a5cd50905290245i4d7ff0c4gba24ddf8437f9620@mail.gmail.com>
Message-ID: <4A20669F.6070009@noaa.gov>

Fredrik Lundh wrote:
> On Fri, May 29, 2009 at 10:07 AM, Sebastian Haase <seb.haase at gmail.com> wrote:
>> I was only asking for the use of the '//' operator, which is "at
>> least" backwards compatible to Python 2.2

> "True division" can also be spelled "float(x) / y", and that spelling
> works in all Python versions (and is used in plenty of places in PIL).

yes, but he asking for the // operator, which I think is spelled:

math.floor(x / y)

except that that does a float conversion for integer operators.

But if want to support 1.5, then you want to support 1.5.

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

From fredrik at pythonware.com  Sat May 30 02:23:49 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sat, 30 May 2009 02:23:49 +0200
Subject: [Image-SIG] Will 1.1.7 be true-division safe ?
In-Reply-To: <4A20669F.6070009@noaa.gov>
References: <bc657ead0905270152o65919587p6928f438e7a8d5a2@mail.gmail.com> 
	<368a5cd50905270214w512d94b6tf0e7bdc21bb3773e@mail.gmail.com> 
	<368a5cd50905281346o4ba9408eq81146385441bf3b9@mail.gmail.com> 
	<bc657ead0905290107i168e199as96791e339a1c5626@mail.gmail.com> 
	<368a5cd50905290245i4d7ff0c4gba24ddf8437f9620@mail.gmail.com> 
	<4A20669F.6070009@noaa.gov>
Message-ID: <368a5cd50905291723t67539f6ex922be7e9ad6709b3@mail.gmail.com>

On Sat, May 30, 2009 at 12:50 AM, Christopher Barker
<Chris.Barker at noaa.gov> wrote:

>> "True division" can also be spelled "float(x) / y", and that spelling
>> works in all Python versions (and is used in plenty of places in PIL).
>
> yes, but he asking for the // operator, which I think is spelled:
>
> math.floor(x / y)
>
> except that that does a float conversion for integer operators.

Or just plain "/" in the context where it's used in PIL.

I still fail to see what a change would buy anyone, given that there
will *never* be a Python 2.X release that doesn't treat "/" the way
it's treated in today's 2.X.  It's not like you cannot use "//" in
your own code...

(Is the problem here that people think that the -Q option should be
used for anything other than 3.X compatibility testing?  Writing code
for 2.X that depends on -Qnew is not the right thing do to; please use
the "from __future__ import division" module-level pragma instead.)

</F>

From seb.haase at gmail.com  Sat May 30 10:50:24 2009
From: seb.haase at gmail.com (Sebastian Haase)
Date: Sat, 30 May 2009 10:50:24 +0200
Subject: [Image-SIG] Will 1.1.7 be true-division safe ?
In-Reply-To: <368a5cd50905291723t67539f6ex922be7e9ad6709b3@mail.gmail.com>
References: <bc657ead0905270152o65919587p6928f438e7a8d5a2@mail.gmail.com> 
	<368a5cd50905270214w512d94b6tf0e7bdc21bb3773e@mail.gmail.com> 
	<368a5cd50905281346o4ba9408eq81146385441bf3b9@mail.gmail.com> 
	<bc657ead0905290107i168e199as96791e339a1c5626@mail.gmail.com> 
	<368a5cd50905290245i4d7ff0c4gba24ddf8437f9620@mail.gmail.com> 
	<4A20669F.6070009@noaa.gov>
	<368a5cd50905291723t67539f6ex922be7e9ad6709b3@mail.gmail.com>
Message-ID: <bc657ead0905300150s70f1c0dav39b497941dc502d9@mail.gmail.com>

On Sat, May 30, 2009 at 2:23 AM, Fredrik Lundh <fredrik at pythonware.com> wrote:
> On Sat, May 30, 2009 at 12:50 AM, Christopher Barker
> <Chris.Barker at noaa.gov> wrote:
>
>>> "True division" can also be spelled "float(x) / y", and that spelling
>>> works in all Python versions (and is used in plenty of places in PIL).
>>
>> yes, but he asking for the // operator, which I think is spelled:
>>
>> math.floor(x / y)
>>
>> except that that does a float conversion for integer operators.
>
> Or just plain "/" in the context where it's used in PIL.
>
> I still fail to see what a change would buy anyone, given that there
> will *never* be a Python 2.X release that doesn't treat "/" the way
> it's treated in today's 2.X. ?It's not like you cannot use "//" in
> your own code...
>
> (Is the problem here that people think that the -Q option should be
> used for anything other than 3.X compatibility testing? ?Writing code
> for 2.X that depends on -Qnew is not the right thing do to; please use
> the "from __future__ import division" module-level pragma instead.)
>

(referring to the last paragraph:)
You are probably correct.   ((Except using '//' does not *depend* on
-Qnew -- the '//' operator works the same with and without -Q))
However, we use python mostly in an interactive mode - essentially as
a Matlab substitute.
And using -Qnew has worked for this very well for more than a year or so.
At first there were some other third party libraries (like scipy and
sympy) that had trouble with this, but since they don't want to
support Python 1.5 they could apply the '//'-patches.
So after I fixed those 5-10 or so places in PIL 1.1.6 everything
worked -- even with -Qnew.

It would not be hard to do the same with 1.1.7 - only less elegant ...
 (that's why I was asking)


(('//' was introduced with Python 2.2 in Dec 2001,
http://python.org/download/releases/2.2 ))

Regards and thanks for PIL,

Sebastian Haase

From karsten.hiddemann at mathematik.uni-dortmund.de  Sat May 30 15:18:50 2009
From: karsten.hiddemann at mathematik.uni-dortmund.de (Karsten Hiddemann)
Date: Sat, 30 May 2009 15:18:50 +0200
Subject: [Image-SIG] PIL 1.1.7 Image sequences
Message-ID: <4A21323A.6050406@mathematik.uni-dortmund.de>

Hi,

I haven't been watching the list that much over the last months, so I
thought I'd better ask directly:

I'd like to create a plugin for some image container / sequences format
with varying image frame dimensions. An example would be DDS (DirectX8
texture) files, or the already included Mac OS X icns file format. Has
PIL 1.1.7 improved support for this or is it already easily achievable
with the current stable PIL version as well? I'd like to see a code
examples how such a plugin would look like if possible.

Thanks,
Karsten Hiddemann

From fredrik at pythonware.com  Sun May 31 15:32:16 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 31 May 2009 15:32:16 +0200
Subject: [Image-SIG] Will 1.1.7 be true-division safe ?
In-Reply-To: <bc657ead0905300150s70f1c0dav39b497941dc502d9@mail.gmail.com>
References: <bc657ead0905270152o65919587p6928f438e7a8d5a2@mail.gmail.com> 
	<368a5cd50905270214w512d94b6tf0e7bdc21bb3773e@mail.gmail.com> 
	<368a5cd50905281346o4ba9408eq81146385441bf3b9@mail.gmail.com> 
	<bc657ead0905290107i168e199as96791e339a1c5626@mail.gmail.com> 
	<368a5cd50905290245i4d7ff0c4gba24ddf8437f9620@mail.gmail.com> 
	<4A20669F.6070009@noaa.gov>
	<368a5cd50905291723t67539f6ex922be7e9ad6709b3@mail.gmail.com> 
	<bc657ead0905300150s70f1c0dav39b497941dc502d9@mail.gmail.com>
Message-ID: <368a5cd50905310632y5a1e5ckc83c41a7a719db74@mail.gmail.com>

On Sat, May 30, 2009 at 10:50 AM, Sebastian Haase <seb.haase at gmail.com> wrote:
>> (Is the problem here that people think that the -Q option should be
>> used for anything other than 3.X compatibility testing? ?Writing code
>> for 2.X that depends on -Qnew is not the right thing do to; please use
>> the "from __future__ import division" module-level pragma instead.)
>>
> (referring to the last paragraph:)
> You are probably correct. ? ((Except using '//' does not *depend* on
> -Qnew -- the '//' operator works the same with and without -Q))
> However, we use python mostly in an interactive mode - essentially as
> a Matlab substitute.

Oh, sorry, I completely misread your first post - didn't notice that
you mention that you *always* did this.  I'm too old school to like
breaking things just for the sake of it (and I know people who still
use PIL with 1.5.2 and 2.1 in long-running production systems), so I
thought you wanted this more of a "let's get ready for 3.X" reason (or
perhaps even the "oh shiny new core feature must use it" attitude
that's quite common in Python land these days ;-) than anything else.

But I think I'll have to leave this as is in 1.1.7 (which should go RC
later today or tomorrow), but at least I now understand the rationale
for changing it also when targeting 2.X.  (having a benefit != 0
definitely helps when you're doing cost/benefit analysis :-)

Thanks /F

From cannon.el at gmail.com  Fri May 29 17:03:30 2009
From: cannon.el at gmail.com (Laura & Edward Cannon)
Date: Fri, 29 May 2009 08:03:30 -0700
Subject: [Image-SIG] remove an image background using PIL
In-Reply-To: <e74b0a060905281353la147723m6d2cec27127b151c@mail.gmail.com>
References: <e74b0a060905281322n656db91bna2bed0a57eaf0638@mail.gmail.com>
	<368a5cd50905281343w7da41753u9e18a137963e5d1b@mail.gmail.com>
	<e74b0a060905281353la147723m6d2cec27127b151c@mail.gmail.com>
Message-ID: <b986b290905290803s1f162782s8741aa8e7986e88c@mail.gmail.com>

One way to get rid of a single color background is to get the
background color (look at the upper left pixel) and then compare every
pixel to it. If they are the same, make it transparent, otherwise
leave it be. This obviously only works if nothing in the foreground is
colored the same as the background, but I have had good success with
this sort of method in the pygame world for making sprites.

On Thu, May 28, 2009 at 1:53 PM, Peter Yen <colorpyen at gmail.com> wrote:
> Hi Fredrik,
>
> Thanks for your quick response. The background is unknown at the time of
> processing. Actually I don't need a very accurate methodology to remove all
> background, removing partially is good enough.
>
> imagick has method like floodfill, curious how to do that with PIL.
>
> thanks a lot
>
> -peter
>
> On Thu, May 28, 2009 at 1:43 PM, Fredrik Lundh <fredrik at pythonware.com>
> wrote:
>>
>> On Thu, May 28, 2009 at 10:22 PM, Peter Yen <colorpyen at gmail.com> wrote:
>>
>> > Is there any sample code to use PIL to remove the image background and
>> > make
>> > it transparent? Any help and advice is highly appreciated.
>>
>> Depends on what the background is. ?The further it is from "a single
>> known color", the harder it gets.
>>
>> </F>
>
>
> _______________________________________________
> Image-SIG maillist ?- ?Image-SIG at python.org
> http://mail.python.org/mailman/listinfo/image-sig
>
>

From fredrik at pythonware.com  Sun May 31 15:42:56 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 31 May 2009 15:42:56 +0200
Subject: [Image-SIG] PIL 1.1.7 Image sequences
In-Reply-To: <4A21323A.6050406@mathematik.uni-dortmund.de>
References: <4A21323A.6050406@mathematik.uni-dortmund.de>
Message-ID: <368a5cd50905310642j35a99af9q7a0d1f78d7b8231f@mail.gmail.com>

On Sat, May 30, 2009 at 3:18 PM, Karsten Hiddemann
<karsten.hiddemann at mathematik.uni-dortmund.de> wrote:

> I'd like to create a plugin for some image container / sequences format
> with varying image frame dimensions. An example would be DDS (DirectX8
> texture) files, or the already included Mac OS X icns file format. Has
> PIL 1.1.7 improved support for this or is it already easily achievable
> with the current stable PIL version as well? I'd like to see a code
> examples how such a plugin would look like if possible.

There's no formally standardized support for this, beyond the current
seek/tell API.  Some guidelines:

- when opening an image, seek to the "best" image (for some suitable
definition of best)

- to support seeking, implement the "seek" and "tell" methods.  seek
should accept indexes from 0 to N (where N doesn't have to be known in
advance).

- im.seek(im.tell()+1) should be supported if at all possible.

- treating seek index 0 as the "best" image is nice, but not required.

- the seek method should modify the image in place, usually by setting
at least "mode", "size" and the "tile" descriptor (which is used for
lazy loading of the actual raster data).  see e.g. the Dcx, Tiff, and
Im loaders for examples.

- there's no standard API to seek to an image that matches a given
constraint (e.g. most colors, best resolution), so you're free to
invent your own extension API here (e.g. im.seek(im.find(...)))
however, if the image contains multiple versions of the exactly the
same data, you can implement the "draft" method and have it seek to
the right frame.

</F>

From fredrik at pythonware.com  Sun May 31 19:27:53 2009
From: fredrik at pythonware.com (Fredrik Lundh)
Date: Sun, 31 May 2009 19:27:53 +0200
Subject: [Image-SIG] remove an image background using PIL
In-Reply-To: <e74b0a060905281353la147723m6d2cec27127b151c@mail.gmail.com>
References: <e74b0a060905281322n656db91bna2bed0a57eaf0638@mail.gmail.com> 
	<368a5cd50905281343w7da41753u9e18a137963e5d1b@mail.gmail.com> 
	<e74b0a060905281353la147723m6d2cec27127b151c@mail.gmail.com>
Message-ID: <368a5cd50905311027u190f74f6s9eb077b9c684848e@mail.gmail.com>

On Thu, May 28, 2009 at 10:53 PM, Peter Yen <colorpyen at gmail.com> wrote:
> Hi Fredrik,
>
> Thanks for your quick response. The background is unknown at the time of
> processing. Actually I don't need a very accurate methodology to remove all
> background, removing partially is good enough.
>
> imagick has method like floodfill, curious how to do that with PIL.

There's a floodfill function in ImageDraw that might be good enough
for you.  I'm not sure it's documented, but here's the PythonDoc
markup:

##
# (experimental) Fills a bounded region with a given color.
#
# @def floodfill(image, xy, value, border=None)
# @param image Target image.
# @param xy Seed position (a 2-item coordinate tuple).
# @param value Fill color.
# @param border Optional border value.  If given, the region consists of
#     pixels with a color different from the border color.  If not given,
#     the region consists of pixels having the same color as the seed
#     pixel.

It's pure Python, so if you want more complex rules for determining
what's background and not, you can always grab a copy and tweak the
code.

</F>