[Bf-committers] bpy.Image memoryview problems

[Campbell Barton]

For experimenting, defining a type for an image is trivial.

The way it works is bpy_types.py has its classes used when available,
otherwise the C/API creates a class its self.

All you'd need to do is...

class Image(bpy_types.ID):
    def buffer_get(self, type="byte", frame=None):
        return None # replace with ctypes/buffer stuff.

After this you can do..
  buffer = bpy.data.images["foo"].buffer_get()

Notice the class must follow the rna parent class, will raise an error
if you dont.
there are similar examples in the same file - Mesh for eg.

Its not clear to me if python should even be defining compositor nodes
which is why I rather start with buffer access done quickly in python
as a test, which doesn't integrate too deep with the py/c rna api.

On Mon, May 3, 2010 at 6:23 AM, Dan Eicher <dan at trollwerks.org> wrote:
>> - An Image has float and int buffers, so we cant assume one buffer per
>> image
>> - An image has imbuf's for different frames of an image sequence.
>>
>
> Could add a method that returns a memory view object that deals with frames,
> layers and such instead of exporting it directly or add different memory
> mappings like image[frame][x][y][pixel].
>
> Either way I'm just trying to get this to work with Lenna before attempting
> to deal with more complex cases.
>
>
>> - This code adds image specific buffer access in bpy_rna.c, which I
>> prefer keep generic where possible.
>>
>
> The main reason I put it there (aside from the obvious of there being no
> proper python image type) is so any object that inherits from bpy_struct can
> export a buffer interface with a simple RNA_struct_is_a() conditional.
>
> Lots of places this could be used -- for instance an object can export all
> the mesh geometry as a (readonly) memoryview object for exporters with
> python taking care of dereferencing pointers to the face/vertex structs and
> whatnot. The PEP has an example with an array of pixel struct pointers which
> demonstrates this.
>
>
>> - adds members, increasing the size of every object/mesh/vertex
>> instance (not just images)
>>
>
> Those aren't really needed -- just one way to keep track of the malloc'd
> arrays for stride, etc. since there's no 'official' way to deal with them.
> Could use another method to keep track of them in any case.
>
>
>> - brecht's recent work on image tiles means this could be tricky to
>> continue supporting in some cases??
>>
>
> I'm not familiar with his work on this.
>
> ------------------------------------
>
> I did see that there is already a py_buffer implementation for simple types
> (that could be adapted to use tp_as_buffer pretty easily) so all this is
> really doing is expanding that for more complex types.
>
> Don't really want to spend time on (yet another) feature that won't get
> accepted so if you're happy with the ctypes/pointer thing I'll just find
> something else to work on. Do kind of need py_buffers for composite pynodes
> though...
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell