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.
Eric's fixes in c00ea10b0a meant that
some of the code that already existed to reuse objects would actually
be run for the first time. Naturally, there were some bugs; namely, I
was storing a filename (instead of a File object) in `_file` and a bad
else clause.
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.
Centralized access of _img, tried to reduce re-calculation of some
properties, renamed _imgfield to source_file to reflect the fact that
it's an ImageFieldFile and not an ImageField.
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.
The original handler implementation ported code from the old ImageModel's
save method, but ended up duplicating the efforts of the ImageSpecFile's
_create method.
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.
One handler is created per model instead of per bound image spec.
This cuts down on the number of handlers created, and also offloads the
policing of the handlers in memory to the signal framework. Since they are no
longer being created per spec, the handlers can be weakly referenced.
Removed the save and clear_cache methods from ImageModel (along with helpers).
Now, whenever an ImageSpec is contributed to a model, handlers are created for
the post_save and post_delete signals. The post_save handler does the work of
running the ImageSpec processors and caching the resulting file, while the
post_delete handler does the work cleaning up the cached files.
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."
You're no longer restricted to just one, special-case admin thumbnail. Make as
many as you want by adding AdminThumbnailView properties to your model and
including them in your admin class's `list_display` tuple. You can also provide
a custom template. Note that (because this change introduces templates to
imagekit), imagekit is now required in INSTALLED_APPS.
Ideally we could get this stuff out of the model, but we'll have to look into
whether that's possible without making things really complicated.
By creating the Descriptor using contribute_to_class (instead of in
ImageModelBase's __init__), we take the first step towards eliminating the need
to extend ImageModel at all.
Removed the cache_dir, cache_filename_fields and cache_filename_format
properties of IKOptions. While these were very powerful, I felt that it was
unnecessarily confusing to have two properties (cache_dir and
cache_filename_format) that determine the filename. The new cache_to property is
modeled after ImageField's upload_to and behaves almost identically (the only
exception being that a callable value receives different arguments). In
addition, I felt that the interpolation of model properties provided by
cache_filename_fields, though useful, would be better handled by a utility
function outside of this library.
This works kind of like Django's models' _default_manager. If your specs don't
specify an image_field, and your IKOptions don't specify a default_image_field,
the first ImageField your model defines will be used.
