Technical specifications
How fast is SetTag really, and can it keep up with a fast shoot? The numbers below are measured, not estimated, run standalone using the exact same code SetTag itself uses (same FSEvents settings, same exiftool call).
Supported cameras and file types
| Brand | File types |
|---|---|
| Canon | CR3, CR2 |
| Nikon | NEF, NRW |
| Sony | ARW |
| Fujifilm | RAF |
| Panasonic | RW2 |
| Olympus / OM System | ORF |
| Hasselblad | FFF (tethered via Phocus) |
| Leica | RWL, DNG, RAW (older models, e.g. D-Lux 3) |
| Adobe DNG | DNG (incl. some Pentax and Ricoh models) |
| All brands | JPEG, TIFF |
Hasselblad's card format .3FR is recognised but can't be tagged, that's a limitation of exiftool itself (the tool SetTag uses to write metadata), not of SetTag. Missing your camera or file type from this list? Let us know via the requests page.
Tested in practice, August 19, 2026: a real tethered session via Lightroom Classic, 88 photos across two sets (Levi's and Tommy Hilfiger). All 88 were automatically and correctly tagged while shooting continued.
Also tested with TETHER STUDIO, August 22, 2026: 59 RAW files in 41 seconds, all automatically and correctly tagged. SetTag was consistently done before TETHER STUDIO itself had even generated a preview of the photo.
Detecting a new file
SetTag runs on FSEvents, macOS's own filesystem mechanism, not periodic polling. As soon as macOS reports the new file (macOS itself batches events in windows of up to 0.5 sec) SetTag sees it.
Built-in safety pause
Deliberately built in: SetTag waits until the file size is unchanged across two checks in a row, so a file the camera or tethering software is still writing never gets tagged halfway through.
Writing the tag
exiftool stays running in the background instead of restarting for every photo (that saves roughly 150-200 ms each time). After the first photo, writing brand, model, colour and location costs only a few milliseconds.
During a burst of many photos at once
SetTag processes up to 4 photos at once. If more land at the same moment, they queue up cleanly instead of anything being skipped or lost.
In practice: at normal fashion-shoot pace (a few frames per second, with time in between to review or reposition), SetTag never runs up against this. The biggest factor isn't the app itself, but the deliberate safety pause that prevents a still-writing file from being tagged incorrectly.
And the camera itself?
The numbers above cover what SetTag itself does, from the moment a file lands in the watch folder. What the camera or tethering software needs to actually write that file falls outside of that, it's camera time, not SetTag time.
That varies a fair bit by situation: a JPEG writes faster than a RAW, a fast CFexpress or UHS-II card is faster than an older one, and not every camera or tethering connection is equally fast. SetTag can only start once the file is actually there, so that write time comes on top of the numbers above, and it's the one step in the whole chain SetTag itself can't speed up.
How this was measured
Measured with a burst of 50 test files in a separate folder, outside the live app, so there was no risk to real shoot data. Two parts were tested separately: FSEvents detection (same FSEventStreamCreate setting SetTag uses) and the exiftool stay-open write (same IPTC/XMP fields SetTag actually writes).
Tested on an iMac M1, macOS 26.6.2, exiftool 13.50, August 2026. Results depend on the Mac and may vary slightly under different workloads; the relative proportions (detection, safety pause, write time) remain representative.