CPython’s convention is to use args for a tuple of ordered argumentrs, keywords or kw for a dict of named arguments.
@ideasman42 yes I know but that is what confused me
but what I did not know is that keyword arguments can be used as regular arguments as well in python taking their position into account so both version are the same
>>> i1 = imbuf.new([1024,768])
>>> i2 = imbuf.new(size=[1024,300])
>>> i1.size
(1024, 768)
>>> i2.size
(1024, 300)
I did not know python keywords had such behavior. So now the name makes sense and it is as it should be and good thing I asked cause as I suspected I was missing something and indeed I was
As you may suspect I tested it first using it as regular argument which is what confused me(see i1 in example).
Thanks mate.
Hooray!!!
My first patch, added support for image buffer duplication , get it now while it hot … just be careful so you wont be burned
More info here
Adding my creation here, mostly to keep eyes on it.
https://developer.blender.org/D3496
I would like to implement pixel access also. The python buffer api docs give me some idea, but do have in mind some existing implementation to get “inspiration”?
Icons can be an “inspiration” they are loaded in memory not from files but from inside blender source code. I would imagine the waveform preview most likely uses the imBuf struct.
if it does it should give you access to the pixel data via the rect member of the imBuf struct.
A typical usage is when using as a opengl texture like so
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA8, b32buf->x, b32buf->y, 0, GL_RGBA, GL_UNSIGNED_BYTE, b32buf->rect);
If you mean in terms of Python implementation I am in favor of Python objects that follow closely Blender source structs like imBuf in this case. So I would just add a rect python list that would contain the same data. That may also be good for performance, if you want direct access to pixels that may means that most likely you want access to a large collection of pixels and it would not be a good idea to introduce any conversion in that stage that would severely slow down the Python execution.
I can add rect myself to the implementation if @ideasman42 has no objections.
Yeah I was thinking python implementation
https://docs.python.org/3/c-api/buffer.html
I just quickly read through this, and realized that this probably isn’t as easy as exposing rect by getter and setter.
you can do this buffer if you want.
I need to finish proxies, then we can have python effect sequence.
Video producers not using blender will hate us 
No guarantees because I am about to leave for vacation but I completely agree bytearray buffer is a more appropriate solution.
A getter and setter most likely will need to be implemented anyway if I remember the Python C API correctly.
I don’t think it’s a great idea to do video processing via Python though, I don’t think Python would cut in this case. So far we exposed the c side so there is no big penalty for Python but if you start relying too much on Python for pixel access and manipulation your probably will get very slow results especially with hd videos.
So I think if video editing is your goal, it will be much better to implement what you want in C and then expose those functions to Python.
I am not in hurry…
Python for pixel access and manipulation your probably will get very slow results especially with hd videos.
That’s why I am working on proxies (indexed video buffers).
Sure C is preferable, but API with pixel access will enable anyone to do whatever processing they want. Also various generators and stuff like that.
1 Like
I run some performance tests for image processing in python. For now I was just drawing solid rectangle over whole image. As expected performance of pure python was terrible, but with numpy I was able to “redraw” whole image(each one frame) ~60x maintaining performance of 60fps.
here some lab notes:
Question is, if numpy is usefull for working with images. I have no experience with it…
But it seems that pillow is also using buffer interface, so it can be hooked up.
So as image generator this seems to be perfect.
I will try to do some processing / distortions to see how much we can do in python.
When the VM , and that does not apply just to CPython but most VMs, executes a function in a DLL (which is what a pyd library is) like numpy , it basically calls its highly optimized machine code. Which means the VM has to wait for the machine code to do what it wants to do and as such cannot affect directly the performance of the library although it can introduce overheads. Obviously that comes with the downside that it cannot do its own stuff either like GC, dynamic types and what makes Python so powerful.
Hence why Numpy is so fast or most libraries that are written in C , which applies to most CPython libraries as well. Of course C alone cannot offer top performance if you don’t know what you are doing so in the end there is no way avoiding C completely.
Numpy is a more general library but indeed has been made for top performance and is written in C. There are a ton of libraries you can use because nowadays every C/C++ libraries offer at least CPython wrappers. So its completely up to you.
I didn’t have time to read all of the posts but I thought T54314 could be relevant. Blender misses this functionality which is very bothering. Some people may not need to store all of the rendering images on disk immediately.
@kilon, I know, I just wanted to demonstrate, that this interface is useful and provide some “quantitative” info about how useful.
Anyway I have this buffer code “ready”, I just have to add selection of rect/rectf. But I am working on other stuff and don’t want to switch branches.
@AmirS
This module deals with image processing.
Your issue seems to be node viewer API stuff