From matthew.sc.brown at gmail.com Fri Aug 2 04:56:55 2013 From: matthew.sc.brown at gmail.com (Matt Brown) Date: Fri, 02 Aug 2013 02:56:55 -0000 Subject: [Image-SIG] Bug in transform function Message-ID: <51FB1FF3.80405@gmail.com> I noticed that the transform function appears to shift images by a half pixel. I ran an image through the identity transformation and it appears to shift by a half pixel. import numpy as np from PIL import Image P = np.array([[1,0,0],[0,1,0]]) I2 = I.transform((100,100),Image.AFFINE, P, resample=Image.BICUBIC) When I use P = np.array([[1,0,0.5],[0,1,0.5]]), then they are identical. From hiei.arhiva at gmail.com Wed Aug 21 16:00:06 2013 From: hiei.arhiva at gmail.com (ha) Date: Wed, 21 Aug 2013 16:00:06 +0200 Subject: [Image-SIG] possible bug in OpenCV python module (cv2) In-Reply-To: References: Message-ID: When I run: img = uint8([[0,255,255,0],[0,255,255,0],[0,255,255,0],[0,255,255,0]]) aaa,bbb = cv2.findContours(img,cv2.RETR_TREE,cv2.CHAIN_APPROX_SIMPLE) img I get the following output: array([[ 0, 0, 0, 0], [ 0, 2, 130, 0], [ 0, 2, 130, 0], [ 0, 0, 0, 0]], dtype=uint8) This does not seem to me as the expected behavior, as the input image has changed. Should this be treated as a bug? What's your experience with cv2 module? Is this the right place to discuss such problems? From chris.barker at noaa.gov Wed Aug 21 18:14:45 2013 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Wed, 21 Aug 2013 09:14:45 -0700 Subject: [Image-SIG] possible bug in OpenCV python module (cv2) In-Reply-To: References: Message-ID: On Wed, Aug 21, 2013 at 7:00 AM, ha wrote: > Is this the right place to discuss such problems? not really -- this list os for more general image processing tools with Pyton, mostly the PIL. There must be an OpenCV list somewhere. If not, I'd try the scipy list, I expect there are users on there. -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 bill at iheartengineering.com Sun Aug 11 17:36:26 2013 From: bill at iheartengineering.com (Bil Morris) Date: Sun, 11 Aug 2013 11:36:26 -0400 Subject: [Image-SIG] Debian patch for PIL-1.1.7 Message-ID: <5207AF7A.3050101@iheartengineering.com> Add "common" library directory to setup.py add_directory(library_dirs, "/usr/lib/x86_64-linux-gnu") From gdesoto at adinet.com.uy Mon Aug 12 20:31:05 2013 From: gdesoto at adinet.com.uy (Gonzalo ADINET) Date: Mon, 12 Aug 2013 15:31:05 -0300 Subject: [Image-SIG] A simple query about image handling in Python 3.3 Message-ID: <000001ce978a$1c167d40$544377c0$@com.uy> Dear members of the group Image-SIG, Relatively recently I'm using Python (3.3.0) and I have some simple questions regarding the handling of images. When looking at the documentation, I found that several of the documents explaining about pictures are related to earlier versions of Python and do not work in 3.3. As an example of a simple case, I did not find a way to put an image instead of text in a menu option, so I would appreciate any suggestions to do so. And take the opportunity to ask if PIL library is available for versions 3.X Thank you very much and greetings. Francisco -------------- next part -------------- An HTML attachment was scrubbed... URL: From harry at daiw.de Tue Aug 13 18:38:54 2013 From: harry at daiw.de (Tobias Hermann) Date: Tue, 13 Aug 2013 18:38:54 +0200 Subject: [Image-SIG] Identity transformation translates image Message-ID: <520A611E.4010004@daiw.de> While transforming images with PIL (1.1.7, Portable Python 2.7.5.1, Windows 7) I stumbled upon a behaviour I find quite strange. When transforming an image with an identity matrix (1,0,0,0,1,0,0) I expect the resulting image to be the exact input (as when using OpenCV). With filter=Image.NEAREST that holds true but not for Image.BILINEAR or Image.BICUBIC. The image is translated to the bottom right. import Image import ImageDraw im = Image.new('L', (64, 64), 0) draw = ImageDraw.Draw(im) draw.line((8,8, 32,8), fill=255) draw.line((8,8, 8,32), fill=255) im.save('out1.png') im = im.transform((64, 64), Image.AFFINE, (1,0,0,0,1,0), Image.BICUBIC) im.save('out2.png') im = im.transform((64, 64), Image.AFFINE, (1,0,0,0,1,0), Image.BICUBIC) im.save('out3.png') im = im.transform((64, 64), Image.AFFINE, (1,0,0,0,1,0), Image.BICUBIC) im.save('out4.png') [1]: http://i.stack.imgur.com/1gktU.png [2]: http://i.stack.imgur.com/gxePy.png [3]: http://i.stack.imgur.com/kSYm1.png [4]: http://i.stack.imgur.com/YhgGf.png Is this intended (I was unable to find something about this in the docs.) or a bug? From edward at unicornschool.org Sun Aug 18 22:09:50 2013 From: edward at unicornschool.org (Edward Cannon) Date: Sun, 18 Aug 2013 13:09:50 -0700 Subject: [Image-SIG] [bug report] OverflowError: signed integer is greater than maximum In-Reply-To: References: Message-ID: have you tried to use the built in save function instead of the save_image function? It would look like img.save( '/tmp/1889935.jpg') you don't need to specify the file type or other parameters as long as the file has an appropriate extension. PS if you are just moving the image around and not changing it at all the shutil.copy() function from the standard libraries is much faster and lossless. On Thu, Jul 25, 2013 at 8:20 AM, Julien Palard wrote: > I jiust reproduced the bug with another image that I can publicly release, > so you may easily reproduce it : > > http://mandark.fr/art/art/2011/01/16/2011-01-16-14-54-22.jpg > > > On Thu, Jul 25, 2013 at 5:11 PM, Julien Palard wrote: > >> Hi there, I'm facing a bug in PIL, from the stable Debian Package, don't >> know the PIL exact version number as it's not exposed by the package but I >> got : >> >> apt-cache policy python-imaging >> python-imaging: >> Installed: 1.1.7-4 >> >> Here come the bug : >> >> $ python >> Python 2.7.3 (default, Jan 2 2013, 13:56:14) >> [GCC 4.7.2] on linux2 >> Type "help", "copyright", "credits" or "license" for more information. >> >>> from PIL import Image as PILImage >> >>> from pilkit.utils import save_image >> >>> >> >>> img = PILImage.open('./1889935.jpg') >> >>> save_image(img, '/tmp/1889935.jpg', 'JPEG', {}, True) >> Traceback (most recent call last): >> File "", line 1, in >> File >> "/usr/local/lib/python2.7/dist-packages/pilkit-1.0.0-py2.7.egg/pilkit/utils.py", >> line 175, in save_image >> img.save(outfile, format, **options) >> File "/usr/lib/python2.7/dist-packages/PIL/Image.py", line 1439, in save >> save_handler(self, fp, filename) >> File "/usr/lib/python2.7/dist-packages/PIL/JpegImagePlugin.py", line >> 471, in _save >> ImageFile._save(im, fp, [("jpeg", (0,0)+im.size, 0, rawmode)]) >> File "/usr/lib/python2.7/dist-packages/PIL/ImageFile.py", line 499, in >> _save >> s = e.encode_to_file(fh, bufsize) >> OverflowError: signed integer is greater than maximum >> >> How I may help ? >> >> -- >> Julien Palard - http://julien.palard.fr >> IRC : mandark at freenode.net, mandark at quakenet.org >> TEL : 06.21.19.49.10 / FAX : 09.72.28.06.72 >> > > > > -- > Julien Palard - http://julien.palard.fr > IRC : mandark at freenode.net, mandark at quakenet.org > TEL : 06.21.19.49.10 / FAX : 09.72.28.06.72 > > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at soroos.net Tue Aug 20 07:16:52 2013 From: eric at soroos.net (Eric Soroos) Date: Mon, 19 Aug 2013 22:16:52 -0700 Subject: [Image-SIG] Corruption writing PNG data In-Reply-To: <51F263B3.9050104@pml.ac.uk> References: <51F263B3.9050104@pml.ac.uk> Message-ID: <5212FBC4.5040402@soroos.net> Hi Ben. (mirrored to the list, who knows when it'll get delivered) I'm a maintainer for Pillow, an actively maintained successor for PIL that has some bugfixes and new features. I've taken a quick look, and it appears that the bug is in Pillow as well. It appears that at some point, once the file gets over about 23 mp, or at 8285x2780, there's a failure. It works at 8284x2780, and also if the subselected region is panned. I've traced it down to the calls to zlib -- Pillow/Pil is calling it to compress the png formatted scanlines, and somewhere in there (but not at the end of the image) the compressed datastream is getting corrupted. However, there is a small workaround that appears to help. If a compress_level is passed into the save call, requesting anything from 0 (no compression) to 9 (max), it saves properly. Passing in -1 (the default compression level, equivalent to 6) triggers the failure. I've been testing it with the following: (if maxblock is big enough, you get all of the image data in one IDAT block, and we can test the decompression of it with the plain zlib decompression call. It's commented out here.) from PIL import Image, ImageFile import zlib npz = numpy.load("data.npz") imagedata = npz['arr_0'] palette = npz['arr_1'] Image.DEBUG = 1 #ImageFile.MAXBLOCK = 512*1024 print(imagedata.shape) def test(p): i1 = imagedata[0:2780,0:p] im = Image.fromarray(i1, 'P') im.putpalette(palette) print (im) im.save('tmp.png',compress_level=9 ) im2 = Image.open('tmp.png') print (im2) print ("Verify: %s" %im2.verify()) try: im2 = Image.open('tmp.png') ImageFile.LOAD_TRUNCATED_IMAGES im2.load() print ("%s success" %p) except: print ("FAIL: %s" %p) #raise #with open('tmp.png','rb') as f: # f.seek(821)# # s = zlib.decompress(f.read(385128)) # print ("successful decompress") test(8284) test(8285) The error I'm getting: "zlib.error: Error -3 while decompressing data: invalid distances set" would indicate that the compressed data stream is either corrupt or was compressed with different settings, perhaps a larger compression window. I'm hoping to find the actual bug here, rather than a vague workaround. eric On 07/26/2013 04:55 AM, Ben Taylor wrote: > Hi all > > I've got some data that should be fine (came from a known-good netCDF > file) but causes PIL to write an invalid image if it is used to save in > PNG format (it's happy writing GIF format). > > The same code writes PNGs quite happily 99% of the time, but just > occasionally we generate a netCDF that causes this bug - we don't know > why. We're not sure if the problem is actually in PIL or if it might be > in libpng. Anyone mind taking a look please? > > Test data at ftp://rsg.pml.ac.uk/rsg/benj/pil_problem/: > data.npz - Numpy npz data with data that causes the issue > working_data.npz - npz file from another source that works fine > test_harness.py - Run this with the two test files to demonstrate the > problem - the PNG generated from data.npz is corrupt. > > Test harness code below (just to demonstrate it's nothing complicated). > > TIA > Ben > > #!/usr/bin/env python > > import numpy > import Image > > def test(infile, prefix): > > npz = numpy.load(infile) > imagedata = npz['arr_0'] > palette = npz['arr_1'] > > out_image = Image.fromarray(imagedata, 'P') > out_image.putpalette(palette) > > out_image.save(prefix + ".gif") # ok > out_image.save(prefix + ".png") # bust > # end function > > test("data.npz", "broken") > test("working_data.npz", "working") > From benj at pml.ac.uk Tue Aug 20 11:13:41 2013 From: benj at pml.ac.uk (Ben Taylor) Date: Tue, 20 Aug 2013 10:13:41 +0100 Subject: [Image-SIG] Corruption writing PNG data In-Reply-To: <5212FBC4.5040402@soroos.net> References: <51F263B3.9050104@pml.ac.uk> <5212FBC4.5040402@soroos.net> Message-ID: <52133345.1060003@pml.ac.uk> Hi Eric (again CC list) Thanks very much for looking into this, I appreciate it! One of my colleagues mentioned Pillow to me when I brought this up here originally (we're currently running Fedora 17, I gather later versions use Pillow instead of PIL so at some point soon we'll migrate I'd imagine, but we'll need to change our codebase a bit). I've tried your test code but the workaround doesn't work for me - no setting of compress_level gives me a working PNG. Version 1.1.7 doesn't support compress_level for PNG images that I can see (not in the handbook for 1.1.6 nor in the PngImagePlugin source for 1.1.7), so I suspect it's silently ignoring the compress_level anyway - I don't know if you're running a tweaked version of PIL. I'm not au-fait enough with PIL, zlib or PNG images to try and hack that in myself! I'm out of the office for a few days after today, so I'll respond next week if you find anything. Thanks again! Cheers Ben On 20/08/13 06:16, Eric Soroos wrote: > Hi Ben. > > (mirrored to the list, who knows when it'll get delivered) > > I'm a maintainer for Pillow, an actively maintained successor for PIL > that has some bugfixes and new features. > I've taken a quick look, and it appears that the bug is in Pillow as well. > > It appears that at some point, once the file gets over about 23 mp, or > at 8285x2780, there's a failure. It works at 8284x2780, and also if the > subselected region is panned. I've traced it down to the calls to zlib > -- Pillow/Pil is calling it to compress the png formatted scanlines, and > somewhere in there (but not at the end of the image) the compressed > datastream is getting corrupted. > > However, there is a small workaround that appears to help. If a > compress_level is passed into the save call, requesting anything from 0 > (no compression) to 9 (max), it saves properly. Passing in -1 (the > default compression level, equivalent to 6) triggers the failure. > > I've been testing it with the following: > (if maxblock is big enough, you get all of the image data in one IDAT > block, and we can test the decompression of it with the plain zlib > decompression call. It's commented out here.) > > > from PIL import Image, ImageFile > import zlib > > npz = numpy.load("data.npz") > imagedata = npz['arr_0'] > palette = npz['arr_1'] > > Image.DEBUG = 1 > #ImageFile.MAXBLOCK = 512*1024 > > print(imagedata.shape) > > def test(p): > i1 = imagedata[0:2780,0:p] > im = Image.fromarray(i1, 'P') > im.putpalette(palette) > print (im) > im.save('tmp.png',compress_level=9 ) > im2 = Image.open('tmp.png') > print (im2) > print ("Verify: %s" %im2.verify()) > try: > im2 = Image.open('tmp.png') > ImageFile.LOAD_TRUNCATED_IMAGES > im2.load() > print ("%s success" %p) > except: > print ("FAIL: %s" %p) > #raise > > #with open('tmp.png','rb') as f: > # f.seek(821)# > > # s = zlib.decompress(f.read(385128)) > # print ("successful decompress") > > > test(8284) > test(8285) > > The error I'm getting: "zlib.error: Error -3 while decompressing data: > invalid distances set" would indicate that the compressed data stream is > either corrupt or was compressed with different settings, perhaps a > larger compression window. > > I'm hoping to find the actual bug here, rather than a vague workaround. > > eric > > > On 07/26/2013 04:55 AM, Ben Taylor wrote: >> Hi all >> >> I've got some data that should be fine (came from a known-good netCDF >> file) but causes PIL to write an invalid image if it is used to save in >> PNG format (it's happy writing GIF format). >> >> The same code writes PNGs quite happily 99% of the time, but just >> occasionally we generate a netCDF that causes this bug - we don't know >> why. We're not sure if the problem is actually in PIL or if it might be >> in libpng. Anyone mind taking a look please? >> >> Test data at ftp://rsg.pml.ac.uk/rsg/benj/pil_problem/: >> data.npz - Numpy npz data with data that causes the issue >> working_data.npz - npz file from another source that works fine >> test_harness.py - Run this with the two test files to demonstrate the >> problem - the PNG generated from data.npz is corrupt. >> >> Test harness code below (just to demonstrate it's nothing complicated). >> >> TIA >> Ben >> >> #!/usr/bin/env python >> >> import numpy >> import Image >> >> def test(infile, prefix): >> >> npz = numpy.load(infile) >> imagedata = npz['arr_0'] >> palette = npz['arr_1'] >> >> out_image = Image.fromarray(imagedata, 'P') >> out_image.putpalette(palette) >> >> out_image.save(prefix + ".gif") # ok >> out_image.save(prefix + ".png") # bust >> # end function >> >> test("data.npz", "broken") >> test("working_data.npz", "working") >> > -- Ben Taylor , http://rsg.pml.ac.uk/ Remote Sensing Group, Plymouth Marine Laboratory Tel: +44 (0)1752 633432, Fax: +44 (0)1752 633101 Latest news: www.pml.ac.uk and @PlymouthMarine Plymouth Marine Laboratory (PML) is a company limited by guarantee registered in England & Wales, company number 4178503. Registered Charity No. 1091222. Registered Office: Prospect Place, The Hoe, Plymouth PL1 3DH, UK. This message is private and confidential. If you have received this message in error, please notify the sender and remove it from your system. You are reminded that e-mail communications are not secure and may contain viruses; PML accepts no liability for any loss or damage which may be caused by viruses. From andrew.mark at is.mpg.de Fri Aug 23 10:05:04 2013 From: andrew.mark at is.mpg.de (Andrew Mark) Date: Fri, 23 Aug 2013 10:05:04 +0200 Subject: [Image-SIG] Problems with polygon drawing Message-ID: <991920AC-156E-495A-A47A-DF320A210256@is.mpg.de> I'd like to use PIL to rasterise a polygon, but I'm having trouble getting even a simple test to work. I expect the following to produce a 11x11 array with a white diamond on a black background, but I only get the background. diamond = array([[5,0], [10,5], [5,10], [0,5]]) img = Image.new('L', (11,11), 0) draw = ImageDraw.Draw(img) draw.polygon(diamond, fill=1, outline=1) array(img) array([[0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]], dtype=uint8) The method draw.line() works as it should. What am I doing wrong? Thanks, -AM From smolds at orcasoul.com Mon Aug 26 08:38:26 2013 From: smolds at orcasoul.com (Stephen M. Olds) Date: Mon, 26 Aug 2013 06:38:26 -0000 Subject: [Image-SIG] Image.py cannot identify existing jpg file Message-ID: <521AF6E7.8010604@orcasoul.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iibeeiic.png Type: image/png Size: 7008 bytes Desc: not available URL: From anthony.mouraud at gmail.com Thu Aug 29 23:16:50 2013 From: anthony.mouraud at gmail.com (Anthony Mouraud) Date: Thu, 29 Aug 2013 21:16:50 -0000 Subject: [Image-SIG] PIL crashes windows 7 (blue screen) Message-ID: Hi, I recently began to use PIL as an image grabber for some python project and I am facing a critical bug. The process consists in regularly grabbing some part of the screen and look for some known pattern. Grabbing seems to work great for a while, but after some time, the process comes to a crash. It first indicates "GRAB failed" for something like 1-2seconds in the terminal from which I am launching my python script and then I have a nice "blue screen" crash of my windows7. Please, tell me about any bug that could lead to such a problem. The problem is reproductible. The delay before crashing can range from some minutes to a couple of hours considering something like one grab / second in average. If this appears to be an unsolved problem, I'll be forced to grab with some other tool. Thanks in advance for your answer. Regards. Anthony PS: I am running python 2.7.5 and PIL 1.1.7 on a 64bits windows7 pro. -------------- next part -------------- An HTML attachment was scrubbed... URL: