Crop doesn't necessarily imply the any scaling is taking place. Several
ideas were discussed, from renaming Crop to combining both processors
into a single Resize processor (as they were in the original IK), but
those solutions were felt to either precluded future extension
(alternative resize modes) or make the API too verbose.
ImageProcessor didn't do anything. I'd rather get it out of there to reduce the
temptation for future IK contributors to do type checking and mess up peoples'
custom processors.
Replaced calls to Image.open with an open_image utility function.
The open_image utility calls Image.open, but then wraps the opened Image's
copy method with a version that preserves EXIF data. This allows an
ImageSpec to copy the original image, yet still provide all the original
image's exif data to the processor pipeline.
Transpose now takes transposition constants as arguments. Multiple
transpositions can be sequenced together in one Transpose processor.
Auto transposition is not yet supported (PIL strips the EXIF data, so need to
find a workaround for getting that data to the processor).
The process of choosing an image format has been cleaned up and
Processors' role in determining the format has been removed.
Previously, processors would return a tuple containing the modified
image and the format. Other parts of IK overrode PIL's Image.format
with the target format, although that had no effect on PIL and the fact
that it didn't throw an error was just lucky.
In the old IK API, processors (like `Transpose`) were able to access
the file by inspecting the model instance (which carried an options
object that specified the attribute name of the ImageField from which
the file could be extracted). Since the new API allows for multiple
ImageFields (and because IKOptions have been removed), it became
necessary to provide more information. Initially, this was accomplished
by passing the spec to `process()`, however with the addition of
ProcessedImageField, it became clear the a cleaner solution was to pass
only the field file (ImageSpecFile or ProcessedImageFieldFile).
This keeps the ORM stuff (fields, etc.) out of the `ImageProcessor` API
but (because field files, not just regular files, are passed) the
average hacker can still have their processor make use of model
information by accessing the model through the file's `instance`
property.
The Format processor was really a special case and didn't do any
processing at all. Instead, ImageSpec just knew to look for it and
responded accordingly. Therefore, it's been replaced with a `format`
property on ImageSpec. This warranted a deeper look at how the format
and extension were being deduced (when not explicitly provided); the
results are documented in-code, though the goal was "no surprises."
