Provided by: exactimage_0.7.4-2ubuntu1_i386
exactimage - fast, modern and generic image processing library
For a client we had to optimize the insane time ImageMagick spent on
certain image processing tasks. After the first code review it became
clear that imagemagick was coded for anything but speed.
We prototyped the needed code in C++, just for speed, and achieved
processing times about 1/20 of what ImageMagick consumes.
In the library we will explore several new algorithms, e.g. for de-
screening, de-skewing, data-dependant triangulation scaling, lossless
JPEG transforms and others as we see need. You are very much welcome to
contribute thrilling state-of-the-art algorithms.
The included codecs take C++ STL std::istreams and std::ostreams
allowing library users to implement their own data sources and
destinations, such as in memory locations or network transfers.
It is intended to become a modern, generic (template) based C++
library, as time permits. - Hopefully a viable alternative to
Since the 0.6 release series ExactImage comes with a completely
rewritten PDF codec, which is not only capable of dumping image data
into a PDF container, but offers complete support for arbitrary vector
data, vector font writing support as well as multi-page documents.
Based on the new PDF codec a new command line front-end named
"hocr2pdf" is included which allows creating searchable PDFs out of
hOCR annotated HTML as obtained from some OCR engines.
Since the 0.5 release series ExactImage comes with the first open-
source, GPL, barcode recognition support ever, an additional, high-
performance image pixel iteration, code generation facility was added,
providing an additional speed boost over the former, pre-0.5 Image
iteration implementation. All algorithms converted to the new iterator
can profit from up to 10x acceleration. Support for writing non-RGB BMP
files, as well as EPS, PS and PDF files and rendering some SVG files
was added. Additionally, language bindings for PHP, Python and Lua can
be generated by the build system (pre-0.5 only a Perl bindings was
Since the 0.4 release series ExactImage supports drawing vector graphic
thru the Anti Grain Geometry rendering engine as well as image
segmentation and fuzzy image pattern matching.
Since the 0.3 release series ExactImage supports per-codec acceleration
of rotation, flipping, scaling and color-space conversion (for JPEG,
ala jpegtran) as well as on-demand decoding.
Since the 0.2 release series ExactImage comes with a stable, simple and
easy to use external API including SWIG support, thus allowing the use
out of any SWIG supported scripting language, such as Perl, PHP,
Python, Ruby or LUA.
Supported image formats
ExactImage currently already supports most wide-spread image formats.
We plan to add at least one new format with each major version release.
Internal C++ library in absence of an external one.
Digital Camera RAW:
Via incooperated dcraw code, might use libopenraw in the future.
Via libjpeg, including lossless transformations.
Via jasper, might use openjpeg in the future.
Via the official libOpenEXR.
Internal C++ code as netpbm does not support arbitrary source and
Internal C++ code to be able to decode in-memory RAW data.
Via libtiff and it’s C++ binding.
Internal C++ code.
Internal C++ code via Agg, read-only.
Internal C++ code, write-only, allows embedding JPEG and JPEG2000,
as well as vector geometry & fonts and write multiple pages.
PS: Internal C++ code, write-only, allows embedding JPEG.
Internal C++ code, write-only, allows embedding JPEG.
Next to implement
Apple Icon Image, Windows Icon Image file format, PCX, Targa, JBIG, Fax
files, sgi, Sun, DJVU, ...
If you miss a format important for you do not hesitate to contact us.
Since version 0.2 ExactImage includes script binding generated through
SWIG. This API is supposed to be stable and if changes are done
backward compatibility is guaranteed to be preserved.
We decided to be that strong with the external API stability even in
this early stage of development, because ever changing APIs just annoy
any serious programmer away and ExactImage is deployed in production
solutions by partner companies.
Incrementally over version 0.3, and 0.4 the external API was extended
with functionality as required by partner companies and build for the
Perl language by default.
Since version 0.5 ExactImage comes with built-in support to generate
not only the Perl, but additionally PHP, Python and Lua laguange
bindings - if the specific language support is detected and requested
In the future we will provide API documentation at this place as well
as in-depth introduction and examples.
The JPEG format is based on the Discrete Cosine Transform (DCT)
performed on equally sized blocks of the pixel image data. With this in
mind one can conclude that it is possible to perform some
transformations on the image data directly on these DCT coefficients by
just moving and transforming the coefficients.
As just working on the DCT coefficients is less expensive (in terms of
CPU cycles) as the decoding and re-encoding process is skipped, it
saving a lot time and additionally prevents new compression artefacts.
Lossless JPEG transformations where first implemented in the Open
Source jpegtran program - a companion application of the JPEG library,
but as using a different tool or library for every image format is a
bit unhandy. Support for these transformations based on the jpegtran
code was added to ExactImage version 0.3.0.
ExactImage 0.3.0 supports lossless:
* orthogonal rotations (90, 180, 270 degree)
* flipping the image data on the X and Y axis
ExactImage 0.3.1 further introduced:
* fast color image to gray conversion
* fast down-scaling by partial decoding DCT coefficients
ExactImage 0.4.1 further introduced:
Common with all this operations is that they are way faster than
performing the pixel-level algorithm on the decoded image data and
(aside down-scaling) do not introduce new artefacts.
Fast down-scaling is also implemented by Enlightenment’s EPEG library
explicitly and we should mention that EPEG is slightly faster, but with
cost to image quality - mostly because it does just nearest neighbor
scaling of the residual scaling applied on top of the partial DCT
A trick how to get a few percent faster down-scaling is outlined in the
econvert examples section of econvert(1).
More information about the ExactImage project can be found at
ExactImage was written by ExactCODE GmbH <http://www.exactcode.de/>.
This manual page was written by Daniel Baumann <email@example.com>, for
the Debian project (but may be used by others).