mirror of
https://github.com/Hopiu/django-imagekit.git
synced 2026-03-17 05:40:25 +00:00
142 lines
5.4 KiB
ReStructuredText
142 lines
5.4 KiB
ReStructuredText
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.
|
|
|
|
.. _`Tox`: http://pypi.python.org/pypi/tox
|
|
|
|
|
|
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.
|