Open benzkji opened 5 months ago
I've had to add a BytesIO use, did not work otherwise. I've tried many things to treat the file in place, but it's not working till now...even asked on SO: https://stackoverflow.com/questions/78020254/python-pillow-treat-an-animated-gif-or-webp-in-place
Feedback welcome, I'm not so sure about not leaving open file pointers around?
...also, will remove _call_pil_method soon.
It has tests now, for all builtin processors. Though, it only tests if frames are preserved, and some of the basic functionalities (as resize/crop) - I'm afraid I don't fully understand all of the processors, and especially not all of the edge cases involved.
If the used BytesIO workaround is ok for @SmileyChris I think it could be merged?
...remaining to add: docs. Also, I would add save_all=True
for all images with more than one frame, it would be better to support them without having to set/use THUMBNAIL_IMAGE_SAVE_OPTIONS
.
...also, docs: how to make them work again?
@SmileyChris feedback welcome :) or maybe shall I reach out to @jrief ?
A first draft. Test still passing, no new tests for the moment.
I don't think that a wrapper (processors leaving as is, abstract things away for processors) would be a good solution, as some processors could still not operate like this. For example, the autocrop would autocrop each frame individually, and if a processor creates a new Image(), and pastes the original into it, frames would still be lost - as the
background
processor does it.With my proposal, animated GIF support would need to be supported by each processor individually. Most of the times, this would mean a simple usage of the new helper function instead of directly calling
im.whatever()
.Using
And animated GIFs work (on my machine), hopefully animated WEBP would as well. A first feedback for the approach is very welcome.