[Bf-committers] pixel get & image processing

[Campbell Barton]

Blank strings to these functions use the current process.
Typically ctypes is not all that useful for data access with large C
programs because you need to match the ctypes class with the C headers
(involves parsing headers or manual copying).

ctypes.CDLL("") / ctypes.LibraryLoader("") are only used to extract
the DNA struct info blender stores internally for blend file reading.

Its possible to read the image buffer with a much smaller script if
the 'Image' struct was hard coded into it, but when writing pydna.py I
was more interested in a way to wrap all DNA, not image access,
advantage with this method is Image struct changes wont break. Any
changes to the ImBuf struct will break since ImBuf is not a DNA
struct, it cant be auto-wrapped.

Disclaimer that pydna.py is 'use at own risk', experimental, unsupported by BF.

- Campbell

On Thu, Jan 27, 2011 at 6:41 AM, Hart's Antler <bhartsho at yahoo.com> wrote:
> Very interesting Ideasman,is this the secret back door for getting into blender from ctypes?  Passing empty strings returns blenders internals, just like when ctypes normally loads an external shared library?
>     blend_cdll = ctypes.CDLL("")    blend_lib = ctypes.LibraryLoader("")
> -brett
> --- On Wed, 1/26/11, Campbell Barton <ideasman42 at gmail.com> wrote:
>
> From: Campbell Barton <ideasman42 at gmail.com>
> Subject: Re: [Bf-committers] pixel get & image processing
> To: domino at dominodesigns.info, "bf-blender developers" <bf-committers at blender.org>
> Date: Wednesday, 26 January, 2011, 8:33 PM
>
> 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
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell