[Bf-committers] pixel get & image processing

Campbell Barton ideasman42 at gmail.com
Thu Jan 27 05:33:23 CET 2011


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).

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 experement with this.

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.

Note that this is totally unsupported, The script is 30 lines added to
the bottom of pydna.py which adds "buffer_raw" attribute to existing
image objects.

Download:
http://www.graphicall.org/ftp/ideasman42/image_buffer_raw_access.py

Example usage.
>>> # Inserts property into blenders Image RNA.
>>> import image_buffer_raw_access
>>>
>>> ima = bpy.data.images['MyImage']
>>> x, y, rect, rect_float = ima.buffer_raw
>>> pixel_index_max = x * y * 4
>>> # set colors for first pixel
>>> rect[0] = 0  # red
>>> rect[1] = 255  # green
>>> rect[2] = 128  # blue
>>> rect[3] = 255  # alpha


On Tue, Jan 25, 2011 at 11:55 PM, Domino Marama
<domino at dominodesigns.info> wrote:
> On Tue, 2011-01-25 at 15:44 -0700, Dan Eicher wrote:
>
>> Anyhoo, image data access comes up quite often and the party line it
>> seems is to just use ctypes (which doesn't work for our windows
>> brethren due to the way msvc exports symbols). Or there's an
>> 'unofficial' port of PIL to py3 that works according to Josh (from the
>> Tube project) blog but I haven't tested it yet meself.
>
> I've got to say that the continued lack of any official way to
> manipulate and read images from python is a show stopper for me and a
> large number of users of my Primstar scripts for Second Life sculpties.
>
> One of my users offers paid support for my scripts and I know they get
> hundreds of new customers each month. The active user base is well into
> the thousands, and we are all still using Blender 2.49 :)
>
> I've users on Windows version from XP upwards, various Linux distros and
> even Mac users willing to put up with UI bugs caused by my use of
> tkinter dialogues.
>
> I'm not interested in rewriting Primstar in C, some of the features
> would be too complex to implement as I make extensive use of variable
> length lists per pixel during the bake process to provide unrivalled
> flexibility in sculptie creation. I also couldn't support all the
> platforms I currently do with Python.
>
> Hopefully the mission to move all users to 2.5.x will outweigh the
> issues in allowing image editing in Python soon as there's a lot of us
> waiting for the scales to tip ;)
>
> Something like the RenderLayer.rect access would be great, but I'd
> settle for get_rect and set_rect if live access is too slow on a pixel
> basis. Though "too slow" is better than "not possible" in my book
> anyway..
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell


More information about the Bf-committers mailing list