[Bf-committers] pixel get & image processing

Campbell Barton ideasman42 at gmail.com
Thu Jan 27 21:42:54 CET 2011


Yes, the problem is you need to have headers from the same version of
blender used to get the offsets, that runs the python scripts.
This would work best if it was a part of the blender build process
though its not at all likely to happen since we already have RNA.
You may be interested in: http://code.google.com/p/pybindgen/

On Thu, Jan 27, 2011 at 9:02 AM, Hart's Antler <bhartsho at yahoo.com> wrote:
> So basically, the best way to expose the blender C API and its data structures, is to parse all the headers in blender?  and generate a ctypes bindings for everything?-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: "bf-blender developers" <bf-committers at blender.org>
> Date: Wednesday, 26 January, 2011, 11:11 PM
>
> 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
> _______________________________________________
> 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


More information about the Bf-committers mailing list