[Image-SIG] Comparison of PIL and GD speed for setting pixels through python

John Barratt jb at langarson.com.au
Mon Feb 5 00:22:18 CET 2007

Hi Douglas,

Douglas Bagnall wrote:
>>   Method          Time (s)        Times slower than fastest
>> +-----+         +-------+       +------------------------+
>> ctypes,c,GD raw 0.00082         1.0
>> ctypes,c,GD     0.00177         2.2
>> PIL - 'load'    0.03226         39.4
>> ctypes, GD      0.14428         176.4
>> PIL, numpy *    0.26271         321.2
>> PIL - 'point'   0.37180         454.5
> You can also access raw PIL image data via C, so your top line,
> "ctypes,c,GD raw" should be just as applicable to PIL as GD.  Or is
> there some reason this is not so?  From memory, you'd pry open the
> im.im object, and use something like im->image32[y][x] to access each
> pixel.
Ahhh, that is the sort of thing I was wanting to do with PIL, I just 
didn't know how, though hadn't dug into the source code for PIL either. 
  I will have a look to see if I can get this to fly as well.  I would 
hope that in this case that things should be a similar/same speed 
between using PIL or gd as the main image object type.  The main reason 
I did it with gd was because I could see a clear path from the 
documentation to achieve this optimisation.

> Also, your C functions boil down to variations of memset.  Have you
> considered trying that?  Another option is PIL's paste(colour, box)
> method.  I suspect you are ignoring these two because somewhere you
> say "one pixel at a time", but as far as I can tell your routines
> don't allow for that pixel to vary, so there is actually no
> difference.  im.paste(colour, (0, 0, width, height)) is functionally
> the same as your test functions; inside it probably looks much like
> your setPixelsRaw.
The code that does the pixel setting in these tests is very simple yes, 
and deliberately so.  It could be done other ways, this was done as a 
simple test case to get an idea of the overhead of the rest of a system 
like this.  The idea is that each pixel requires some relatively complex 
piece of code to calculate each value, and one that can't be obtained by 
simple array/image operations that work on the whole image.  I have a 
'real world' example that I will finish, and might help show this more 



John Barratt - www.langarson.com.au
          Python, Zope, GIS, Weather

More information about the Image-SIG mailing list