Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement Image APIs #379

Open
10 of 17 tasks
tushar5526 opened this issue Aug 22, 2022 · 9 comments
Open
10 of 17 tasks

Implement Image APIs #379

tushar5526 opened this issue Aug 22, 2022 · 9 comments
Labels

Comments

@tushar5526
Copy link
Member

tushar5526 commented Aug 22, 2022

Implement the following Image APIs

Image

Loading & Displaying Pixels

@tushar5526
Copy link
Member Author

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.

@tushar5526
Copy link
Member Author

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.

@tushar5526
Copy link
Member Author

Let me know your thoughts :)

@ziyaointl
Copy link
Member

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.

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.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.

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.

@tushar5526
Copy link
Member Author

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 :)

@Hakarishirenai
Copy link

Hey @tushar5526!
Is this issue still active ? If yes, can i work on tint() & blend() function

@tushar5526
Copy link
Member Author

Yes @Hakarishirenai you can start with this

@Hakarishirenai
Copy link

For both methods, we should first abstract them in PImage at "p5/core/image" and then each render will have its own implementation, right?

@tushar5526
Copy link
Member Author

Yes, this is the pattern we are following. This issue focuses features specific to skia but feel free to add it for vispy

@tushar5526 tushar5526 added this to the Integrate Skia milestone Feb 7, 2023
@tushar5526 tushar5526 added the skia label Feb 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants