From brian at fluggo.com Mon Oct 8 16:04:04 2012 From: brian at fluggo.com (Brian Crowell) Date: Mon, 8 Oct 2012 09:04:04 -0500 Subject: [Image-SIG] Adding Python 3 support Message-ID: Hi. I'm interested in helping bring PIL to Python 3. I contacted Matthias Klose, the package maintainer for PIL, to see which codebase he thought would be best to do that on, and he pointed me to Pillow, so I'm here to ask about what's been done so far for Python 3 support and what I could do. I noticed there was a patch series porting PIL 1.1.6 to Py3k about four years ago at https://github.com/sloonz/pil-py3k. Barring anything else, it seemed like the best plan would be to port that patch series forward to Pillow, since the hardest thing about the conversion will be the bytes vs. str division, and that patch series claims to have worked out a lot of the kinks. The key question seems to be: What's the earliest version of Python you would want to support afterwards? Supporting earlier than 2.6 isn't so hard in the C code, but might be difficult in the Python code. Let me know your thoughts on this, and if anyone's beaten me to working on this. --Brian From nakagami at gmail.com Tue Oct 9 01:56:30 2012 From: nakagami at gmail.com (Hajime Nakagami) Date: Tue, 9 Oct 2012 08:56:30 +0900 Subject: [Image-SIG] Adding Python 3 support In-Reply-To: References: Message-ID: Hi Brian, and all I'm trying to suport python3.3 and python2.7 by one source https://github.com/nakagami/Pillow (please checkout py33py27 branch) It seems to work at gif, jpeg and png. But other many image format still not work. That's most import bug(?) is only support Python2.7 and Python3.3 If you need widely version support, Probabry use 2to3 approach. thanks 2012/10/8 Brian Crowell : > Hi. I'm interested in helping bring PIL to Python 3. > > I contacted Matthias Klose, the package maintainer for PIL, to see > which codebase he thought would be best to do that on, and he pointed > me to Pillow, so I'm here to ask about what's been done so far for > Python 3 support and what I could do. > > I noticed there was a patch series porting PIL 1.1.6 to Py3k about > four years ago at https://github.com/sloonz/pil-py3k. Barring anything > else, it seemed like the best plan would be to port that patch series > forward to Pillow, since the hardest thing about the conversion will > be the bytes vs. str division, and that patch series claims to have > worked out a lot of the kinks. > > The key question seems to be: What's the earliest version of Python > you would want to support afterwards? Supporting earlier than 2.6 > isn't so hard in the C code, but might be difficult in the Python > code. > > Let me know your thoughts on this, and if anyone's beaten me to working on this. > > --Brian > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig From cgohlke at uci.edu Tue Oct 9 02:07:02 2012 From: cgohlke at uci.edu (Christoph Gohlke) Date: Mon, 08 Oct 2012 17:07:02 -0700 Subject: [Image-SIG] Adding Python 3 support In-Reply-To: References: Message-ID: <50736AA6.3080503@uci.edu> On 10/8/2012 4:56 PM, Hajime Nakagami wrote: > Hi Brian, and all > > I'm trying to suport python3.3 and python2.7 by one source > > https://github.com/nakagami/Pillow > (please checkout py33py27 branch) > > It seems to work at gif, jpeg and png. But other many image format > still not work. > That's most import bug(?) is only support Python2.7 and Python3.3 > > If you need widely version support, Probabry use 2to3 approach. > > thanks > > > 2012/10/8 Brian Crowell : >> Hi. I'm interested in helping bring PIL to Python 3. >> >> I contacted Matthias Klose, the package maintainer for PIL, to see >> which codebase he thought would be best to do that on, and he pointed >> me to Pillow, so I'm here to ask about what's been done so far for >> Python 3 support and what I could do. >> >> I noticed there was a patch series porting PIL 1.1.6 to Py3k about >> four years ago at https://github.com/sloonz/pil-py3k. Barring anything >> else, it seemed like the best plan would be to port that patch series >> forward to Pillow, since the hardest thing about the conversion will >> be the bytes vs. str division, and that patch series claims to have >> worked out a lot of the kinks. >> >> The key question seems to be: What's the earliest version of Python >> you would want to support afterwards? Supporting earlier than 2.6 >> isn't so hard in the C code, but might be difficult in the Python >> code. >> >> Let me know your thoughts on this, and if anyone's beaten me to working on this. >> >> --Brian See also . Christoph From brian at fluggo.com Tue Oct 9 06:51:00 2012 From: brian at fluggo.com (Brian Crowell) Date: Mon, 8 Oct 2012 23:51:00 -0500 Subject: [Image-SIG] Adding Python 3 support In-Reply-To: References: Message-ID: On Mon, Oct 8, 2012 at 6:56 PM, Hajime Nakagami wrote: > That's most import bug(?) is only support Python2.7 and Python3.3 > > If you need widely version support, Probabry use 2to3 approach. Yes, that seems to me to be the main trouble. Anything done to the Python source will break compatibility with code before 2.6. I'm sure that's why it looks like PIL has been ported to Python 3 several times, but none of them stuck. How do other developers feel about that? Maybe letting old PIL 1.1.7 take care of anyone using 2.5/2.6 or older, and focusing on 2.6/2.7 and up? Or perhaps maintaining a separate branch with Python 3 code? --Brian From charlie.clark at clark-consulting.eu Tue Oct 9 19:28:45 2012 From: charlie.clark at clark-consulting.eu (Charlie Clark) Date: Tue, 09 Oct 2012 19:28:45 +0200 Subject: [Image-SIG] Adding Python 3 support In-Reply-To: References:

Message-ID: Am 09.10.2012, 06:51 Uhr, schrieb Brian Crowell : > How do other developers feel about that? Maybe letting old PIL 1.1.7 > take care of anyone using 2.5/2.6 or older, and focusing on 2.6/2.7 > and up? Or perhaps maintaining a separate branch with Python 3 code? 2.6 tends to have fairly good support not least because it's still in the Debian stable packages. So if possible it should still be supported. I'd certainly cut anything less than 2.6 loose from any updates. PIL is one of those libraries that is used almost everywhere so not going to 3 is a probably a blocker for lots of different people. Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Kronenstr. 27a D?sseldorf D- 40217 Tel: +49-211-600-3657 Mobile: +49-178-782-6226 From virtue at rocketmonkeys.com Tue Oct 9 19:58:32 2012 From: virtue at rocketmonkeys.com (James) Date: Tue, 9 Oct 2012 13:58:32 -0400 Subject: [Image-SIG] Adding Python 3 support In-Reply-To: References:

Message-ID: I'm not a dev, just a user. Adding my 2 cents. I'd say having 1.1.7 around for Python 2.5 seems sufficient. 2.5 is old, 1.1.7 is stable, it should fit most use cases there. I'd much rather drop 2.5 support and gain 3.x for PIL. Keeping 2.6 support would be a very good thing. Even though 2.6 is old, it's still very useful (and actively used many places, like system Python installs, etc). -James From sienkiew at stsci.edu Tue Oct 9 20:41:03 2012 From: sienkiew at stsci.edu (Mark Sienkiewicz) Date: Tue, 9 Oct 2012 14:41:03 -0400 Subject: [Image-SIG] Adding Python 3 support In-Reply-To: References:

Message-ID: <50746FBF.4010102@stsci.edu> On 10/09/12 00:51, Brian Crowell wrote: > Yes, that seems to me to be the main trouble. Anything done to the > Python source will break compatibility with code before 2.6. I'm sure > that's why it looks like PIL has been ported to Python 3 several > times, but none of them stuck. > > How do other developers feel about that? Maybe letting old PIL 1.1.7 > take care of anyone using 2.5/2.6 or older, and focusing on 2.6/2.7 > and up? Or perhaps maintaining a separate branch with Python 3 code? > I don't think support for older versions is necessarily that important. One thing I do here is support Python software for the Hubble Space Telescope. It means I get a lot of support tickets from astronomers at other institutions. These are people who are not interested in programming, except for the minimum they need to get their job done. They want to use whatever python they have, and if I tell them to upgrade 20 different things they are not happy. I haven't seen a support ticket from any python 2.5 users for a long time now. There are still some linux distributions that use python 2.6. I don't think those distributions are looking for a replacement for PIL. So, I think python 2.6 is relatively unimportant and python 2.5 support is a serious "don't care" at this point. If you were to support python 3 only, you would not make any difference to python 2 users. They would continue to use the latest PIL that was released about 3 years ago. There would just be a python 3 version available. Python 3 has two major problems: 1) it is incompatible with python 2, and 2) too many packaged don't exist for that. If you make a contribution to solving #2, that is a net improvement. The question, then is python 2.7. The problem you have is not technical. It is marketing. Do you propose to try to replace PIL with your derivative package? If so, you have to get people to know about it. For example, Pillow (a fork of PIL) is almost 2 years old, but I just found out about it a few months ago. So, how do you get people to know about and use your package? - promote it - I can't use it if I don't know about it. (b.t.w. One way to promote your package: If you fix problems that people frequently have with PIL, then you can announce it on mailing lists, forums, stackoverflow, etc. It is not spam if you are saying "I know a package that fixes your problem".) - include support for python 2.7 (and maybe 2.6 if it is easy). If I can use it in my python 2.7 environment, then it is not "just some thing that I don't care about because I don't use python 3". Make your package attractive, and I can have just one package for both my existing python 2.7 environment and my prototype python 3 environment. Someday, when I might want python 3, I will remember your package. - add new capabilities and fix old bugs, so that I have some reason to switch to your package even though I already have PIL installed. For example, I did not find gamma correction in the latest PIL; if you have one, maybe your package is more interesting to me. - but remain plug-compatible with the old PIL, so everything just works - be willing to support the package in the long term; if you make a python 3 port and then abandon it, it is just another of thousands of abandoned packages. Maybe you can make an alliance with all those other people who tried python 3 ports. They've done at least some of the work, and you could work together to promote whatever you collectively come up with. But don't let forming the alliance be an obstacle to doing anything. If you spend all your time arguing, you gain nothing. Also, if you spend all your time saying "I don't know - what do YOU think?" you also don't get anywhere. Mark S. From brian at fluggo.com Tue Oct 9 22:02:25 2012 From: brian at fluggo.com (Brian Crowell) Date: Tue, 9 Oct 2012 15:02:25 -0500 Subject: [Image-SIG] Adding Python 3 support In-Reply-To: <50746FBF.4010102@stsci.edu> References:

<50746FBF.4010102@stsci.edu> Message-ID: On Tue, Oct 9, 2012 at 1:41 PM, Mark Sienkiewicz wrote: > So, how do you get people to know about and use your package? Well, that's why I asked the Debian package maintainer first. He pointed me here. He wasn't exactly clear, but he seemed interested in Pillow as the source of a Python 3 port specifically because it's under active development. He didn't sound interested in a replacement for PIL under Python 2. If we can make it attractive to Debian as the official Python 3 version of PIL, I think that's a big step forward. >From what I'm hearing, it seems to me the sensible plan is to combine the previous Python 3 ports (counting Hajime's, that's three I've found) on top of current Pillow, and drop support for Python 2.5 and older. I'll get started. --Brian From sienkiew at stsci.edu Tue Oct 9 22:11:31 2012 From: sienkiew at stsci.edu (Mark Sienkiewicz) Date: Tue, 9 Oct 2012 16:11:31 -0400 Subject: [Image-SIG] Adding Python 3 support In-Reply-To: References:

<50746FBF.4010102@stsci.edu> Message-ID: <507484F3.8060905@stsci.edu> On 10/09/12 16:02, Brian Crowell wrote: > On Tue, Oct 9, 2012 at 1:41 PM, Mark Sienkiewicz wrote: >> So, how do you get people to know about and use your package? > Well, that's why I asked the Debian package maintainer first. He > pointed me here. He wasn't exactly clear, but he seemed interested in > Pillow as the source of a Python 3 port specifically because it's > under active development. He didn't sound interested in a replacement > for PIL under Python 2. If we can make it attractive to Debian as the > official Python 3 version of PIL, I think that's a big step forward. That would be extremely helpful, especially if the package is identified as "PIL replacement for Python 3" or some such, so that people looking for PIL can find it. > From what I'm hearing, it seems to me the sensible plan is to combine > the previous Python 3 ports (counting Hajime's, that's three I've > found) on top of current Pillow, and drop support for Python 2.5 and > older. I'll get started. From what I read of Pillow, they aren't really interested in maintaining a copy of PIL. Do you mean to fork Pillow, or try to persuade them to let you help maintain it? From brian at fluggo.com Tue Oct 9 22:26:37 2012 From: brian at fluggo.com (Brian Crowell) Date: Tue, 9 Oct 2012 15:26:37 -0500 Subject: [Image-SIG] Adding Python 3 support In-Reply-To: <507484F3.8060905@stsci.edu> References:

<50746FBF.4010102@stsci.edu> <507484F3.8060905@stsci.edu> Message-ID: On Tue, Oct 9, 2012 at 3:11 PM, Mark Sienkiewicz wrote: > From what I read of Pillow, they aren't really interested in maintaining a > copy of PIL. Do you mean to fork Pillow, or try to persuade them to let you > help maintain it? I want to contribute code that would make Pillow Python 3-capable so that Debian/Ubuntu might pick it up, and Python 3 developers would finally have their PIL back. I gathered from the notes that Pillow was a continuation of PIL as a fork, and since it's active, I expect it will be more attractive to the distros than a straight port of PIL 1.1.7. I hoped to hear from Alex Clark. He looks like the main contributor. --Brian From aclark at aclark.net Wed Oct 10 18:00:40 2012 From: aclark at aclark.net (Alex Clark) Date: Wed, 10 Oct 2012 12:00:40 -0400 Subject: [Image-SIG] Adding Python 3 support References:

<50746FBF.4010102@stsci.edu> <507484F3.8060905@stsci.edu> Message-ID: On 2012-10-10 16:00:40 +0000, Alex Clark said: > On 2012-10-09 20:26:37 +0000, Brian Crowell said: > >> On Tue, Oct 9, 2012 at 3:11 PM, Mark Sienkiewicz wrote: >>> From what I read of Pillow, they aren't really interested in maintaining a >>> copy of PIL. Do you mean to fork Pillow, or try to persuade them to let you >>> help maintain it? >> >> I want to contribute code that would make Pillow Python 3-capable so >> that Debian/Ubuntu might pick it up, and Python 3 developers would >> finally have their PIL back. I gathered from the notes that Pillow was >> a continuation of PIL as a fork, and since it's active, I expect it >> will be more attractive to the distros than a straight port of PIL >> 1.1.7. >> >> I hoped to hear from Alex Clark. He looks like the main contributor. > > > Test. Just wrote a long message and it hasn't made it through yet. Grrr? And? I can't find my sent messages in Unison. Here's a recap of the highlights: - I spoke with Felix Schwarz from the Fedora project about including Pillow in Fedora. So from what I read earlier in this thread about Debian, that means we potentially have two Linux vendors contemplating inclusion of Pillow now? - Pillow started as a packaging fork, but I now consider image code fixes if they are tracked upstream (by ticket or commit). - I've been considering adding Python 3 support to Pillow. I'm not going to do the work, but I will help whoever does. I assume that involves picking the an approach from the "best of" attempts. Python 2.7 and 3.3 support sounds reasonable to me. If someone wants Python 2.6 they can use an older Pillow release or PIL itself. We may even back port to the older releases. Alex > > >> >> --Brian >> _______________________________________________ >> Image-SIG maillist - Image-SIG at python.org >> http://mail.python.org/mailman/listinfo/image-sig -- Alex Clark ? https://www.gittip.com/aclark4life/ From sienkiew at stsci.edu Wed Oct 10 21:31:35 2012 From: sienkiew at stsci.edu (Mark Sienkiewicz) Date: Wed, 10 Oct 2012 15:31:35 -0400 Subject: [Image-SIG] Adding Python 3 support In-Reply-To: References:

<50746FBF.4010102@stsci.edu> <507484F3.8060905@stsci.edu> Message-ID: <5075CD17.1090303@stsci.edu> On 10/10/12 15:07, Alex Clark wrote: > > - Pillow started as a packaging fork, but I now consider image code fixes if they are tracked upstream (by ticket or commit). Does that mean you are looking for a ticket filed against the old PIL for each of the python 3 modifications? If not, how does this policy interact with the python 3 support? From gwidion at mpc.com.br Thu Oct 11 01:00:07 2012 From: gwidion at mpc.com.br (Joao S. O. Bueno) Date: Wed, 10 Oct 2012 20:00:07 -0300 Subject: [Image-SIG] Adding Python 3 support In-Reply-To: References:

<50746FBF.4010102@stsci.edu> <507484F3.8060905@stsci.edu> Message-ID: Within the Plone comunity, Pillow has been the "de facto" flavour of PIL for several months now. The fact it behaves as expected with package management (easy_install, PIL), is vital for large web projects which are based on buildout and expect Python projects to install properly. Plone itself is not going Python 3 anytime soon - but it is a strong comunity making use of Pillow, and I found this information relevant on the context here. js -><- On 10 October 2012 16:07, Alex Clark wrote: > On 2012-10-10 16:00:40 +0000, Alex Clark said: > >> On 2012-10-09 20:26:37 +0000, Brian Crowell said: >> >>> On Tue, Oct 9, 2012 at 3:11 PM, Mark Sienkiewicz >>> wrote: >>>> >>>> From what I read of Pillow, they aren't really interested in maintaining >>>> a >>>> copy of PIL. Do you mean to fork Pillow, or try to persuade them to let >>>> you >>>> help maintain it? >>> >>> >>> I want to contribute code that would make Pillow Python 3-capable so >>> that Debian/Ubuntu might pick it up, and Python 3 developers would >>> finally have their PIL back. I gathered from the notes that Pillow was >>> a continuation of PIL as a fork, and since it's active, I expect it >>> will be more attractive to the distros than a straight port of PIL >>> 1.1.7. >>> >>> I hoped to hear from Alex Clark. He looks like the main contributor. >> >> >> >> Test. Just wrote a long message and it hasn't made it through yet. Grrr? > > > > And? I can't find my sent messages in Unison. Here's a recap of the > highlights: > > > - I spoke with Felix Schwarz from the Fedora project about including Pillow > in Fedora. So from what I read earlier in this thread about Debian, that > means we potentially have two Linux vendors contemplating inclusion of > Pillow now? > > - Pillow started as a packaging fork, but I now consider image code fixes if > they are tracked upstream (by ticket or commit). > > - I've been considering adding Python 3 support to Pillow. I'm not going to > do the work, but I will help whoever does. I assume that involves picking > the an approach from the "best of" attempts. Python 2.7 and 3.3 support > sounds reasonable to me. If someone wants Python 2.6 they can use an older > Pillow release or PIL itself. We may even back port to the older releases. > > > Alex > > > > > >> >> >>> >>> --Brian >>> _______________________________________________ From aclark at aclark.net Thu Oct 11 03:07:52 2012 From: aclark at aclark.net (Alex Clark) Date: Wed, 10 Oct 2012 21:07:52 -0400 Subject: [Image-SIG] Adding Python 3 support References:

<50746FBF.4010102@stsci.edu> <507484F3.8060905@stsci.edu> <5075CD17.1090303@stsci.edu> Message-ID: On Wed, Oct 10, 2012 at 8:07 PM, Alex Clark wrote: > No. But maybe a single "Python 3 support" ticket in the relevant branch > (https://bitbucket.org/effbot/pil-2009-raclette). IIUC, PIL has some Python > support added. One possible scenario is that we take that code and release > it. Do you consider Raclette your upstream? Also, I'm reading through the Python 3 patches on there. Lundh seemed to expect to be able to support much older versions of Python, which really wouldn't have worked when he hit the Python source. I'm going to go with a cleaner approach. Essentially all I'm going to do is update the Python source to where it meets Py3 syntax and library requirements, get the extension modules to build under both Py2 and Py3, then futz with the bytes/str division using the three existing ports as a guide. After that, all we should need is solid testing. --Brian From aclark at aclark.net Thu Oct 11 05:12:12 2012 From: aclark at aclark.net (Alex Clark) Date: Wed, 10 Oct 2012 23:12:12 -0400 Subject: [Image-SIG] Adding Python 3 support References:

<50746FBF.4010102@stsci.edu> <507484F3.8060905@stsci.edu> <5075CD17.1090303@stsci.edu> Message-ID: On 2012-10-11 02:57:07 +0000, Brian Crowell said: > On Wed, Oct 10, 2012 at 8:07 PM, Alex Clark wrote: >> No. But maybe a single "Python 3 support" ticket in the relevant branch >> (https://bitbucket.org/effbot/pil-2009-raclette). IIUC, PIL has some Python >> support added. One possible scenario is that we take that code and release >> it. > > Do you consider Raclette your upstream? Also, I'm reading through the > Python 3 patches on there. Yes. IIUC that's where there the latest PIL work is/was taking place. > Lundh seemed to expect to be able to > support much older versions of Python, which really wouldn't have > worked when he hit the Python source. I'm going to go with a cleaner > approach. > > Essentially all I'm going to do is update the Python source to where > it meets Py3 syntax and library requirements, get the extension > modules to build under both Py2 and Py3, then futz with the bytes/str > division using the three existing ports as a guide. After that, all we > should need is solid testing. +1. This would be the time for others to weigh in I guess. Is this what folks generally want to see from PIL/Pillow wrt to Python 3 support? > > --Brian > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig -- Alex Clark ? https://www.gittip.com/aclark4life/ From sienkiew at stsci.edu Thu Oct 11 16:30:14 2012 From: sienkiew at stsci.edu (Mark Sienkiewicz) Date: Thu, 11 Oct 2012 10:30:14 -0400 Subject: [Image-SIG] Adding Python 3 support In-Reply-To: References:

<50746FBF.4010102@stsci.edu> <507484F3.8060905@stsci.edu> <5075CD17.1090303@stsci.edu> Message-ID: <5076D7F6.4090808@stsci.edu> On 10/10/12 23:12, Alex Clark wrote: > On 2012-10-11 02:57:07 +0000, Brian Crowell said: > >> On Wed, Oct 10, 2012 at 8:07 PM, Alex Clark wrote: >>> No. But maybe a single "Python 3 support" ticket in the relevant branch >>> (https://bitbucket.org/effbot/pil-2009-raclette). IIUC, PIL has some Python >>> support added. One possible scenario is that we take that code and release >>> it. >> >> Do you consider Raclette your upstream? Also, I'm reading through the >> Python 3 patches on there. > > Yes. IIUC that's where there the latest PIL work is/was taking place. The last commit I see there is 2011-06-28, which is quite some time ago. Have you confirmed with Fredrik Lundh that PIL is still under active development? Do you have an agreement with him about how Pillow and PIL will interact? I presume that Pillow is a fork because he is unable or unwilling to apply the patches that you need and make a release. There are various good reasons that can happen, but for our purposes, it is only important that it _has_ happened. I expect a Python 3 port to be a big change. The more changes you make, the harder it will be to bring in patches from the old code base. I can see wanting to track the original PIL, but it is common for a free software project eventually reach a state where the original author is no longer able to continue developing it. If that has happened to PIL, then we have some questions to consider: Is it time for a new maintainer for PIL? Is it time for Pillow and PIL to go their separate ways? Is it time to find a way to merge the two projects? I don't have any answers, but it seems to me that those are relevant questions. > >> >> Essentially all I'm going to do is update the Python source to where >> it meets Py3 syntax and library requirements, get the extension >> modules to build under both Py2 and Py3, then futz with the bytes/str >> division using the three existing ports as a guide. After that, all we should need is solid testing. >>> Lundh seemed to expect to be able to >>> support much older versions of Python, which really wouldn't have >>> worked when he hit the Python source. I'm going to go with a cleaner >>> approach. >> > > > > +1. This would be the time for others to weigh in I guess. Is this what folks generally want to see from PIL/Pillow wrt to Python 3 support? +1. I have no reason to expect we will get Python 3 support any other way. I mentioned before that I am not concerned with compatibility with very old Python versions (I already have PIL for those systems), so a simple and clean port looks like the way to go. Mark S. From aclark at aclark.net Thu Oct 11 22:03:20 2012 From: aclark at aclark.net (Alex Clark) Date: Thu, 11 Oct 2012 16:03:20 -0400 Subject: [Image-SIG] Adding Python 3 support References:

<50746FBF.4010102@stsci.edu> <507484F3.8060905@stsci.edu> <5075CD17.1090303@stsci.edu> <5076D7F6.4090808@stsci.edu> Message-ID: On 2012-10-11 14:30:14 +0000, Mark Sienkiewicz said: > On 10/10/12 23:12, Alex Clark wrote: >> On 2012-10-11 02:57:07 +0000, Brian Crowell said: >> >>> On Wed, Oct 10, 2012 at 8:07 PM, Alex Clark wrote: >>>> No. But maybe a single "Python 3 support" ticket in the relevant branch >>>> (https://bitbucket.org/effbot/pil-2009-raclette). IIUC, PIL has some Python >>>> support added. One possible scenario is that we take that code and release >>>> it. >>> >>> Do you consider Raclette your upstream? Also, I'm reading through the >>> Python 3 patches on there. >> >> Yes. IIUC that's where there the latest PIL work is/was taking place. > > > The last commit I see there is 2011-06-28, which is quite some time > ago. Have you confirmed with Fredrik Lundh that PIL is still under > active development? Do you have an agreement with him about how Pillow > and PIL will interact? > > I presume that Pillow is a fork because he is unable or unwilling to > apply the patches that you need and make a release. There are various > good reasons that can happen, but for our purposes, it is only > important that it _has_ happened. > > I expect a Python 3 port to be a big change. The more changes you > make, the harder it will be to bring in patches from the old code base. > I can see wanting to track the original PIL, but it is common for a > free software project eventually reach a state where the original > author is no longer able to continue developing it. > > If that has happened to PIL, then we have some questions to consider: > Is it time for a new maintainer for PIL? Is it time for Pillow and PIL > to go their separate ways? Is it time to find a way to merge the two > projects? > > I don't have any answers, but it seems to me that those are relevant questions. Sure, and most if not all of these questions have been discussed on this list in the past (see: http://mail.python.org/pipermail/image-sig/). I'll give a brief recap: - Re: PIL development. No idea what's going on. I assume it's dead or moving very slow. And yes, Pillow is a fork. Fredrik has commented on Pillow on this list, but I don't have the archive link handy. It was something to the effect "I'm glad someone is doing something besides complaining". - Re: Changing away from PIL. Pillow is "the friendly PIL fork" so we will always try to do what is best for both projects (including tracking issues between projects, etc). But Pillow is first and foremost: practical. Adding Python 3 support is a practical matter whose time has come. If this change causes Pillow to drift further from PIL, then so be it. Pillow *is* PIL, so I don't think it matters that much. People will gravitate (as they have already) toward what works and what is well maintained. Should Pillow become PIL? No idea. Probably not yet, if ever. Maybe after Python 3 compat is added, but even then it's not going to be something I will push for or be too interested in (not to say I wouldn't consider it, if that should become necessary). Alex > > >> >>> >>> Essentially all I'm going to do is update the Python source to where >>> it meets Py3 syntax and library requirements, get the extension >>> modules to build under both Py2 and Py3, then futz with the bytes/str >>> division using the three existing ports as a guide. After that, all we >>> should need is solid testing. >>>> Lundh seemed to expect to be able to >>>> support much older versions of Python, which really wouldn't have >>>> worked when he hit the Python source. I'm going to go with a cleaner >>>> approach. >>> >> >> >> >> +1. This would be the time for others to weigh in I guess. Is this what >> folks generally want to see from PIL/Pillow wrt to Python 3 support? > > > +1. I have no reason to expect we will get Python 3 support any other > way. I mentioned before that I am not concerned with compatibility > with very old Python versions (I already have PIL for those systems), > so a simple and clean port looks like the way to go. > > Mark S. > > > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig -- Alex Clark ? https://www.gittip.com/aclark4life/ From brian at fluggo.com Sun Oct 14 05:56:05 2012 From: brian at fluggo.com (Brian Crowell) Date: Sat, 13 Oct 2012 22:56:05 -0500 Subject: [Image-SIG] rehash_collide, strict aliasing, and pointer sizes Message-ID: I'm trying to iron out some of the strict-aliasing warnings that come up when building the code under Python 3. (Strict aliasing is a C rule against using the same pointer as two different types, which, when followed, gives the optimizer a huge advantage. This didn't come up under Python 2, because Python 2 code couldn't be built with strict aliasing on, so it becomes an issue in Python 3 code where strict aliasing is on by default.) I came across this strange function in Quant.c: static void rehash_collide(HashTable h, void **keyp, void **valp, void *newkey, void *newval) { *valp=(void *)((*(int *)valp)+(*(int *)&newval)); } This function sets off red flags in my brain. It's essentially casting two void pointers to ints to add them and then cast them back. Now, the strict-aliasing-safe version is not hard to write: static void rehash_collide(HashTable h, void **keyp, void **valp, void *newkey, void *newval) { union { void *ptr; int val; } uresult, uvalp = { *valp }, unewval = { newval }; uresult.val = uvalp.val + unewval.val; *valp = uresult.ptr; } ...but the fact that it equates the sizes of ints and void pointers worries me. Is there a good reason this function isn't written: static void rehash_collide(HashTable h, void **keyp, void **valp, void *newkey, void *newval) { *valp=(void *)(((size_t) *valp) + ((size_t) newval)); } ...? --Brian From brian at fluggo.com Sun Oct 14 06:03:28 2012 From: brian at fluggo.com (Brian Crowell) Date: Sat, 13 Oct 2012 23:03:28 -0500 Subject: [Image-SIG] rehash_collide, strict aliasing, and pointer sizes In-Reply-To: References: Message-ID: On Sat, Oct 13, 2012 at 10:56 PM, Brian Crowell wrote: > union { > void *ptr; > int val; > } uresult, uvalp = { *valp }, unewval = { newval }; ...and just after I send that, it occurs to me that the code could just be trying to store an int in the space reserved for a void pointer. In that case, I'll go with this: *valp = (void *)(((int) *valp) + ((int) newval)); ...and later see if that produces warnings on a 64-bit machine. --Brian From brian at fluggo.com Sun Oct 21 18:41:46 2012 From: brian at fluggo.com (Brian Crowell) Date: Sun, 21 Oct 2012 11:41:46 -0500 Subject: [Image-SIG] Python 3 port -- first pass finished Message-ID: I completed my first pass at a Python 2.6/3.2 port. You can find it at: https://github.com/fluggo/Pillow Please check it out and test it. This port is largely based on previous ports by Christoph Gohlke and Hajime Nakagami. You can find both ports in my git tree as single commits for comparison. With a project this big and complicated, there will be hidden bugs. I've tested this with Christoph Gohlke's test suite (included) which runs 79 of 82 tests successfully on Python 2.6.8, 2.7.3rc3, and 3.2.3 (the versions of Python found in debian-testing). You should expect zero regressions using this library in Python 2.6 or 2.7, with one exception: Image text, such as comments and tags, is now decoded with a specific character encoding, so the same text might appear differently. In Python 3, image comments and tags are now decoded to Unicode strings. == IF YOU WANT TO HELP == Check this code out, build it, and test it. The documentation tests haven't been updated to work in Python 3, but you can use Gohlke's tests by running: python Tests/run.py python3 -bb Tests/run.py The -bb switch stops the test if there are invalid bytes/str comparisons. Individual tests can be run from the Pillow root like this: PYTHONPATH=. python Tests/test_imagefont.py PYTHONPATH=. python3 -bb Tests/test_imagefont.py *Skipped tests:* Three of Gohlke's tests don't run on my laptop. I haven't bothered to find out why. Investigate the test_imagegl, test_imagegrab, and test_imageqt tests. *Windows build:* I haven't attempted a Windows build or any tests there. For all I know, the GDI code might not even compile. == CHANGES TO LOOK OUT FOR == Your Python 2.6/2.7 code should run with no changes. (If you have to change your code, I've got a bug, so please tell me.) You should, however, start to change all tostring/fromstring calls to tobytes/frombytes. tobytes() and frombytes() are declared in both Python 2 and Python 3, but tostring() and fromstring() are only aliased on Python 2. In Python 3, all image data is represented in bytes objects, not str. str is now Unicode, so binary data doesn't belong there. For more information on the changes, please read my comments in the patch series. Feedback is welcome and much appreciated. --Brian From aclark at aclark.net Sun Oct 21 22:54:35 2012 From: aclark at aclark.net (Alex Clark) Date: Sun, 21 Oct 2012 16:54:35 -0400 Subject: [Image-SIG] Python 3 port -- first pass finished References: Message-ID: On 2012-10-21 16:41:46 +0000, Brian Crowell said: > I completed my first pass at a Python 2.6/3.2 port. You can find it at: > > https://github.com/fluggo/Pillow > > Please check it out and test it. > > This port is largely based on previous ports by Christoph Gohlke and > Hajime Nakagami. You can find both ports in my git tree as single > commits for comparison. > > With a project this big and complicated, there will be hidden bugs. > I've tested this with Christoph Gohlke's test suite (included) which > runs 79 of 82 tests successfully on Python 2.6.8, 2.7.3rc3, and 3.2.3 > (the versions of Python found in debian-testing). > > You should expect zero regressions using this library in Python 2.6 or > 2.7, with one exception: Image text, such as comments and tags, is now > decoded with a specific character encoding, so the same text might > appear differently. In Python 3, image comments and tags are now > decoded to Unicode strings. > > == IF YOU WANT TO HELP == > > Check this code out, build it, and test it. The documentation tests > haven't been updated to work in Python 3, but you can use Gohlke's > tests by running: > > python Tests/run.py > python3 -bb Tests/run.py > > The -bb switch stops the test if there are invalid bytes/str > comparisons. Individual tests can be run from the Pillow root like > this: > > PYTHONPATH=. python Tests/test_imagefont.py > PYTHONPATH=. python3 -bb Tests/test_imagefont.py > > *Skipped tests:* Three of Gohlke's tests don't run on my laptop. I > haven't bothered to find out why. Investigate the test_imagegl, > test_imagegrab, and test_imageqt tests. > > *Windows build:* I haven't attempted a Windows build or any tests > there. For all I know, the GDI code might not even compile. > > == CHANGES TO LOOK OUT FOR == > > Your Python 2.6/2.7 code should run with no changes. (If you have to > change your code, I've got a bug, so please tell me.) > > You should, however, start to change all tostring/fromstring calls to > tobytes/frombytes. tobytes() and frombytes() are declared in both > Python 2 and Python 3, but tostring() and fromstring() are only > aliased on Python 2. > > In Python 3, all image data is represented in bytes objects, not str. > str is now Unicode, so binary data doesn't belong there. > > For more information on the changes, please read my comments in the > patch series. > > Feedback is welcome and much appreciated. You rock! I'm planning to do another PIllow release this month and will try to find some time to test this. > > --Brian > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig -- Alex Clark ? https://www.gittip.com/aclark4life/ From brian at fluggo.com Thu Oct 25 03:19:32 2012 From: brian at fluggo.com (Brian Crowell) Date: Wed, 24 Oct 2012 20:19:32 -0500 Subject: [Image-SIG] Python 3 port -- first pass finished In-Reply-To: References: Message-ID: On Sun, Oct 21, 2012 at 3:54 PM, Alex Clark wrote: > You rock! I'm planning to do another PIllow release this month and will try > to find some time to test this. The more I look at it, the more areas I'm seeing that Gohlke's tests don't cover. There are a lot of image plugins that aren't exercised. I'm adding patches as I write more tests and fix more plugins. --Brian From cgohlke at uci.edu Thu Oct 25 03:34:29 2012 From: cgohlke at uci.edu (Christoph Gohlke) Date: Wed, 24 Oct 2012 18:34:29 -0700 Subject: [Image-SIG] Python 3 port -- first pass finished In-Reply-To: References: Message-ID: <50889725.1080207@uci.edu> On 10/24/2012 6:19 PM, Brian Crowell wrote: > On Sun, Oct 21, 2012 at 3:54 PM, Alex Clark wrote: >> You rock! I'm planning to do another PIllow release this month and will try >> to find some time to test this. > > The more I look at it, the more areas I'm seeing that Gohlke's tests FWIW, those are the official PIL tests from adjusted to Python 3. Christoph > don't cover. There are a lot of image plugins that aren't exercised. > I'm adding patches as I write more tests and fix more plugins. > From aclark at aclark.net Thu Oct 25 03:37:35 2012 From: aclark at aclark.net (Alex Clark) Date: Wed, 24 Oct 2012 21:37:35 -0400 Subject: [Image-SIG] Python 3 port -- first pass finished References: Message-ID: On 2012-10-25 01:19:32 +0000, Brian Crowell said: > On Sun, Oct 21, 2012 at 3:54 PM, Alex Clark wrote: >> You rock! I'm planning to do another PIllow release this month and will try >> to find some time to test this. > > The more I look at it, the more areas I'm seeing that Gohlke's tests > don't cover. There are a lot of image plugins that aren't exercised. > I'm adding patches as I write more tests and fix more plugins. Can we run a coverage report? IIRC nose makes that easier, but I don't recall if anyone's added it to Pillow yet. > > --Brian > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig -- Alex Clark ? https://www.gittip.com/aclark4life/ From brian at fluggo.com Thu Oct 25 15:13:07 2012 From: brian at fluggo.com (Brian Crowell) Date: Thu, 25 Oct 2012 08:13:07 -0500 Subject: [Image-SIG] Python 3 port -- first pass finished In-Reply-To: <50889725.1080207@uci.edu> References: <50889725.1080207@uci.edu> Message-ID: On Wed, Oct 24, 2012 at 8:34 PM, Christoph Gohlke wrote: > FWIW, those are the official PIL tests from > adjusted to Python 3. Hello! I had just assumed that Pillow included raclette, or that you had worked straight off PIL 1.1.7, and so the tests had to be yours. My bad. Your work has been a very useful guide during this process. --Brian From brian at fluggo.com Thu Oct 25 17:31:43 2012 From: brian at fluggo.com (Brian Crowell) Date: Thu, 25 Oct 2012 10:31:43 -0500 Subject: [Image-SIG] Python 3 port -- first pass finished In-Reply-To: References: Message-ID: On Wed, Oct 24, 2012 at 8:37 PM, Alex Clark wrote: > Can we run a coverage report? IIRC nose makes that easier, but I don't > recall if anyone's added it to Pillow yet. The test runner *looks* like it includes support for this module: http://pypi.python.org/pypi/coverage You would pass "--coverage" to run.py or the individual tests. Haven't tried it yet. --Brian From lars.ruoff at gmail.com Mon Oct 29 16:05:28 2012 From: lars.ruoff at gmail.com (Lars Ruoff) Date: Mon, 29 Oct 2012 16:05:28 +0100 Subject: [Image-SIG] PIL: Unexpected results with Image.paste on RGBA images with transparency. Message-ID: Hi, I'm new to this list, so excuse me if this is a known issue. I didn't find anything on it on the net so far but didn't have time to search much. I have observed what i consider a flaw in the Image.paste algorithm when used with transparent images. transparent-columns.png is an image with 3 vertical black columns with alpha=0.5, 0.2 and transparent respectively. transparent-bars.png is an image with 2 horizontal black bars with transparent and alpha=0.5 respectively. (images attached) When these two images are transparently pasted one over the other, using the following code: from PIL import Image source = Image.open('transparent-columns.png') result = Image.open('transparent-bars.png') result.paste(source, (0, 0), source) result.save('transparent-columns-on-bars-pil.png') The result is unexpectet to say the least. PIL seems to modify the transparency even in regions where only one of the images has non-transparent values. Very wrong in my opinion. Doing the same manipulation in GIMP 2.6 gives what i consider the expected result. (attached for reference) I guess the per-pixel transparency of the result should be result_alpha = 1 - (1-alpha1)*(1-alpha2), where alpha1,alpha2 are the alpha channel values from the original images. Regards, Lars Ruoff -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: transparent-bars.png Type: image/png Size: 315 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: transparent-columns.png Type: image/png Size: 383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: transparent-columns-on-bars-gimp-2.6.png Type: image/png Size: 401 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: transparent-columns-on-bars-gimp-2.6-with-white-background.png Type: image/png Size: 406 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: transparent-columns-on-bars-pil.png Type: image/png Size: 390 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: transparent-columns-on-bars-pil-with-white-background.png Type: image/png Size: 363 bytes Desc: not available URL: From aclark at aclark.net Mon Oct 29 16:33:11 2012 From: aclark at aclark.net (Alex Clark) Date: Mon, 29 Oct 2012 11:33:11 -0400 Subject: [Image-SIG] PIL: Unexpected results with Image.paste on RGBA images with transparency. References: Message-ID: On 2012-10-29 15:05:28 +0000, Lars Ruoff said: > Hi, > > I'm new to this list, so excuse me if this is a known issue. > I didn't find anything on it on the net so far but didn't have time to > search much. > > I have observed what i consider a flaw in the Image.paste algorithm > when used with transparent images. > > transparent-columns.png is an image with 3 vertical black columns with > alpha=0.5, 0.2 and transparent respectively. > transparent-bars.png is an image with 2 horizontal black bars with > transparent and alpha=0.5 respectively. > (images attached) > > When these two images are transparently pasted one over the other, > using the following code: > > from PIL import Image > source = Image.open('transparent-columns.png') > result = Image.open('transparent-bars.png') > result.paste(source, (0, 0), source) > result.save('transparent-columns-on-bars-pil.png') > > The result is unexpectet to say the least. > PIL seems to modify the transparency even in regions where only one of > the images has non-transparent values. > Very wrong in my opinion. > > Doing the same manipulation in GIMP 2.6 gives what i consider the > expected result. > (attached for reference) > > I guess the per-pixel transparency of the result should be result_alpha > = 1 - (1-alpha1)*(1-alpha2), > where alpha1,alpha2 are the alpha channel values from the original images. You are welcome to submit a patch to Pillow (the "friendly" PIL fork) here: - https://github.com/python-imaging/Pillow Speaking of that, can anyone review: - https://github.com/python-imaging/Pillow Also, I'm looking for a few folks willing to "stand up" and regularly review image code fixes. I know nothing about that code, and plan to stick with being the release manager only. I'll be doing a 1.7.8 release soon (by the end of this month) then maybe Pillow 1.8 will contain support for Python 3.3 (and cut everything before 2.7). > > Regards, > Lars Ruoff > > > > > > > > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig -- Alex Clark ? https://www.gittip.com/aclark4life/ From gamespy1991 at gmail.com Sun Oct 14 06:43:22 2012 From: gamespy1991 at gmail.com (hbprotoss) Date: Sun, 14 Oct 2012 04:43:22 -0000 Subject: [Image-SIG] Strange thing about attribute '__setitem__' of PixelAccess object Message-ID: <507A42DB.8060104@gmail.com> Hello everybody, I'm doing an image processing project. When processing the sampling rate and quantization rate of the image, I come across a strange phenomenon. Why doesn't __setitem__ exist before help() function but appear after it? It is the same even after I execute the express 'data[x,y] = value'. It only appears after help() function. Doesn't the express 'data[x,y] = value' call the method __setitem__ ? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ???.jpg Type: image/jpeg Size: 44186 bytes Desc: not available URL: From feroze.dawood at gmail.com Wed Oct 17 01:35:34 2012 From: feroze.dawood at gmail.com (feroze dawood) Date: Tue, 16 Oct 2012 16:35:34 -0700 Subject: [Image-SIG] Problems converting hierarchical (pyramidal) TIFF images Message-ID: I am doing some image processing on images. I use PIL to resize the images. The image in question is a multilayered TIFF image. When I run it through my code, all I get is an image with a green background and no detail. It is as if the image is being corrupted, or not being read correctly by PIL. I have got the repro case down to a few lines of python code. -- import os import sys import Image import ImageFile import StringIO data = None with open(sys.argv[1]) as fp: data = fp.read() img = Image.open(StringIO.StringIO(data)) print img.format, img.size, img.mode, img.getbands() #img.show() img1 = img.convert("RGB") print img1.format, img1.size, img1.mode, img1.getbands() #img1.show() out = StringIO.StringIO() img1.save (out, "JPEG" , quality=95) with open(sys.argv[2], 'w') as f: f.write(out.getvalue()) -- At each step if you comment out the img.show() I get an image with a green background, and no detail I pass in as arguments to this tool Here is the source image URL: http://feroze.s3.amazonaws.com/ptiff_file.jpg Any idea what I am doing wrong? Thanks, feroze. -------------- next part -------------- An HTML attachment was scrubbed... URL: From feroze.dawood at gmail.com Tue Oct 23 05:45:01 2012 From: feroze.dawood at gmail.com (feroze dawood) Date: Mon, 22 Oct 2012 20:45:01 -0700 Subject: [Image-SIG] Problems converting multi-layered TIFF images Message-ID: I am doing some image processing on images. I use PIL to resize the images. The image in question is a multilayered TIFF image. When I run it through my code, all I get is an image with a green background and no detail. It is as if the image is being corrupted, or not being read correctly by PIL. I have got the repro case down to a few lines of python code. -- import os import sys import Image import ImageFile import StringIO data = None with open(sys.argv[1]) as fp: data = fp.read() img = Image.open(StringIO.StringIO(data)) print img.format, img.size, img.mode, img.getbands() #img.show() img1 = img.convert("RGB") print img1.format, img1.size, img1.mode, img1.getbands() #img1.show() out = StringIO.StringIO() img1.save (out, "JPEG" , quality=95) with open(sys.argv[2], 'w') as f: f.write(out.getvalue()) -- At each step if you comment out the img.show() I get an image with a green background, and no detail I pass in as arguments to this tool Here is the source image URL: http://feroze.s3.amazonaws.com/ptiff_file.jpg Any idea what I am doing wrong? Thanks, feroze. -------------- next part -------------- An HTML attachment was scrubbed... URL: From feroze.dawood at gmail.com Thu Oct 25 05:22:07 2012 From: feroze.dawood at gmail.com (feroze dawood) Date: Wed, 24 Oct 2012 20:22:07 -0700 Subject: [Image-SIG] Unable to read multilayered TIFF images using PIL 1.1.7 Message-ID: I am doing some image processing on images. I use PIL to resize the images. The image in question is a multilayered TIFF image. When I run it through my code, all I get is an image with a green background and no detail. It is as if the image is being corrupted, or not being read correctly by PIL. I have got the repro case down to a few lines of python code. -- import os import sys import Image import ImageFile import StringIO data = None with open(sys.argv[1]) as fp: data = fp.read() img = Image.open(StringIO.StringIO(data)) print img.format, img.size, img.mode, img.getbands() #img.show() img1 = img.convert("RGB") print img1.format, img1.size, img1.mode, img1.getbands() #img1.show() out = StringIO.StringIO() img1.save (out, "JPEG" , quality=95) with open(sys.argv[2], 'w') as f: f.write(out.getvalue()) -- At each step if you comment out the img.show() I get an image with a green background, and no detail I pass in as arguments to this tool Here is the source image URL: http://feroze.s3.amazonaws.com/ptiff_file.jpg Any idea what I am doing wrong? Thanks, feroze. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aclark at aclark.net Wed Oct 10 03:17:39 2012 From: aclark at aclark.net (Alex Clark) Date: Wed, 10 Oct 2012 01:17:39 -0000 Subject: [Image-SIG] Adding Python 3 support References:

<50746FBF.4010102@stsci.edu> <507484F3.8060905@stsci.edu> Message-ID: On 2012-10-09 20:26:37 +0000, Brian Crowell said: > On Tue, Oct 9, 2012 at 3:11 PM, Mark Sienkiewicz wrote: >> From what I read of Pillow, they aren't really interested in maintaining a >> copy of PIL. Do you mean to fork Pillow, or try to persuade them to let you >> help maintain it? > > I want to contribute code that would make Pillow Python 3-capable so > that Debian/Ubuntu might pick it up, and Python 3 developers would > finally have their PIL back. I gathered from the notes that Pillow was > a continuation of PIL as a fork, and since it's active, I expect it > will be more attractive to the distros than a straight port of PIL > 1.1.7. > > I hoped to hear from Alex Clark. He looks like the main contributor. And I just happened to be wandering by, sorry. You can always email me directly: aclark at aclark.net. I drift in and out of this list (via GMANE). Great to hear folks discussing this! My take: - I recently spoken with Felix Schwarz who works on Fedora. He was asking about the status of PIL, and I recommend (after some careful thought) that Pillow be adopted by Fedora. So, with what I just read about Debian in this thread, I think that means we have two Linux distros ready to include Pillow? - For a while Pillow did nothing but packaging-related fixes. Then I began to consider "tracking PIL" which means that we'll release an image code fix if it's tracked upstream (either by ticket or commit). - Then I began to consider Python 3 support. At this point, I'm in favor adding Python 3 support to Pillow using the "best of" of all the recent attempts. I don't plan to do the work myself, but I'll gladly help anyone that wants to tackle it. As for what to do about supporting old Python versions: nothing. Pillow has a nice series of releases on PyPI for anyone that needs to support older Python versions[1], so whatever old versions of Python 3 need to be dropped to make this work is fine with me. I'd say supporting Python 2.7 and 3.3 feels right. Maybe we'll call the Python 3 compatible version of Pillow "Pillow 2.0". Lastly, I've roughly targetted PyCon 2013 as the date to have Python 3 support added to Pillow. I'm not sure if this is overly-ambitious or overly-generous. Alex [1] We could even backport fixes to the 1.x series of Pillow, given enough volunteers. > --Brian > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig -- Alex Clark ? https://www.gittip.com/aclark4life/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From aclark at aclark.net Wed Oct 10 22:12:15 2012 From: aclark at aclark.net (Alex Clark) Date: Wed, 10 Oct 2012 20:12:15 -0000 Subject: [Image-SIG] Adding Python 3 support References:

<50746FBF.4010102@stsci.edu> <507484F3.8060905@stsci.edu> <5075CD17.1090303@stsci.edu> Message-ID: On 2012-10-10 19:31:35 +0000, Mark Sienkiewicz said: > On 10/10/12 15:07, Alex Clark wrote: >> >> - Pillow started as a packaging fork, but I now consider image code >> fixes if they are tracked upstream (by ticket or commit). > > > Does that mean you are looking for a ticket filed against the old PIL > for each of the python 3 modifications? If not, how does this policy > interact with the python 3 support? Not for each of the modifications but maybe an "Add Python 3 support" ticket to the pil-radcliffe-2009 branch to make sure we fly above the radar. IIUC some bit of Python 3 support has been added to PIL somewhere, it's just not released yet. So one scenario is: add that code to Pillow and release it. > _______________________________________________ > Image-SIG maillist - Image-SIG at python.org > http://mail.python.org/mailman/listinfo/image-sig -- Alex Clark ? https://www.gittip.com/aclark4life/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From liaofeng.pro at gmail.com Thu Oct 11 13:12:10 2012 From: liaofeng.pro at gmail.com (feng liao) Date: Thu, 11 Oct 2012 11:12:10 -0000 Subject: [Image-SIG] help: how to add words on a image Message-ID: Hi there: I have a need to add words to a image, just a watermark considering the image maybe black or white, so it's not good to to define the font color of the watermark, what i want is to add a shadow to the words, set the background of the font to white and the shadow to black. I explore the docs still no idea how to implement this. can you help me with this? really thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicolas.david.mail at gmail.com Tue Oct 16 12:10:45 2012 From: nicolas.david.mail at gmail.com (Nicolas DAVID) Date: Tue, 16 Oct 2012 12:10:45 +0200 Subject: [Image-SIG] [BUG - minor][1.1.7] ImageDraw.Draw.rectangle - box argument Message-ID: *ImageDraw.Draw.rectangle : - v1.1.7* It is stated in the docs that the second coordinates pair of the box argument defines a point just *outside* the rectangle, but defines in fact a point located *inside* the rectangle *ex :* >>> im = Image.new('1', (10,10), 0) >>> draw = ImageDraw.Draw(im) >>> # according to doc, the following rectangle size is (4,4) >>> draw.rectangle((0,0,4,4), fill=0xff) >>> # to check, pixel (4,4) should be black, as outside the drawn rectangle >>> im.getpixel((4,4)) 255 >>> # Problem ! ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon.j.george at gmail.com Thu Oct 18 16:35:00 2012 From: brandon.j.george at gmail.com (Brandon George) Date: Thu, 18 Oct 2012 07:35:00 -0700 Subject: [Image-SIG] Changing output resolution when converting EPS file to PNG in Python Imaging Library Message-ID: I wrote a simple implementation of PIL to convert a list of EPS files to PNG images. The problem is the PNG image is of pretty low quality. When I save the image using im.save("file.png", dpi = (1000, 1000)) the increased DPI does not result in a higher quality image. I believe this is due to the im = Image.open("file.eps") importing in low resolution. Is there a way to import the EPS file into a higher resolution "im" object? Thanks in advance. I also have a stackoverflow question about this matter but haven't received any fixes. It is here in case you would like to see my script. Thanks again. Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From sburoff at optonline.net Sun Oct 21 20:28:21 2012 From: sburoff at optonline.net (Steven Buroff) Date: Sun, 21 Oct 2012 14:28:21 -0400 Subject: [Image-SIG] PIL for python 3.X? Message-ID: <000001cdafb9$d9fa1bf0$8dee53d0$@optonline.net> Is there a version of PIL that will run with python 3.3? If not, are there plans to support 3.3 and, if so, is there any release schedule? Thanks very much. Steve Buroff -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: application/octet-stream Size: 4341 bytes Desc: not available URL: From kmike84 at gmail.com Mon Oct 29 20:11:26 2012 From: kmike84 at gmail.com (Mikhail Korobov) Date: Tue, 30 Oct 2012 01:11:26 +0600 Subject: [Image-SIG] Python 3 port -- first pass finished Message-ID: Hello Brian et al, Thanks for your work! There are some issues with Python3 fork (I don't know if they apply to "main" Pillow though): 1) Test running doesn't work for me. python Tests/run.py fails with many obscure errors: running test_numpy ... === error 256 Traceback (most recent call last): File "Tests/test_numpy.py", line 1, in from tester import * File "/Users/kmike/svn/Pillow/Tests/tester.py", line 1, in from __future__ import print_function ImportError: No module named __future__ py.test and nosetest can't even collect the tests from Tests folder so something strange is happening :) It would be great to run PIL tests using tox, but the supplied tox.ini config runs only selftest.py (which is broken under Python3, but that's an another issue, see https://github.com/fluggo/Pillow/pull/1 ). 2) fromstring and tostring methods are gone in Python3 version. They have unfortunate names but I think it is better not to break the interface. For example, I'm writing a Python 2/3 library that uses PIL and this change breaks it under Python3. What do you think about issuing a deprecation warning instead? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.ruoff at gmail.com Mon Oct 29 21:05:42 2012 From: lars.ruoff at gmail.com (Lars Ruoff) Date: Mon, 29 Oct 2012 21:05:42 +0100 Subject: [Image-SIG] PIL: Unexpected results with Image.paste on RGBA images with transparency. In-Reply-To: References: Message-ID: Any other comments? Alex, Pillow says: Please report any non-packaging related issues here first: - https://bitbucket.org/effbot/pil-2009-raclette/issues Should i report the issue there? Lars On Mon, Oct 29, 2012 at 4:33 PM, Alex Clark wrote: > On 2012-10-29 15:05:28 +0000, Lars Ruoff said: > > Hi, >> >> I'm new to this list, so excuse me if this is a known issue. >> I didn't find anything on it on the net so far but didn't have time to >> search much. >> >> I have observed what i consider a flaw in the Image.paste algorithm when >> used with transparent images. >> >> transparent-columns.png is an image with 3 vertical black columns with >> alpha=0.5, 0.2 and transparent respectively. >> transparent-bars.png is an image with 2 horizontal black bars with >> transparent and alpha=0.5 respectively. >> (images attached) >> >> When these two images are transparently pasted one over the other, using >> the following code: >> >> from PIL import Image >> source = Image.open('transparent-**columns.png') >> result = Image.open('transparent-bars.**png') >> result.paste(source, (0, 0), source) >> result.save('transparent-**columns-on-bars-pil.png') >> >> The result is unexpectet to say the least. >> PIL seems to modify the transparency even in regions where only one of >> the images has non-transparent values. >> Very wrong in my opinion. >> >> Doing the same manipulation in GIMP 2.6 gives what i consider the >> expected result. >> (attached for reference) >> >> I guess the per-pixel transparency of the result should be result_alpha = >> 1 - (1-alpha1)*(1-alpha2), >> where alpha1,alpha2 are the alpha channel values from the original images. >> > > > You are welcome to submit a patch to Pillow (the "friendly" PIL fork) here: > > - https://github.com/python-**imaging/Pillow > > > Speaking of that, can anyone review: > > - https://github.com/python-**imaging/Pillow > > > Also, I'm looking for a few folks willing to "stand up" and regularly > review image code fixes. I know nothing about that code, and plan to stick > with being the release manager only. I'll be doing a 1.7.8 release soon (by > the end of this month) then maybe Pillow 1.8 will contain support for > Python 3.3 (and cut everything before 2.7). > > > >> Regards, >> Lars Ruoff >> >> >> >> >> >> >> >> ______________________________**_________________ >> Image-SIG maillist - Image-SIG at python.org >> http://mail.python.org/**mailman/listinfo/image-sig >> > > > -- > Alex Clark ? https://www.gittip.com/**aclark4life/ > > > ______________________________**_________________ > 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 aclark at aclark.net Tue Oct 30 00:24:45 2012 From: aclark at aclark.net (Alex Clark) Date: Mon, 29 Oct 2012 19:24:45 -0400 Subject: [Image-SIG] PIL: Unexpected results with Image.paste on RGBA images with transparency. In-Reply-To: References: Message-ID: Hi Lars, On Mon, Oct 29, 2012 at 4:05 PM, Lars Ruoff wrote: > Any other comments? > > Alex, > > Pillow says: > Please report any non-packaging related issues here first: > > - https://bitbucket.org/effbot/pil-2009-raclette/issues > > > Should i report the issue there? > Yes please. > > Lars > > > > On Mon, Oct 29, 2012 at 4:33 PM, Alex Clark wrote: > >> On 2012-10-29 15:05:28 +0000, Lars Ruoff said: >> >> Hi, >>> >>> I'm new to this list, so excuse me if this is a known issue. >>> I didn't find anything on it on the net so far but didn't have time to >>> search much. >>> >>> I have observed what i consider a flaw in the Image.paste algorithm when >>> used with transparent images. >>> >>> transparent-columns.png is an image with 3 vertical black columns with >>> alpha=0.5, 0.2 and transparent respectively. >>> transparent-bars.png is an image with 2 horizontal black bars with >>> transparent and alpha=0.5 respectively. >>> (images attached) >>> >>> When these two images are transparently pasted one over the other, using >>> the following code: >>> >>> from PIL import Image >>> source = Image.open('transparent-**columns.png') >>> result = Image.open('transparent-bars.**png') >>> result.paste(source, (0, 0), source) >>> result.save('transparent-**columns-on-bars-pil.png') >>> >>> The result is unexpectet to say the least. >>> PIL seems to modify the transparency even in regions where only one of >>> the images has non-transparent values. >>> Very wrong in my opinion. >>> >>> Doing the same manipulation in GIMP 2.6 gives what i consider the >>> expected result. >>> (attached for reference) >>> >>> I guess the per-pixel transparency of the result should be result_alpha >>> = 1 - (1-alpha1)*(1-alpha2), >>> where alpha1,alpha2 are the alpha channel values from the original >>> images. >>> >> >> >> You are welcome to submit a patch to Pillow (the "friendly" PIL fork) >> here: >> >> - https://github.com/python-**imaging/Pillow >> >> >> Speaking of that, can anyone review: >> >> - https://github.com/python-**imaging/Pillow >> >> >> Also, I'm looking for a few folks willing to "stand up" and regularly >> review image code fixes. I know nothing about that code, and plan to stick >> with being the release manager only. I'll be doing a 1.7.8 release soon (by >> the end of this month) then maybe Pillow 1.8 will contain support for >> Python 3.3 (and cut everything before 2.7). >> >> >> >>> Regards, >>> Lars Ruoff >>> >>> >>> >>> >>> >>> >>> >>> ______________________________**_________________ >>> Image-SIG maillist - Image-SIG at python.org >>> http://mail.python.org/**mailman/listinfo/image-sig >>> >> >> >> -- >> Alex Clark ? https://www.gittip.com/**aclark4life/ >> >> >> ______________________________**_________________ >> Image-SIG maillist - Image-SIG at python.org >> http://mail.python.org/**mailman/listinfo/image-sig >> > > -- Alex Clark ? http://aclark.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at fluggo.com Tue Oct 30 23:28:27 2012 From: brian at fluggo.com (Brian Crowell) Date: Tue, 30 Oct 2012 17:28:27 -0500 Subject: [Image-SIG] Python 3 port -- first pass finished In-Reply-To: References: Message-ID: On Mon, Oct 29, 2012 at 2:11 PM, Mikhail Korobov wrote: > 1) Test running doesn't work for me. > > python Tests/run.py > ... > ImportError: No module named __future__ It would be an awfully odd version of Python that didn't recognize a __future__ import. What version of Python is this, and where did it come from? > py.test and nosetest can't even collect the tests from Tests folder so > something strange is happening :) > > It would be great to run PIL tests using tox, but the supplied tox.ini > config runs only selftest.py (which is broken under Python3, but that's an > another issue, see https://github.com/fluggo/Pillow/pull/1 ). I wasn't sure how to tackle selftest.py, so I didn't touch it. I saw your commit to fix it in your own repository: https://github.com/kmike/Pillow/commit/eac71dd8493af7a9bb15f48c63941f5d0b6c763f If that works, I think I'll just borrow your commit. I'm not familiar with tox. The Tests directory is grafted onto stock Pillow, so nothing else was configured to use the tests there. > 2) fromstring and tostring methods are gone in Python3 version. They have > unfortunate names but I think it is better not to break the interface. For > example, I'm writing a Python 2/3 library that uses PIL and this change > breaks it under Python3. What do you think about issuing a deprecation > warning instead? That's a good idea. tobytes/frombytes work in both versions, so I should issue a deprecation warning that says to switch to those names. --Brian From brian at fluggo.com Tue Oct 30 23:31:42 2012 From: brian at fluggo.com (Brian Crowell) Date: Tue, 30 Oct 2012 17:31:42 -0500 Subject: [Image-SIG] PIL for python 3.X? In-Reply-To: <000001cdafb9$d9fa1bf0$8dee53d0$@optonline.net> References: <000001cdafb9$d9fa1bf0$8dee53d0$@optonline.net> Message-ID: On Sun, Oct 21, 2012 at 1:28 PM, Steven Buroff wrote: > Is there a version of PIL that will run with python 3.3? If not, are there > plans to support 3.3 and, if so, is there any release schedule? Thanks very > much. We're working on creating a version that works with Python 2.6/2.7 and 3.2/3.3. Alex is looking to do a release later this year; he can chime in about the timing. You can help us by testing the version found at: https://github.com/fluggo/Pillow --Brian