p5
p5 copied to clipboard
Implement Image APIs
Implement the following Image APIs
Image
- [x] createImage()
- [x] saveCanvas()
- [ ] saveFrames()
- [x] p5.Image
Loading & Displaying Pixels
- [x] loadImage()
- [x] image()
- [ ] tint()
- [ ] noTint()
- [x] imageMode()
- [x] pixels
- [ ] blend()
- [ ] copy()
- [x] filter()
- [ ] get()
- [x] loadPixels()
- [ ] set()
- [x] updatePixels()
Hey @ziyaointl. It seems we need to have different PImage classes for skia and vispy renderers, as their implementation is very different.
We could either declare an abstract class in p5.core and then inherit them in each renderer and do their specific implementation. This doesn't feel necessary to me as we use p5.renderer type calls for each type of rendering function, there is no direct need to have an interface which declares the type of PImage as renderer will handle those calls.
So I am thinking of just implementing different renderer specific classes in each renderer. In the same way we did Style class.
Also, p5.js uses 1D lists to handle image manipulation as well. So, to specify RGBA values, we use ith, i+1th, i+2th, i+3th index for each pixel's RGBA values. These manipulations are handled by load_pixels and update_pixels.
Instead of this, skia supports numpy and I am thinking of using them only. So users would have to update a (width * height) * (RGBA) numpy array to modify the image's pixels. This would be different from p5.js but more pythonic way to do Processing in python.
Let me know your thoughts :)
We could either declare an abstract class in p5.core and then inherit them in each renderer and do their specific implementation. This doesn't feel necessary to me as we use
p5.renderertype calls for each type of rendering function, there is no direct need to have an interface which declares the type ofPImageas renderer will handle those calls.So I am thinking of just implementing different renderer specific classes in each renderer. In the same way we did
Styleclass.
I'm inclined to use an abstract PImage class because we need to provide a common interface for the object returned by createImage and loadImage. Then, each renderer can define their own image class that inherits from PImage. I think this is slightly different from the Style classes because PImage is a public interface, but Style classes are not. Feel free to correct me if you think this is wrong though! To be frank I'm probably missing a lot of details on how difficult this would be to implement.
Also,
p5.jsuses 1D lists to handle image manipulation as well. So, to specifyRGBAvalues, we useith,i+1th,i+2th,i+3thindex for each pixel's RGBA values. These manipulations are handled byload_pixelsandupdate_pixels.Instead of this, skia supports numpy and I am thinking of using them only. So users would have to update a
(width * height) * (RGBA)numpy array to modify the image's pixels. This would be different from p5.js but more pythonic way to do Processing in python.
I think this is a great idea! Being able to use numpy arrays directly would be both more performant and IMO makes the indexing more intuitive.
Yes, that makes sense. I think we should define an abstract class in image.py having methods similar to p5.Image. Each renderer can then have its own implementations.
Thank you :)
Hey @tushar5526! Is this issue still active ? If yes, can i work on tint() & blend() function
Yes @Hakarishirenai you can start with this
For both methods, we should first abstract them in PImage at "p5/core/image" and then each render will have its own implementation, right?
Yes, this is the pattern we are following. This issue focuses features specific to skia but feel free to add it for vispy