Well after some digging through the PIL source code after the prompting
from Douglas, and some tinkering with the python C interface, I have
implemented a C based version of the core pixel setting loop using PIL
objects. I have also added 'reference' versions using plain python,
setting an int
John Barratt wrote:
> I haven't tried it, but did originally think of adding it to the list of
> things tested. Given this specific example though, where the idea is
> that a specific method or piece of code is needed to be run for every
> pixel (not that it actually is in this abstract example
John Barratt wrote:
> I think that has about exhausted the possible combinations to test, but
> if anyone has any other suggestions, please let me know. Also if anyone
> has any ideas as to why the PIL/raw/c version should go so much faster
> than the gd/raw/c version I would be interested to
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.
>
Hi Douglas,
Douglas Bagnall wrote:
> um.. cache locality? With GD you have
>
> for (u=0; u for (v=0; v d[v][u] = colour;
> }
> }
>
> which goes through every row for each column, jumping back and forth in
> memory. You need to switch the order of the loops, like you have in t
This is a follow up on my previous posts about PIL/gd speed comparisons,
which is perhaps now a bit of a misnomer. It is now really just a
C/python speed comparison for custom intensive image operations given it
is clearly possible to access the same sort of raw data with both gd and
PIL withi
