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 TypedArray
s 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.5MB (minimal, compressed w/ brotli) to 5MB (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 currently to be considered of beta quality, but it is 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.
npm install magickwand.js
This will install pre-built Node.js native binaries on Windows x64, Linux x64 and macOS x64. It will try to compile the module on all other platforms. It will also install the pre-built WASM binaries which are universal.
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.
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');
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);
To see run the web browser example:
npm run example:browser
Then open http:https://localhost:8030
.
There is also an online demo at https://magickwand.momtchev.com/.
You can run it locally with:
npm run demo:start
Your best source of further information is the Magick++ documentation itself:
- The tutorial: https://imagemagick.org/Magick++/tutorial/Magick++_tutorial.pdf
- The full API: https://www.imagemagick.org/Magick++/Documentation.html
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, the Image.display()
function works and it is an excellent debugging tool.
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. This will be documented separately once it has been stabilized.
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 MSVC
on Windows x64. As the project contains assembler code (mostly SIMD), and I do not have access to a macOS arm64 build host, I cannot provide macOS x64 binaries.
The xPack fully self-contained version will use clang
on all platforms.
-
In order to regenerate the C++ wrapping code, you will need SWIG JavaScript Evolution 5.0.4 - available using the
mmomtchev/setup-swig
Github action or fromconan
-
Alternatively, if you don't want to rebuild SWIG JSE yourself, the SWIG-generated wrappers are included in the published
npm
packages -
Recursively clone the repo
git clone --recursive https://github.com/mmomtchev/magickwand.js
cd magickwand.js
-
npm install
should automatically install the dependencies and compile the module unless a pre-built binary can be downloaded -
or, to do everything manually:
npm install # install all npm dependencies
npx xpm install # install the supporting xpm packages (python, conan, meson, ninja, cmake)
npx xpm generate # generate the SWIG wrappers
npx xpm run prepare --config native-debug # available builds are native, native-debug, wasm and wasm-debug
npx xpm run configure --config native-debug -- -Db_sanitize=address # optional step to enable ASAN
npx xpm run build --config native-debug # build
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.
npm test
should work at this point
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
Currently, you need to have EMSDK installed and activated in your environment. A future version might get it automatically from conan
.
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
.
The following options are available when using npm install
:
-
--verbose
and--foreground-scripts
are genericnpm
options that when used together allow to see the compilation output -
--build-from-source
rebuilds the Node.js native module even if a precompiled binary is available -
--build-wasm-from-source
rebuilds the WASM module even if a precompiled binary is available -
--disable-conan
disablesconan
completely and uses only the system-installed libraries -
--enable-shared
buildsImageMagick
as a shared library and prefers linking against the shared versions of the system libraries, this binary will be smaller and load faster, but it will run only on the system on which it was compiled -
--enable-external
will build only the JavaScript bindings expecting to link to an already existing ImageMagick installation -
--cpp_args=
can be used to pass additional arguments when compiling, add-I
when compiling with an external ImageMagick -
--cpp_link_args=
can be used to pass additional arguments when linking, add-L
/-l
when linking with an external ImageMagick -
--disable-simd
disables SIMD (always disabled for WASM)
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 but leave the support enabled if the corresponding libraries is system-installed
--disable-fonts
for the font delegate libraries (always disabled for WASM)--disable-jpeg
forlibopenjpeg
--disable-png
forlibpng
--disable-tiff
forlibtiff
--disable-webp
forlibwebp
--disable-jpeg
forlibjpeg-turbo
(will be auto-enabled byraw
,tiff
andjpeg200
)--disable-jpeg2000
forlibopenjp2
andjasper
--disable-jbig
forlibjbig
--disable-raw
forlibraw
--disable-jxl
forlibjxl
(this is disabled by default as it is broken at the moment)--disable-exr
forOpenEXR
--disable-fftw
forFFTW3
(this is disabled by default as it is broken at the moment)--disable-heif
forlibheif
--disable-color
forliblcms2
--disable-xml
forlibxml2
and enables the built-in basic XML support--disable-gzip
forzlib
--disable-zip
forlibzip
--disable-bzip2
forlibbz2
--disable-zstd
forlibzstd
--disable-lzma
forliblzma
andxz-utils
--disable-openmp
forOpenMP
(supported only on Linux/native and macOS/native)--disable-display
forX11
(supported only on Linux/native and macOS/native with Quartz), noconan
variant as it always uses the system libraries--disable-cairo
forcairo
(always disabled for WASM)
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
.
A WASM version built this way will probably lack support for most formats as it is very unlikely that you will have system-installed WASM-version libraries that ImageMagick will detect and use.
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.
- The Node.js native module supports
worker_threads
but it cannot be unloaded cleanly and it should be loaded in the main thread, before using it in worker threads, to prevent Node.js from unloading it when a worker quits (fixing this will require changes in Node.js) - Building without HDRI enabled or with a different quantum size than 16 bits is not supported
- If rebuilding when installing from
npm
fails on Windows with the error:npm ERR! fatal: not a git repository (or any of the parent directories): .git
, see #21 - Fonts do not work in the WASM version and are unlikely to be implemented in the near future as a proper implementation will require a complex interface with the browser font engine
- Using the PNG encoder for large images in the WASM version leads to stack overflows, the native version encoder and the WASM decoder do not have this limitation
- Generally, if you get strange exceptions in the WASM code, the most probable reason is a stack overflow - currently,
emscripten
cannot grow the stack which is limited to 2MB and cannot reliably report stack overflows without incurring a significant performance penalty - The loader of the WASM version has its Node.js support disabled to improve its
webpack
compatibility - as Node.js has its own native version, there is no need for WASM
This project serves as showcase and testing grounds for SWIG Node-API.
SWIG JSE roadmap:
- a
wasi-wasm32
target in addition to theemscripten-wasm32
target - a much slower for async operations but more compatible WASM version that does not require COOP/COEP but uses message passing between web browser threads
- Regexp support for
%feature
avoiding the need to explicitly list all the async classes - Provide memory allocation information to the GC
magickwand.js
roadmap:
- SIMD support for the WASM version
- Allow configuration from the CLI of the included wrappers - allowing to build an ultra-light version that includes support only for the methods selected by the user
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
-
Versions of
magickwand.js
up to 0.9.6 including are compiled with alibwebp
vulnerable to CVE-2023-4863. -
Prebuilt binaries of
magickwand.js
are NOT affected by CVE-2024-3094 since these are linked with xz-utils 5.4.5, the last version before the backdoor.
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.
Copyright 2023 Momtchil Momtchev [email protected]
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.
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.