Changelog

v2.0.2

  • Fixed the pickling of ImageSpecFieldFile.
  • Signals are now connected without specifying the class and non-IK models are filitered out in the receivers. This is necessary beacuse of a bug with how Django handles abstract models.
  • Fixed a ZeroDivisionError in the Reflection processor.
  • cStringIO is now used if it’s available.
  • Reflections on images now use RGBA instead of RGB.

v2.0.1

  • Fixed a file descriptor leak in the utils.quiet() context manager.

v2.0.0

  • Added the concept of image cache backends. Image cache backends assume control of validating and invalidating the cached images from ImageSpec in versions past. The default backend maintins the current behavior: invalidating an image deletes it, while validating checks whether the file exists and creates the file if it doesn’t. One can create custom image cache backends to control how their images are cached (e.g., Celery, etc.).

    ImageKit ships with three built-in backends:

    • imagekit.imagecache.PessimisticImageCacheBackend - A very safe image cache backend. Guarantees that files will always be available, but at the cost of hitting the storage backend.
    • imagekit.imagecache.NonValidatingImageCacheBackend - A backend that is super optimistic about the existence of spec files. It will hit your file storage much less frequently than the pessimistic backend, but it is technically possible for a cache file to be missing after validation.
    • imagekit.imagecache.celery.CeleryImageCacheBackend - A pessimistic cache state backend that uses celery to generate its spec images. Like PessimisticCacheStateBackend, this one checks to see if the file exists on validation, so the storage is hit fairly frequently, but an image is guaranteed to exist. However, while validation guarantees the existence of an image, it does not necessarily guarantee that you will get the correct image, as the spec may be pending regeneration. In other words, while there are generate tasks in the queue, it is possible to get a stale spec image. The tradeoff is that calling invalidate() won’t block to interact with file storage.
  • Some of the processors have been renamed and several new ones have been added:

    • imagekit.processors.ResizeToFill - (previously imagekit.processors.resize.Crop) Scales the image to fill the provided dimensions and then trims away the excess.
    • imagekit.processors.ResizeToFit - (previously imagekit.processors.resize.Fit) Scale to fit the provided dimensions.
    • imagekit.processors.SmartResize - Like ResizeToFill, but crops using entroy (SmartCrop) instead of an anchor argument.
    • imagekit.processors.BasicCrop - Crop using provided box.
    • imagekit.processors.SmartCrop - (previously imagekit.processors.resize.SmartCrop) Crop to provided size, trimming based on entropy.
    • imagekit.processors.TrimBorderColor - Trim the specified color from the specified sides.
    • imagekit.processors.AddBorder - Add a border of specific color and thickness to an image.
    • imagekit.processors.Resize - Scale to the provided dimensions (can distort).
    • imagekit.processors.ResizeToCover - Scale to the smallest size that will cover the specified dimensions. Used internally by Fill and SmartFill.
    • imagekit.processors.ResizeCanvas - Takes an image an resizes the canvas, using a specific background color if the new size is larger than the current image.
  • mat_color has been added as an arguemnt to ResizeToFit. If set, the the target image size will be enforced and the specified color will be used as background color to pad the image.

  • We now use Tox to automate testing.

v1.1.0

  • A SmartCrop resize processor was added. This allows an image to be cropped based on the amount of entropy in the target image’s histogram.
  • The quality argument was removed in favor of an options dictionary. This is a more general solution which grants access to PIL’s format-specific options (including “quality”, “progressive”, and “optimize” for JPEGs).
  • The TrimColor processor was renamed to TrimBorderColor.
  • The private _Resize class has been removed.

v1.0.3

  • ImageSpec._create() was renamed ImageSpec.generate() and is now available in the public API.
  • Added an AutoConvert processor to encapsulate the transparency handling logic.
  • Refactored transparency handling to be smarter, handling a lot more of the situations in which one would convert to or from formats that support transparency.
  • Fixed PIL zeroing out files when write mode is enabled.

v1.0.2

  • Added this changelog.
  • Enhanced extension detection, format detection, and conversion between the two. This eliminates the reliance on an image being loaded into memory beforehand in order to detect said image’s extension.
  • Fixed a regression from the 0.4.x series in which ImageKit was unable to convert a PNG file in P or “palette” mode to JPEG.

v1.0.1

  • Minor fixes related to the rendering of README.rst as a reStructured text file.
  • Fixed the included admin template not being found when ImageKit was and the packaging of the included admin templates.

v1.0

  • Initial release of the new field-based ImageKit API.

Table Of Contents

Related Topics

This Page