search

mmomtchev / magickwand.js

Full native ImageMagick-7 bindings for Node.js native & WASM - showcase for SWIG Node-API
ISC License
49 stars 6 forks source link
image-processing magick magick-api magickwand node-js nodejs swig wasm

readme

magickwand.js

ISC Test npm package Node.js CI npm

formerly known as node-magickwand

This package is a full native port of the ImageMagick-7 C++ library to both Node.js native and browser WASM using SWIG Node-API + emnapi.

Unlike all other ImageMagick npm packages, it does not use the CLI to interact with the utilities, but offers direct access to the full C++ API. It supports both synchronous and multithreaded asynchronous operations, it is integrated with TypedArrays and ArrayBuffer and it has full TypeScript support.

It adds many new features and offers a substantial performance boost and usability benefits over the previous CLI ports.

The Node.js native addon version and the browser WASM version share the same SWIG interface files, the same generated C++ wrappers, the same API, the same TypeScript bindings and the same unit tests which are run both in the browser and in Node.js. Both support asynchronous parallel processing using the same multi-threading model.

The pre-built binaries are fully self-contained and do not need an existing ImageMagick installation. It is also possible to rebuild the package against a shared ImageMagick-7 when using the native version in Node.js.

The default WASM version is also fully self-contained and its size range is from 1.7MB (minimal, compressed w/ brotli) to 5.6MB (default full build compressed w/ gzip) depending on the supported image formats.

Both versions support synchronous and asynchronous multi-threaded operations with an identical API and identical TypeScript bindings. WASM requires SharedArrayBuffer (read about COOP / COEP). The Node.js native version also support OpenMP multithreading and SIMD instructions.

The project is very actively developed and maintained because of it its special status as SWIG Node-API showcase project. It is a testament to SWIG Node-API's capabilities, namely producing a 400k C++ lines multi-threaded and dual-environment project out of 600 lines of SWIG code.

It is feature-complete and it should be reasonably stable. The Node.js native version is designed to be well-suited for server-side use with an Express.js-like framework. It has been debugged for memory leaks and, and when only asynchronous methods are used, it should never block the event loop. See also Security.

There is also a medium article about using the new Node-API support in SWIG in case you are interested in porting another C++ library to Node.js.

Usage

Installation

npm install magickwand.js

This will install pre-built Node.js native binaries on Windows x64, Linux x64 and macOS x64 and arm64. It will try to compile the module on all other platforms. It will also install the pre-built WASM binaries which are universal. The prebuilt binaries are statically linked to the (almost) full set of supported libraries by ImageMagick and are very large. See below for alternatives.

Refer to the example directory for more code examples including browser use examples.

Refer to the test/integration directory for integration examples with various environments including webpack and TypeScript.

Importing

Starting from 2.0, ES6 2020 projects can import magickwand.js in fully automatic mode, using Node.js 16 exports. This means that a single import statement can be evaluated by both Node.js or a modern web bundler such as webpack (including React) or rollup to pick either the native version or the WASM version depending on the context.

import ImageMagick from 'magickwand.js';
// ImageMagick will be either a native library
// (if called from a Node.js application)
// or a WASM bundle (when bundled by a web bundler)
const { Magick, MagickCore } = await ImageMagick;

The only downside is that this requires ES6 2020 top-level await. If you are using TypeScript, you will have to transpile to ES2020.

There is is alternative, synchronous, entry point that works only in Node.js. It is compatible with both CJS and ES6. It uses @guybedford's CJS named exports in Node.js.

const { Magick, MagickCore } = require('magickwand.js/native');

Example

Using ES6 2020 and top-level await:

import ImageMagick from 'magickwand.js';
import { fileURLToPath } from 'url';
import * as path from 'path';
const { Magick } = await ImageMagick;

// The famous ImageMagick wizard
const wizard = path.join(path.dirname(fileURLToPath(import.meta.url)),
  'node_modules', 'magickwand.js', 'test', 'data', 'wizard.png');

// Read a new image (synchronously)
let im = new Magick.Image(wizard);
console.log(`${wizard}: ${im.size()}`);

// Read a new image (asynchronously)
im = new Magick.Image;
await im.readAsync(wizard);
console.log(`${wizard}: ${await im.sizeAsync()}`);

// Convert it to PNG
await im.magickAsync('PNG');

// Rescale and rotate it
await im.scaleAsync('160x212');
await im.rotateAsync(60);

// Extract the RGBA data
// Conversion to Uint16 is automatic (it recognizes the type of the array)
const pixels = new Uint16Array(im.size().width() * im.size().height() * 4);
await im.writeAsync(0, 0, im.size().width(), im.size().height(), 'RGBA', pixels);

In a webpack bundle

To see run the web browser example:

npm run example:browser

Then open http://localhost:8030.

There is also an online demo at https://magickwand.momtchev.com/.

You can run it locally with:

npm run demo:start

Documentation

Your best source of further information is the Magick++ documentation itself:

magickwand.js implements the full Magick++ C++ API.

(only the Pixels and PixelData classes are not implemented in JavaScript - use Image.pixelColor to get individual pixels or write the image to a TypedArray with RGB/RGBA/CMYK encoding to get a large region).

Also, if you have a code editor capable of reading the TypeScript bindings, such as Visual Studio Code, it will provide online help for each method.

When in doubt about the JS semantics of a particular method, you can also check the unit tests: https://github.com/mmomtchev/magickwand.js/tree/main/test.

When using Node.js with X-Windows (Linux or Mac), it is possible to build the module with X11 support, in this case the Image.display() function will work and it will provide an excellent debugging tool. The default prebuilt binaries do not have this option at the moment in order to support headless installation. Use --enable-display to build the native module with it.

Rebuilding from npm with the built-in ImageMagick library

Starting with version 2.0, magickwand.js uses the new hadron build system specifically developed for dual-environment (browser WASM and native Node.js) Node-API projects.

npm install magickwand.js --build-from-source

This will also rebuild the included Magick++ library. Currently, you will need a working C++17 environment as the full xPack version that will rebuild itself with its own compiler is still not ready. The project is tested, and has pre-built binaries, with gcc on Linux x64, clang on macOS x64 and arm64, and MSVC on Windows x64.

This will rebuild the bindings against the available system-installed (usually shared) libraries which will lead to an order of magnitude smaller addon size. If the X11 libraries are available, this build will support X11 (Image.display method) on Linux and macOS.

If you want to rebuild the bindings using the full set of statically linked libraries obtained from conan, you have to use:

npm install magickwand.js --build-from-source --enable-conan

The xPack fully self-contained version will use clang on all platforms.

Rebuilding from git or using an externally provided ImageMagick library

Alternatively, you can use an already installed on your system ImageMagick-7 library. In this case you should know that there are two compilation options that can produce four different libraries - enabling/disabling HDRI (High Dynamic Range Images) which returns float pixels instead of int and Q8/Q16 which determines the bit size of the Quantum. These only apply to the data used internally by ImageMagick - image files still use whatever is specified. Mismatching those will produce an addon that returns garbage when requesting individual pixels. By default, this addon uses Q16 with HDRI - which is the default setting on Linux. Unless you can regenerate the SWIG wrappers, you will have to use the exact same version (the latest one at the release date) that was used when they were generated. In this case, assuming that you have ImageMagick installed in /usr/local, build with:

npm install --verbose --foreground-scripts=true --build-from-source  \
  --enable-external --enable-shared                                  \
  --cpp-args="`pkg-config --cflags Magick++`"                        \
  --cpp-link-args="`pkg-config --libs Magick++`"

In this case, it would be possible to use a non Q16HDRI build or any other specially built ImageMagick-7 as long as its version is an exact match.

If you want to use a different ImageMagick-7 version, you will have to regenerate the SWIG wrappers. A future version might do this automatically since SWIG-jse is now available from conan on all OS.

Rebuilding the WASM version

The WASM version uses SWIG JSE and emnapi.

Generally, the prebuilt WASM binaries should work for everyone. To rebuild the WASM version yourself, you should start by building the conan dependencies:

npm install magickwand.js --build-wasm-from-source --enable-conan

Currently, you need to have EMSDK installed and activated in your environment. A future version might get it automatically from conan.

conan is required when building to WASM because it is unlikely that you will have system-installed WASM-version libraries that ImageMagick will detect and use.

Or to build a minimal version that excludes many optional dependencies:

npm install --build-wasm-from-source --verbose --foreground-scripts           \
  --disable-fonts --enable-jpeg --enable-png --disable-tiff                   \
  --disable-webp --disable-jpeg2000 --disable-raw --disable-openmedia         \
  --disable-exr --disable-fftw --disable-heif \
  --disable-color --disable-xml --enable-gzip --disable-zip                   \
  --disable-bzip2 --disable-zstd --disable-xz --disable-lzma --disable-simd   \
  --disable-openmp --disable-display --disable-jbig --disable-cairo

At the moment this cross-compilation has been tested only on Linux. Rebuilding both the native and WASM module at the same time is supported but currently it is not possible to use different compilation options. This is possible only by manually rebuilding in the node_modules/magickwand.js directory using xpm.

All installation / compilation options

The following options are available when using npm install:

Additionally, the following options control the various ImageMagick submodules. All --disable-* options have --enable-* counterparts which are enabled by default and --disable-*-conan variants which disable only the built-in conan delegate - when conan is enabled - but leave the support enabled if the corresponding libraries is system-installed.

When disabling the built-in static delegates with --disable-*-conan, the ImageMagick configure script will still detect the presence of compatible system libraries and will try to use them, producing a custom binary that will need the dynamically loaded versions of those libraries on your system. The system-installed libraries will be detected through the use of the standard CMake supplied modules and, when that fails, on Linux and macOS, through pkg-config.

If the WASM binary is rebuilt with no additional libraries, its size will be brought down to 1.5MB compressed with brotli. Further reduction is possible by disabling unneeded SWIG wrappers but this requires to manually edit the SWIG source files and to regenerate the C++ files. Producing a version that supports only synchronous mode and does not require COOP/COEP is also possible. I will consider any offer for commercial support of such dedicated light version.

Also note that currently the unit testing suite expects all supported delegates to be included.

Using this project as a tutorial for creating C++ bindings for Node.js and emscripten/WASM with SWIG Node-API

ImageMagick is the perfect candidate for an automatically generated with SWIG Node.js addon:

ImageMagick has an absolutely huge number of API methods and objects - the SWIG-generated module totals more than 400k lines of C++ code - and this is only covering the Magick++ API and the enums from the MagickWand API. However there are relatively few distinct method signatures. The whole SWIG project which brings you this full API to Node.js and the browser, measures a grand total of only 656 lines - half of which are comments!!

I have tried to be as verbose as possible throughout the Magick++.i file - you should start there. ImageMagick is a very complex C++ project with over 30 years history and it uses (almost) every single SWIG feature. Study the various JS wrappers that expect special arguments (ArrayBuffer, TypedArray, arrays), remember to check the ImageMagick header file for the original C++ function and you should be able to use its SWIG typemaps as a starting point in your project.

There is also a medium article about using the new Node-API support in SWIG.

Known to be broken at the moment

Future plans

This project serves as showcase and testing grounds for SWIG Node-API.

SWIG JSE roadmap:

magickwand.js roadmap:

Security

ImageMagick is a very widely used software. Security vulnerabilities tend to be very well known and are usually fixed very fast.

The current ImageMagick version can be checked in the MagickLibVersionText / MagickLibAddendum global exported constants.

IMPORTANT

Special care must be exercised when ImageMagick is used to process images coming from untrusted sources. Although possible, outright arbitrary code execution by embedded malicious code in an image is extremely rare and there has been only one such case during the last 30 years - the infamous ImageTragick exploit in 2016. It did not affect users who had restrictive security policies.

However DoS attacks are much more common as it is relatively easy to construct an image that will be of relatively small size when compressed, but it will expand to fill all available memory once uncompressed.

If using ImageMagick in such environment, it is highly recommended to review the default security policy in node_modules/magickwand.js/lib/binding/{platform}/ImageMagick/etc/ImageMagick-7/policy.xml and to eventually replace it with a more restrictive security policy from the examples in node_modules/magickwand.js/deps/ImageMagick/config/. Be also sure to check https://imagemagick.org/script/security-policy.php for more information and to follow an appropriate security announcements mailing list. Also, consider re-building ImageMagick yourself in order to support a more limited amount of image file formats, as complexity is always the main risk factor with any software.

Example for loading websafe (the most restrictive security policy):

const pathNodeMagick = require.resolve('magickwand.js');
const websafe = fs.readFileSync(path.resolve(pathNodeMagick,
  'deps', 'ImageMagick', 'config', 'policy-websafe.xml'), 'utf8');
Magick.SetSecurityPolicy(websafe);

assert(MagickCore.IsRightsAuthorized(
  MagickCore.SystemPolicyDomain,
  MagickCore.WritePolicyRights, 'file') === false);

The current security policy can be dumped to stdout by calling MagickCore.ListPolicyInfo(). There is also an online tool for analyzing security policies at https://imagemagick-secevaluator.doyensec.com/.

In all other cases security should not be of any concern.

License

Copyright 2023 Momtchil Momtchev momtchil@momtchev.com

Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies.

THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.

Disclaimer

magickwand.js is not affiliated in any way with ImageMagick LLC.

In particular, the WASM version is an independent and distinct port from the WASM port of one of the ImageMagick authors.