exiftool-vendored
Advanced tools
Blazing-fast, cross-platform Node access to ExifTool.
High performance via -stay_open and multithreading.
7-300x faster performance than competing packages (depending on platform)!
Support for Mac, Linux, and Windows.
Proper extraction of
Thumbnail and Preview (if they exist)Robust type definitions of the top 99.5% tags used by over 6,000 different camera makes and models
Auditable ExifTool source code (the "vendored" code is verifiable)
Automated updates to ExifTool (as new versions come out monthly)
Robust test suite, performed with Node v4, v6 and v7 on Linux, Mac, & Windows.
npm install --save exiftool-vendored
The vendored version of ExifTool relevant for your platform will be installed
via
platform-dependent-modules.
You shouldn't include either the exiftool-vendored.exe or
exiftool-vendored.pl as direct dependencies to your project.
import { exiftool } from "exiftool-vendored";
// Read all metadata tags in `path/to/image.jpg`.
// Returns a `Promise<Tags>`.
exiftool
.read("path/to/image.jpg")
.then((tags /*: Tags */) => console.log(`Make: ${tags.Make}, Model: ${tags.Model}`))
.catch(err => console.error("Something terrible happened: ", err))
// Extract the low-resolution thumbnail in `path/to/image.jpg`,
// write it to `path/to/thumbnail.jpg`, and return a Promise<void>
// that is fulfilled when the image is extracted:
exiftool.extractThumbnail("path/to/image.jpg", "path/to/thumbnail.jpg");
// Extract the "Preview" image (found in some images):
exiftool.extractPreview("path/to/image.jpg", "path/to/preview.jpg");
// Extract the "JpgFromRaw" image (found in some RAW images):
exiftool.extractJpgFromRaw("path/to/image.cr2", "path/to/fromRaw.jpg");
// Extract the binary value from "tagname" tag in `path/to/image.jpg`
// and write it to `dest.bin` (which cannot exist already
// and whose parent directory must already exist):
exiftool.extractBinaryTag("tagname", "path/to/file.exf", "path/to/dest.bin");
With the npm run mktags target, > 3000 sample images, and maxProcs set to 4,
reading tags on my laptop takes ~6 ms per image:
Read 2236 unique tags from 3011 files.
Parsing took 16191ms (5.4ms / file) # win32, core i7, maxProcs 4
Parsing took 27141ms (9.0ms / file) # ubuntu, core i3, maxProcs 1
Parsing took 12545ms (4.2ms / file) # ubuntu, core i3, maxProcs 4
For reference, using the exiftool npm package (which doesn't work on Windows)
took 85 seconds (almost 7x the time):
Reading 3011 files...
Parsing took 85654ms (28.4ms / file) # ubuntu, core i3
This package is so much faster due to ExifTool stay_open and support for > 1
child processes.
Starting the perl version of ExifTool is expensive, and is especially expensive on the Windows version of ExifTool.
On Windows, a distribution of Perl and the ~1000 files that make up ExifTool are extracted into a temporary directory for every invocation. Windows virus scanners that wedge reads on these files until they've been determined to be safe make this approach even more costly.
Using -stay_open we can reuse a single instance of ExifTool across all
requests, which drops response latency dramatically.
The exiftool singleton is configured with a maxProcs of 1; no more than 1
child process of ExifTool will be spawned, even if there are many read requests
outstanding.
If you want higher throughput, instantiate your own singleton reference of
ExifTool with a higher maxProcs. Note that exceeding your cpu count won't
increase throughput, and that each child process consumes between 10 and 50 MB
of RAM.
You may want to call .end() on your singleton reference when your script
terminates. This gracefully shuts down all child processes.
Generally, EXIF tags encode dates and times with no timezone offset. Presumably the time is captured in local time, but this means parsing the same file in different parts of the world results in a different absolute timestamp for the same file.
Rather than returning a Date which always includes a timezone, this library returns classes that encode the date, the time of day, or both, with an optional tzoffset. It's up to you, then, to do what's right.
In many cases, though, a tzoffset can be determined, either by the composite
TimeZone tag, or by looking at the difference between the local
DateTimeOriginal and GPSDateTime tags. GPSDateTime is present in most
smartphone images.
If a tzoffset can be determined, it is encoded in all related ExifDateTime
tags for those files.
Official EXIF tag names
are PascalCased, like
AFPointSelected and ISO. ("Fixing" the field names to be camelCase, would
result in ungainly aFPointSelected and iSO atrocities).
The tags.ts file is autogenerated by parsing through images of more than 3,000
different camera makes and models taken from the ExifTool site. It groups tags,
their type, frequency, and example values such that your IDE can autocomplete.
Note that tag existence and types is not guaranteed. If parsing fails (for, example, and datetime string), the raw string will be returned. Consuming code should verify both existence and type as reasonable for safety.
debug is used with the
exiftool-vendored prefix.
I wanted to include the ExifTool's version number explicitly in the version number, but npm requires strict compliance with SemVer. Given that ExifTool sometimes includes patch releases, there aren't always enough spots to encode an API version and the ExifTool version.
Given those constraints, version numbers follow standard SemVer, with the following scheme:
API.UPDATE.PATCH
API is incremented forUPDATE is incremented forPATCH is incremented fortaskTimeoutMillis, which will cause the promise to be rejected if
exiftool takes longer than this value to parse the file. Note that this
timeout only starts "ticking" when the task is enqueued to an idle ExifTool
process.onIdle method every onIdleIntervalMillis (defaults to every 10
seconds) to ensure all requested tasks are serviced.ECONN or ECONNRESET is raised from the child process (which seems to
happen for roughly 1% of requests), the current task is re-enqueued and the
current exiftool process is recycled.Tags definitions using more (6,412!) sample image files
(via npm run mktags ~/sample-images), including many RAW image types
(like .ORF, .CR2, and .NEF).maxReuses before exiftool processes are recycledgps.toDate is not a function.kill() on .end() in case the stdin command was missed by ExifToolupdate/io.ts error message didn't handle null statuscodes properlyupdate/mktags.ts had a counting bug exposed by TS 2.2.on("error") added to the process itself, only on stderr of the child
process).Orientation is rendered as a string by
ExifTool,
which was surprising (to me, at least). By exposing optional args in
ExifTool.read, the caller can choose how ExifTool renders tag values.LANG and LC_ environment variables were passed through to exiftool (and
subsequently, perl). These are now explicitly unset when exec'ing ExifTool,
both to ensure tag names aren't internationalized, and to prevent perl errors
from bubbling up to the caller due to missing locales.extractBinaryTag exposed because there are a lot of binary tags (and
they aren't all embedded images)JpgFromRaw was missing in Tag (no raw images were in the example corpus!)extractJpgFromRaw implemented to pull out EXIF-embedded images from RAW formatsextractThumbnail and extractPreview implemented to pull out EXIF-embedded imageslogger to debugplatform-dependent-modules.
npm warnings
aren't awesome.npm's os-specific optionalDependencies rather than platform-dependent-modules.process) name-collided on the globals imported by ElectronTag.Error exposed for unsupported file types.ExifTool.end(), which left child ExifTool
processes running. The constructor to ExifTool now adds a shutdown hook to
send all child processes a shutdown signal.toString() for all date/time typesmaxProcs ctor paramExifTimeZoneOffset to handle the TimeZone composite tagš±āØ Initial Release. Packages ExifTool v10.31.
v2.15.0
FAQs
Efficient, cross-platform access to ExifTool
The npm package exiftool-vendored receives a total of 17,020 weekly downloads. As such, exiftool-vendored popularity was classified as popular.
We found that exiftool-vendored demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago.Ā It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
OpenSSF has published OSPS Baseline, an initiative designed to establish a minimum set of security-related best practices for open source software projects.
Security News
Michigan TypeScript founder Dimitri Mitropoulos implements WebAssembly runtime in TypeScript types, enabling Doom to run after processing 177 terabytes of type definitions.
Security News
vlt's new "reproduce" tool verifies npm packages against their source code, outperforming traditional provenance adoption in the JavaScript ecosystem.