Image conversion and processing
econvert: Is a command line frontend for the image processing library and mimicks Imagemagick's convert. However since some aspects of the convert arguments are too limited (e.g. even now we have two ditherizers to select from) or annoying (colorspace conversion is quite unintuitive to control with Imagemagick and the data is often blown up to an more generic colorspace) the econvert syntax never will be 1:1 compatible with convert. Also because those options only start with one dash (-) ... or are named density rather than resolution and so on.
First image data must be read using -i or --input, processing routines are selected by their name with two leading dashes (e.g. --rotate) and at any point the data might be written into a file with -o or --output, for example:
econvert -i lenea.tiff --box-scale 0.5 -o medium.png --box-scale 0.5 -o little.png
Since version 0.3 the library tries to delay image decoding as much as possible and provides lossless and accelerated algorithms to work on compressed data (such as JPEGs) directly:
econvert -i AV220-Scan.JPG --resolution 300x300 -o 1.jpg --rotate 90 -o 2.jpg --rotate 180 -o 3.jpg --rotate -90 -o 4.jpg --flip -o 5.jpg --flop -o 6.jpg --scale 0.25 -o thumb.jpg
In this example 1.jpg will be created from the original JPEG DCT coefficients, those coefficients will be rearranged and 2.jpg, 3.jpg, 4.jpg, 5.jpg and 6.jpg will be written without any additional loss in precision (no new JPEG artefacts) and with outstanding speed. Only at the end, for image thumb.jpg, the DCT will actually be decoded - but due to the accelerated JPEG scaling only partially! The whole chain of operations applied to an 8 bit RGB JPEG only takes 0.99s on 2GHz Intel Core2.
For a detailed list of available procesing options please refer to the tool's help (-h, --help).
- more optimizing Image::iterator, to avoid the need of handcrafting so many optimized algorithms
- CMYK support
- YUV support
- ICC color calibratoin
- EXIF support
- XMP support
Tips & Tricks
Thumbnails of black and white (bi-level) images
When 1 bit, black and white, images are scaled down the output often might look pretty awful. The box scaling algorithm usually does a pretty good job thumbnailing b/w images, however as the ExactImage algorithms always operate in the color-space the image data is stored in the colorspace must be changed (e.g. to 8 bit gray) before applying the box scaler. At the end the result might be converted back to just a few shades of gray such as 2 or 4 bit:
econvert -i avision-bw-scan.pbm --colorspace gray8 --box-scale 0.125 --colorspace gray2 -o thumb.png
Slightly faster JPEG down-scaling
As outlined in the lossless JPEG page, ExactImage is slightly slower than EPEG, though with noticeable higher output quality. If you do not care about quality, only about bare thruput (maybe in an web application?) you can force nearest neighbor scaling by just specifing a scale factor the JPEG decoder can accellerate (1/2, 1/4, or 1/8) and apply the remaining scalling manually. To archive a faster scaling with the effective factor 0.33:
econvert -i big.jpg --scale .5 --nearest-scale 0.66 -o thumb.jpg
Working with digital camera RAW data
Digital still camera raw images differ from model to model and are sometimes even obfuscated to prevent loading by third parties. However, ExactImage supports a wide range of RAW formats thanks to the embedded dcraw code (we had to embed a copy of dcraw as the orignal project is only available as a command line program and not in form of a library - ExactImage needs to have some more control about how the image data is passed around, e.g. in memory and not by pipes).
Usually decoding of RAW data should be transparent and automatic, however some formats also are valid TIFF files and the embedded thumbnail might be picked by ExactImage's TIFF support in favour of the actual RAW content. This this cases the dcraw backend decoder can explicitly be request with the decoder prefix of the input parameter:
econvert -i dcraw:img_0123.cr2 ...
As of version 0.6.5 ExactImage also allows to quickly extract the embedded thumbnail preview, if any, by specifing "thumb"(nail) as decompress argument before the image is loaded:
econvert --decompress thumb -i dcraw:img_0123.cr2 ...
This usually just takes parts of a second and is useful to generate previews, galleries, etc.
Loading real raw data
While working on algorithms, dumping frame-buffer content or doing low-level driver development it often is handy to also load arbitrary RAW pixel data. Via the "raw:" codec specification this is possible in econvert. As econvert does use the current color-depth (colorspace) and size for the raw data they have to be specified before loading the image like this:
econvert --size 1696x32 --colorspace rgb8 -i raw:data-file ...