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

[John Barratt]

Hi Chris,

Christopher Barker wrote:
>> I think where PIL & numpy would excel is where you have a cases of a 
>> number of images with calculations required that could be easily 
>> represented as array operations.  The examples I am thinking of don't 
>> lend themselves to this sort of solution.
> 
> Also true -- but are you sure you couldn't do your pixel-specific 
> calculations as array operations?
Well, certainly not simple array operations, I have an example I will 
finish (hill shading) that perhaps could be done with array operations, 
but would I think still require a large number of them, making it still 
inefficient.

> By the way, you really want to be using numpy 1.0.1, not numpy 0.9.8, 
> numpy was undergoing a lot of flux before 1.0 came out.
OK, I will update my version.

> Also, it looks like your code wouldn't work anyway:
> 
> data = numpy.resize(numpy.array(0),outputSize)
>     for x in range(outputSize[0]):
>         for y in range(outputSize[1]):
>             data[x,y] = colourI
> 
> This creates a 2-d array of 32bit integers, which isn't going to match 
> an RBG array. You'd need to either use RGBA, or use an WxHx3 array of 
> bytes:
> 
> data = numpy.zeros(outputSize[0], outputSize[1], 3, dtype=numpy.ubyte)
> 
> However, that would only make it slower! I am a bit surprised that it is 
> as slow as that.
OK, thanks.  I was perhaps guessing at what was required here, and since 
I couldn't get the output to work I couldn't tell it was actually 
broken.  I'll revisit this when I can get numpy working with PIL, 
perhaps the newer version will help.

> There is a movement afoot (mostly us numpy folks) to get a basic n-d 
> array object into the standard Python library. The goal is that all 
> packages that need an nd-array of data (such as PIL, etc) could use the 
> same thing, and then they'd all have the same C API for accessing the 
> data -- this looks like another good argument for that!
mmm that would be nice.  Would be nice to be able to combine python with 
the efficiency of C more easily for tasks 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.
> 
> careful here -- if your "relatively complex" piece of code takes 
> substantially longer than the pixel setting, then all this work is for 
> naught -- though we're all learning something from it!
Yes, true. It could be a relatively minor cost at the end of the day if 
the per-pixel operation is too costly.  But there are actually two 
motivations here :

- If the per-pixel operation isn't too costly, then you get a real 
noticeable benefit of lower pixel-access overhead.

- Even if the per-pixel operation is relatively costly, with this method 
you can easily implement that per-pixel operation in C because the core 
pixel access loop is in C (with PIL or gd at the python level).  This in 
turn should make it run significantly faster than it's pure python 
counterpart.  This perhaps works only with the assumption that it isn't 
too much effort to write/rewrite that particular operation in C.

> by the way, numpy can do more than "simple array" operations -- so it 
> still may help.
OK.  It may indeed be able to do something more effectively with the 
next example.

Thanks for the comments,

JB.

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