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 <ideasma...@gmail.com> wrote: From: Campbell Barton <ideasma...@gmail.com> Subject: Re: [Bf-committers] pixel get & image processing To: "bf-blender developers" <bf-committers@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 <bhart...@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 <ideasma...@gmail.com> wrote: > > From: Campbell Barton <ideasma...@gmail.com> > Subject: Re: [Bf-committers] pixel get & image processing > To: dom...@dominodesigns.info, "bf-blender developers" > <bf-committers@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 > <dom...@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@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > - Campbell > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers