`resize.Crop` actually hasn't been moved to `crop.Crop` (as the removed
class claimed). In fact, what used to be called `resize.Crop` is now
`resize.Fill`. The confusion is understandable, since it's what
motivated the change in the first place!
Though it's not the case with `FileSystemStorage`, attempting to delete
a nonexistent file can cause an exception (as in #80). We want to avoid
these errors but don't want to suppress others raised in the process of
deleting the file, so we first check to see if the file exists.
The `options` argument for `ImageSpec` and `ProcessedImageField`
replaces `quality` and provides a more general solution, allowing the
user access to PIL's format-specific options (including "quality",
"progressive", and "optimize" for JPEGs).
After #51 presented a good use case, we decided to make this part of
the API (i.e. remove the underscore). The default value for the `lazy`
kwarg is changed to `True` to reduce the likelihood of accidental
regeneration of images. Closes#54.
At first, we only had a small amount of code for preserving
transparency in `img_to_fobj`, but as that code grew it became apparent
that it really didn't belong in the utility function. This commit
creates an `AutoConvert` processor which is automatically run before
saving unless you disable it by passing `autoconvert=False` to your
`ImageSpec` or `ProcessedImageField` constructor. `img_to_fobj` is once
again a simple utility function for creating a file object from a PIL
image.
The in-code comments explain it pretty thoroughly but, in short, this
handles a lot more of the situations in which you're converting to or
from formats that support transparency.
Previously, we set it to an arbitrary large number (which turned out
not to be large enough in some cases). Since we may have been
overriding something the user explicitly chose (and our value may be
overridden by another app), that probably wasn't good. After this
change, `MAXBLOCK` is only increased when it needs to be--and even
then, only temporarily.
