https://github.com/acdha/nativeimaging

PIL-compatible interface for platform libraries such as GraphicsMagick, Aware or JAI.
https://github.com/acdha/nativeimaging

Last synced: 2 months ago
JSON representation

PIL-compatible interface for platform libraries such as GraphicsMagick, Aware or JAI.

• Host: GitHub
• URL: https://github.com/acdha/nativeimaging
• Owner: acdha
• Created: 2010-10-19T21:03:42.000Z (about 14 years ago)
• Default Branch: master
• Last Pushed: 2017-11-07T18:21:40.000Z (about 7 years ago)
• Last Synced: 2024-10-14T17:55:20.491Z (3 months ago)
• Language: Python
• Homepage: http://acdha.github.com/NativeImaging/
• Size: 28.7 MB
• Stars: 25
• Watchers: 4
• Forks: 2
• Open Issues: 2
• Metadata Files:
  • Readme: README.rst

Awesome Lists containing this project

README

        
Native Imaging

==============

This is an experiment in seeing how far you can get using platform-provided

packages such as GraphicsMagick, CoreImage, etc. to provide a PIL-like

interface but taking advantage of their support for more advanced features

such as threading, broader format support (including JPEG-2000),

vectorization, etc.

The goal is simple: a user should be able to install NativeImaging and do

something like this to a program which is currently using PIL::

    from NativeImaging import get_image_class

    Image = get_image_class("GraphicsMagick")

Status

------

.. image:: https://secure.travis-ci.org/acdha/NativeImaging.png

   :alt: Build Status

   :target: http://travis-ci.org/acdha/NativeImaging

aware

~~~~~

Very fast JPEG 2000 thumbnail generation compared to GraphicsMagick. Requires

the non-OSS AWARE library: http://www.aware.com/imaging/jpeg2000.htm

GraphicsMagick

~~~~~~~~~~~~~~

Currently supports typical web application usage: loading an image, resizing it

and saving the result. Testing reveals mixed results, beating PIL when

producing thumbnails from large TIFFs and underperforming when thumbnailing

equivalent JPEGs, both by about 2:1.

Both CPython and PyPy are supported, with PyPy seeing performance gains using the CFFI backend instead of

ctypes. Significant optimization gains are likely possible, particularly where the I/O functions marshall

data in and out of the non-filename-based APIs where data is currently being copied.

Jython

~~~~~~

Currently supports basic usage: loading an image, resizing it, and saving the

result. Performance is generally quite decent as the Java Advanced Imaging API

is quite tuned, if somewhat baroque in design.