-
-
Notifications
You must be signed in to change notification settings - Fork 671
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
Allow toga to work with Pillow image files #2142
Comments
Hi I'm new to toga and love the project. I want to work on this. Hope I will get your guidance. |
@dr-gavitron Awesome - the ticket description should contains all the design details that are specific to this problem; if you're looking for general advice on the Toga development process, we have a section in the docs to get you started. If you need any more specific advice or guidance, ask a question and we'll do our best to answer it. |
I want to create an ImageView but it did not show up?
why I cant see the image? What I can see is a dot, probably one pixel.. |
That's almost certainly #1745, which has been resolved in the main branch. If you're thinking of working on this feature, you're definitely going to want to be working on the main branch, not the stable release from PyPI. |
I made some progress. I have added support for PIL.Image in toga.Image. Here's HowI have added a new argument called pil_image alongside path and data in toga.Image. The default value of pil_image is None. How to use this feature
|
Good to hear you've made progress; the real demonstration that you've made progress is to submit a PR. Also - it's worth noting that your sample code is different from the sample code that was provided in the feature specficiation. If you've got a good reason for diverging from the original specification, you can make your case for that change - but changing an API from one that has been proposed without a clear explanation is going to raise eyebrows during the review process. |
Inspecting the code I found: toga.Image has 2 args, path and data, both are set to None. So, whenever we will give first argument the path parameter will be set. Like for creating an image with raw bytes
The point is: for now toga.Image has two named argument first one is
If you want to do that, then we should unify all the sources then detect the type of the source from the value. For that case
|
Implemented all of the features with little diversion. Now you can:
Submitting a PR. |
Allowing a PIL.Image to be passed as the first argument by using a type check is what the "Additional details" section of the feature specification called for. Adding the equivalent type check for a
Some notes about this: We can't arbitrarily rename the argument to If we're going to change the name (and I agree it's probably worth it), we need to maintain a backwards compatibility path. This means the prototype needs to be something like:
with usage of the The |
In my recent commits, I didnt changed the code. Meaning pil_image is still an argument, but I get your point. There are other image formats that toga may support in the future... So, we cant be giving every time a new argument to toga.Image to support a new format(the way I add pil_image to support pillow image object) for that case, we should go according to the above way: adding Should I start implementing it? |
Yes - I think Image et al should take a single argument, and we should use type checking to convert that data into whatever format is possible; |
Hi. I ran tests but got error.
|
The set of requirements that must be installed for testing purposes, but not for "normal" installation, is defined in the |
Implementation of
This should be working but tests failed...
I think |
No - there's no need to use a temporary file on disk. If the API is file-like, use an Also - |
I just realised the |
Doing this... I think I should wait,.. |
I'd like to take a turn at this, if that's alright. @freakboy3742 did you have any particular API in mind for registering image formats and their respective converters? Perhaps a registry class and a method like |
Yes. I may not be able to work on this any sooner due to some unavoidable circumstances. |
@HalfWhitt I'd imagine we'd use That said:
|
@dr-gavitron Hope everything's okay, take care of yourself. @freakboy3742 Aha, the power of asking! I'll read up on that; implementing just PIL first does indeed sound like a good strategy. I did look through the PR, wasn't sure if I should comment there or here. Will start from there. |
If you're looking for an examples of how the plugin interface works: Toga already uses them to register backends (see the platform module in toga core, plus the setup.cfg registrations for each backend). Briefcase also makes extensive use of them. |
Fixed by #2231. |
What is the problem or limitation you are having?
Pillow is the defacto image handling library for Python. While it's possible to convert Pillow
Image
objects intotoga.Image
objects, it requires some manual boilerplate handling. It should be possible to use Pillow images directly, with the boilerplate being managed by thetoga.Image
interface.Describe the solution you'd like
The following code should work:
The
as_image()
APIs should default totoga.Image
as the format, soimageview.as_image()
would be the equivalent ofimageview.image
.PIL should not be added as an install-time requirement of toga-core, or any Toga backend. It must be possible use Toga in an environment that doesn't have PIL. This means any
from PIL import Image
call must be wrapped inexcept ImportError
handling, and the body logic cannot assume that the PIL image class is available.Describe alternatives you've considered
Do nothing, and require manual conversion.
Additional context
The boilerplate version of converting a PIL image to a Toga image is as follows:
The first argument to
toga.Image
is the "path". It currently accepts a string or a Path; or we can extend this to allowPIL.Image
as a data type, and if PIL is available in the runtime environment, do a type check to perform the conversion intodata
form. A similar check would be required on thetoga.ImageView
constructor, thetoga.ImageView.image
setter, etcFor bonus points, these APIs wouldn't be PIL specific. There are other libraries (e.g., OpenCV) that have their own image formats; it would be desirable to provide support for those image formats as well. The simple solution would be to add additional type checks for other known image formats. An even better option would be to add a plugin interface that allows any third-party library to register an image format that can be passed in to
toga.Image
et al, with PIL being the first consumer of that API (with the implementation provided as part of Toga).The text was updated successfully, but these errors were encountered: