Eevee
Eevee
And allow passing one to `resize`. The tricky bit is avoiding hardcoding all the filter names that happen to exist in the wrapped version of IM, but I don't know...
This would be kinda neat, to report how much space an image is actually using.
I have some notes saying (a) I would like a more general and robust way of handling proxies to properties of other objects, and (b) an existing pixel proxy class...
Makes for a really nice proof of concept.
In `convert`, these are special syntax for special pseudo-formats. I don't know where they'd live here. Just functions in the `image` module? Note that I need a way to expose...
I think you'd ask a frame for a canvas, and use methods on that to do the actual painting?
I super wish I could use this to expose a big C string without making a copy, but so far I don't see how.
That includes gradients, patterns, the clipboard, printers (!), and other such nonsense that arbitrary user input could abuse.
I don't know where these go, but imo they should be able to use the filter API, even though they don't strictly work the same way.
Make them objects with properties, to replace the current filetype-introspection API. But allow passing strings for filetypes. Maybe reuse the enum thing from #5?