[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