Technische specificaties
Hoe snel is SetTag nou echt, en houdt het een snelle shoot bij? Onderstaande cijfers zijn gemeten, niet geschat, losstaand van de app zelf met dezelfde code die SetTag ook gebruikt (dezelfde FSEvents-instellingen, dezelfde exiftool-aanroep).
Ondersteunde camera's en bestandstypen
| Merk | Bestandstypen |
|---|---|
| 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 (oudere modellen, bv. D-Lux 3) |
| Adobe DNG | DNG (o.a. sommige Pentax- en Ricoh-modellen) |
| Alle merken | JPEG, TIFF |
Hasselblad's kaartformaat .3FR wordt herkend maar kan niet getagd worden, dat is een beperking van exiftool zelf (het gereedschap dat SetTag gebruikt om metadata te schrijven), niet van SetTag. Mist je camera of bestandstype in deze lijst? Laat het ons weten via de verzoekenpagina.
In de praktijk getest, 19 augustus 2026: een echte tethered sessie via Lightroom Classic, 88 foto's over twee sets (Levi's en Tommy Hilfiger). Alle 88 zijn automatisch en correct getagd terwijl er werd doorgefotografeerd.
Ook getest met TETHER STUDIO, 22 augustus 2026: 59 RAW-bestanden in 41 seconden, allemaal automatisch en correct getagd. SetTag was daarbij steeds klaar vóórdat TETHER STUDIO zelf een voorbeeld van de foto had gegenereerd.
Detectie van een nieuw bestand
SetTag draait op FSEvents, het bestandssysteem van macOS zelf, niet op periodiek pollen. Zodra macOS het nieuwe bestand doorgeeft (macOS bundelt events zelf al in stapjes van maximaal 0,5 sec) ziet SetTag het.
Ingebouwde veiligheidspauze
Bewust ingebouwd: SetTag wacht tot de bestandsgrootte twee keer op rij gelijk is, zodat een bestand dat de camera of tethersoftware nog aan het wegschrijven is nooit halverwege wordt getagd.
Tag wegschrijven
exiftool blijft continu open op de achtergrond in plaats van steeds opnieuw op te starten (dat scheelt zo'n 150-200 ms per keer). Na de eerste foto kost het wegschrijven van merk, model, kleur en locatie nog maar een paar milliseconden.
Bij een burst van veel foto's tegelijk
SetTag verwerkt tot 4 foto's tegelijk. Landen er meer in één keer, dan stapelen ze netjes op in de wachtrij in plaats van dat er iets wordt overgeslagen of gemist.
In de praktijk: bij normaal fashion-tempo (een paar frames per seconde, met tijd ertussen om te reviewen of te herpositioneren) komt SetTag hier nooit tegenaan. De grootste factor is niet de app, maar de bewuste veiligheidspauze die voorkomt dat een nog-schrijvend bestand verkeerd wordt getagd.
En de camera zelf?
De cijfers hierboven gaan over wat SetTag zelf doet, vanaf het moment dat een bestand in de watch folder staat. Wat de camera of tethersoftware nodig heeft om dat bestand daadwerkelijk weg te schrijven, valt daarbuiten, dat is geen SetTag-tijd maar cameratijd.
Dat verschilt flink per situatie: een JPEG is sneller weggeschreven dan een RAW, een snelle CFexpress- of UHS-II-kaart is sneller dan een oudere kaart, en niet elke camera of tetherverbinding is even snel. SetTag kan pas beginnen zodra het bestand er ligt, die schrijftijd komt dus bovenop de cijfers hierboven, en is de enige stap in de hele keten die SetTag zelf niet kan versnellen.
Hoe dit gemeten is
Gemeten met een burst van 50 testbestanden in een losse map, buiten de live app om, zodat er geen risico was voor echte shoot-data. Twee onderdelen zijn los getest: de FSEvents-detectie (dezelfde FSEventStreamCreate-instelling als in SetTag) en het wegschrijven via exiftool in stay-open modus (dezelfde IPTC/XMP-velden als SetTag echt schrijft).
Getest op een iMac M1, macOS 26.6.2, exiftool 13.50, augustus 2026. Resultaten hangen af van de Mac en kunnen op ander werk enigszins verschillen, de verhoudingen (detectie, veiligheidspauze, schrijftijd) blijven representatief.