[Bf-committers] pixel get & image processing

[Campbell Barton]

Hi Domino,
Hard to say when certain features will be added back, but a hack like
this could be officially supported if it we can ensure it wont crash
blender (and better not use pydna, ctypes could be used internally
still).

- expose py_buffer access rather then ctypes array.
- ensure image data access is bound to a single execution.

A problem we have with our api is that python references blender's
pointers (#python people tell me this is very bad).
and python is not aware of re-allocations, so its very easy to crash
blender if python keeps access to invalid memory.

In this area we have double standards, referencing a python vertex
location after undo or editmode toggle would crash blender too.
We should fix this but this is a big topic on its own and I wont go into it. :S

Unlike mesh data its not so important to have access to 1000s of
elements at once so we could expose buffer data in a way that you only
get restricted access to the buffer (so blender wont re-alloc before
the next access).

2 ways to do this come to mind.
- image.buffer_access(MyFuncWhichEditsABuffer)
  so the buffer can be disabled for future access by buffer_access
once the callback is done.

- python's new contexts (unrelated to bpy.context)
  eg:
with buffer in image.buffer_context:
    .... edit the buffer

The contexts have an __enter__ and __exit__ methods which may be able
to be used to ensure the objects dont get accessed later on too.
however I didn't use contexts yet, only read examples.
http://effbot.org/zone/python-with-statement.htm,
http://www.python.org/dev/peps/pep-0343/


You could question why not just add this in our C api, a memoryview
patch has been submitted for this.
It would work but it doesn't solve the problem of restricting access
and I'm making an effort not to allow too much custom-py-c-api code
into blender, since it has a tendancy to feature-creep.
2.4x py api was over 100,000 lines. Initial 2.5x RNA api over ~1500
lines (not including rna_*.c), now its approx 6000 since it includes
code for keyframing, array/mathutils access and registration but I
really want to keep it small.

- Campbell

On Thu, Jan 27, 2011 at 11:21 AM, Domino Marama
<domino at dominodesigns.info> wrote:
> 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
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell