Support WEBP sizers and filters

respondcreate / django-versatileimagefield

A drop-in replacement for django's ImageField that provides a flexible, intuitive and easily-extensible interface for quickly creating new images from the one assigned to the field.

http://django-versatileimagefield.readthedocs.io/

MIT License

531 stars 88 forks source link

Support WEBP sizers and filters #191

Closed iamjazzar closed 3 years ago

iamjazzar commented 3 years ago

Adding support for WEBP resizing. This is an issue presented by some users and happened with me. Currently, trying to resize WEBP images results in some errors. This PR fixes them.

Fixes #151

respondcreate commented 3 years ago

Thanks @ahmedaljazzar, thanks for this PR! If you add some test coverage I'll be happy to get this merged.

coveralls commented 3 years ago

Coverage remained the same at 100.0% when pulling 6f84572abe351a45f5fa9f60fb4422a1188aeff6 on ahmedaljazzar:support-webp-resizing into 2c09821d17440042144840249a3e227086ce5888 on respondcreate:master.

iamjazzar commented 3 years ago

@respondcreate Thanks for the reply. Tests have been pushed and passed locally.

iamjazzar commented 3 years ago

New update with passing post_processor/post_processor_tests.py. Checked on on my fork here

iamjazzar commented 3 years ago

Coverage should work fine now. I updated the doc regarding using WebP images on early Django versions (<2.2). In these versions, if a user attempts to create an ImageField instance without specifying the height and width of a given WebP image, they should expect to receive a RuntimeError.

This is issue is under Django #29705 and solved in Django #10331

I didn't add any validators for the above behavior for the following reasons:

Django no longer supports these releases. Check here
Users who are on these affected versions and using WebP images are already setting these values.
It's an attempt to hack what Django already fixed in newer releases.

iamjazzar commented 3 years ago

@respondcreate Any idea why tests are failing?

respondcreate commented 3 years ago

Hey @ahmedaljazzar !

Just checked the logs and re-ran, it appears it was an issue with Github Actions. ¯_(ツ)_/¯

NyanKiyoshi commented 3 years ago

When it comes to unsupported versions of Django, it is common practice for Django third-party libraries to only support the versions that Django is actually still porting bug and security fixes.

A GitHub issue could be opened for that matter in order to drop the unsupported versions. It would need to be another PR for updating CIs, setup.py classifiers and aligning the supported Python versions to what the Django versions are supporting.

respondcreate commented 3 years ago

That's a great idea, @NyanKiyoshi ! Do you want to open an issue so we can discuss a plan of attack for dropping unsupported versions? My thinking up until now was just to support as many versions as I could without incurring too much of a headache, your suggestion gives a more solid framework for deciding which versions to support which I like a great deal more.

iamjazzar commented 3 years ago

@respondcreate Just a reminder here.

respondcreate commented 3 years ago

Hey @ahmedaljazzar !

Just realized I forgot to actually do a PyPI release on this back in July when we were working on this. Apologies!! Just pushed the 2.2 release this morning. Again: I am so, so sorry for the delay and thanks again for all your hard work on this PR, I appreciate it!!