// the find
Brooooooklyn/Image
Image processing library.
@napi-rs/image is a Rust-backed Node.js image processing library targeting the same space as sharp. It wraps common encode/decode operations in a chainable Transformer API and adds HEIC support by delegating to OS codecs on macOS and Windows. The audience is Node.js server-side image pipelines that want better throughput or HEIC handling.
At UV_THREADPOOL_SIZE=10 it's nearly 2x sharp on WebP (431 vs 238 ops/s) — that's a real gap, not benchmark theater, because napi-rs bindings avoid the libuv threadpool contention sharp suffers from. The HEIC approach is genuinely clever: delegating to ImageIO on macOS and WIC on Windows means no bundled HEVC codec and no patent exposure, which is a hard problem sharp sidesteps by just not supporting HEIC at all. The Transformer chain API composes rotate/resize/encode in a single pass without intermediate allocations. WASI/browser build is a meaningful differentiator — there are real use cases for running image transforms in a Cloudflare Worker or browser context where sharp is simply unavailable.
WebP and AVIF decoding are both absent — you can encode to those formats but cannot read them. That kills the library for the most common server upload pipeline where you need to accept whatever the client sends. HEIC only works on macOS and Windows; Linux support doesn't exist, so despite the headline feature, you can't use HEIC in any standard cloud deployment. ICC profile handling is stripped: everything is force-normalized to sRGB with no profile carried through, which silently destroys wide-gamut data — the README mentions this as a v1 limitation with no timeline. With 409 stars and 12 forks the maintenance surface is thin compared to sharp's ecosystem; composite behavior already diverges from sharp for translucent inputs, and there's no indication those gaps will close quickly.