[Bf-committers] pixel get & image processing

Domino Marama domino at dominodesigns.info
Thu Jan 27 12:21:27 CET 2011


On Thu, 2011-01-27 at 04:33 +0000, Campbell Barton wrote:
> Adding image access properly is tricky because it needs to work right
> with blender, notify on changes, upload rect from float, lock the
> image threads before accessing.

> I had a talk to Ton about this but he's of the opinion to support it
> correctly or not at all (which is understandable).

It is understandable, though I hope I'm right in reading "don't support
it until we can do it correctly" as the meaning. "We can't do it
correctly so don't support it" sounds wrong :)

> But, I get the impression python devs work on specific projects where
> image access is useful (research & custom scripts)  so I wrote a
> ctypes (pure python) direct memory access to pixel data for people who
> like to experiment with this.

Thanks for that. It'll be next week before I can test it out, but looks
like it'll do what I need.

> a quick test on setting all pixels on a 1024x1024 image though python
> took 0.75 seconds, getting was about the same.
> 
> Is someone wants to extend this further they could add 'py_buffer'
> access to bypass pythons slowness.

For my use that's plenty fast enough. The largest image size used for
Second Life sculpties is 64 x 128 pixels, though I do use 512 x 512 for
adding library maps to Primstar. As it's basically import and export
stuff, speed isn't a big factor anyway.

> Note that this is totally unsupported

I hope a supported way stays on the todo list, I learnt my lesson on
using oddball code with the tkinter stuff under 2.49 :)

But at least I can get started on the port now and just isolate the
image stuff so it's easy to swap out when there's a better way.

Cheers,
Domino




More information about the Bf-committers mailing list