libTIFF for Linux
v4.7.2LinuxlibTIFF 4.7.2 for native Node.js addons on Linux, precompiled for x64 and arm64, glibc 2.28 or later as @crossbind/port-tiff-linux.
npm install @crossbind/port-tiff-linux@betaInstall
The addons and their loader land in dist; the Node.js playbook has the whole flow.
Usage
The examples the WebAssembly page runs, as Linux compiles them: the same headers and the same calls. They are checked on the WebAssembly build.
Encode pixels as a TIFF and decode them back
The core of libtiff: TIFFSetField and TIFFWriteScanline write a page, TIFFGetField and TIFFReadRGBAImageOriented read it back as display pixels. TIFFStreamOpen keeps the file in memory.
libtiff 4.7.2: 76800 B of RGBA -> 27692 B, starts with II* 160x120, 3 x 8-bit samples, LZW, 1 page true
Store several pages in one file
Scanners and fax software keep a document as one TIFF: every page is a directory closed with TIFFWriteDirectory, listed with TIFFReadDirectory and opened again with TIFFSetDirectory. These pages are 1-bit CCITT Group 4, the fax codec.
3 pages in 6133 B page 1 "cover": 240x320, CCITT Group 4 page 2 "summary": 240x320, CCITT Group 4 page 3 "appendix": 240x320, CCITT Group 4 true
Keep 32-bit float samples exact
Elevation, temperature and microscopy data are not 8-bit pictures. SAMPLEFORMAT_IEEEFP stores the real values, the floating-point predictor helps them compress and TIFFReadScanline reads them back; TIFFRGBAImageOK says why the RGBA reader cannot.
262144 B of float32 -> Deflate 123852 B, with predictor 3 9072 B true Sorry, can not handle images with 32-bit samples
Read one tile of a big image
Large TIFFs are cut into tiles so a viewer decodes only what it shows. TIFFWriteTile stores them, TIFFComputeTile finds the one under a pixel and TIFFReadTile decodes it alone.
512x512 in 16 tiles of 128x128, 239648 B pixel (300, 200) is in tile 6, decoded alone: 49152 B rgb(150, 100, 125)
"Open a TIFF file and print its tags" writes its input with m.FS, which Linux does not have; the C++ takes paths, so it works unchanged on files in the app's storage. It runs on the WebAssembly page.
What is different on Linux
crossbind build -p linuxlinks one.nodeaddon per architecture intodist, next to a loader,dist/<name>.native.cjs, thatrequireandimportboth load. A plaincrossbind buildskips it.await initNative()once, then call the classes: calls are synchronous, and no Worker is involved.- The library and the C++ runtime are linked into the addon statically. It runs on glibc 2.28 or later (RHEL 8, Debian 10, Ubuntu 20.04 and newer), not on musl distributions such as Alpine.
- There is no
m.FS: the C++ reads real paths, and data such asGDAL_DATAorproj.dbis copied todist/data. - The build runs in Docker on any host, a Mac included.
worker_threadsare not supported yet.
Other platforms
- libTIFF overview: the apps, every platform's setup and the packages.
- libTIFF for WebAssembly: browsers, Node.js and edge runtimes.
- libTIFF for Android: React Native apps on Android.
- libTIFF for iOS: React Native apps on iOS.
- libTIFF for macOS: native Node.js addons and Electron on macOS.
- libTIFF for Windows: native Node.js addons on Windows.
- libTIFF for WASI: command-line programs under wasmtime.
Facts on this page come from the port manifests in the repository and from what npm served on beta when the site was built. See the Libraries guide for the full consumer flow.