Photos that only carry a car number in their metadata are hard to sell twice: once at delivery, and never again from your archive. A team or sponsor searching your library months later for "car 7, [event name]" won't find it if the file only ever got tagged "7" — and a co-driver whose name never made it into a single caption has no reason to think your archive has anything of them at all.
Understanding the problem
Metadata tagging is writing the fields that make a photo findable — caption, keywords, and the standard EXIF/XMP/IPTC blocks — into the file itself, not just the folder it sits in. In rally, the identifying information is a car number plus two names (driver and co-driver), sometimes a team and a class, all of which come from the entry list rather than anything visible in the frame beyond the number.
Rally income is built on crews, co-drivers, and their sponsors being able to find their own photos, weeks or seasons after the event. A file whose metadata only says "car 7" is technically tagged but practically unsearchable to anyone who doesn't already know that number by heart — and a co-driver who's never named in a caption is a sale you never make, even though they're standing right there in the photo.
In this sport specifically
A circuit race ties one driver to one number for the session; rally ties two people to that number, and both are names a delivery spec or a sponsor contract may require. Multi-day events compound this: three days of stage folders need the same keyword structure applied consistently, or your season archive ends up with three different captioning conventions for the same crew.
Where it shows up
A team press officer asks for every photo of car 7 at the end of day three, across all four stages shot that day. · very common
If captions only carry the car number, the press officer has to cross-reference their own entry list against your filenames — work that should have happened once, on your side, at import.
A co-driver's management reaches out months after the event looking for any photos featuring their client. · common
If the co-driver's name was never written into the caption or keywords — only the driver's, or just the car number — a name search on your archive turns up nothing, even though the photos exist.
A photo agency or wire service delivery spec requires structured IPTC fields (event, location, date, subject names) before they'll accept a submission. · occasional
Typing those fields per photo, per stage, across a multi-day event isn't realistic by hand, so photographers either skip agency delivery or spend hours on data entry instead of shooting or editing.
A photographer covers the same championship across a season and wants their archive searchable by crew across every round, not just within one event's folder. · occasional
Without a consistent keyword structure applied automatically at every event, the season archive ends up with inconsistent tagging conventions that make cross-event search unreliable.
Traditional approaches, and why they fall short
Caption and keyword each photo by hand in Lightroom or Photo Mechanic, cross-referencing the entry list for driver and co-driver names as you go
Realistically adds significant time on top of culling and editing, scaled to however many stage folders the event produced · As accurate as your entry list and your attention — reliable when you're fresh, more error-prone typing the same two names hundreds of times by the third day
It's manual data entry, not photography, and it competes directly with the time you have to actually edit and deliver.
Tag the car number only, and let the buyer or team figure out which names go with it
Minutes — effectively just a filename or single keyword per folder · Not applicable — this doesn't identify the crew at all, just the car
It defers the real work to the buyer, who usually won't do it. A file findable only by a number nobody outside your own workflow remembers isn't really findable.
Apply a saved keyword set (event name, series, sponsor) to the whole folder, without per-photo car or crew detail
Minutes per folder up front · Covers the event-level fields but nothing crew-specific
It solves generic discoverability ("WRC Rally Sweden 2026") but not the thing a crew, sponsor, or team actually searches for: their own name.
How RaceTagger handles it
RaceTagger detects the competition number on each car in each photo and matches it against the entry list CSV you upload for the event. Rally is set up as a crew-based entry, so a CSV with driver and co-driver columns — plus any other columns you include, such as team or class — carries both names into the photo's caption and keywords, not just the driver's. The result is written straight into each file's EXIF/XMP/IPTC fields, in JPEG or RAW (via the embedded preview), so the metadata travels with the file into your DAM, delivery platform, or wire submission. A number that doesn't match a current entry list row comes back unmatched — no caption is written — rather than guessing.
Key advantage
The entry list becomes the metadata schema. Every matched photo gets the same structured fields — car number, driver, co-driver, and whatever else you included — without you typing a single name twice, and that structure stays consistent across every stage folder and every day of a multi-day event.
- Good conditions
- A clearly readable competition number matched against a current, crew-complete entry list writes a full driver-and-co-driver caption reliably
- Challenging
- A readable number that isn't yet in your entry list — a late entry, for instance — comes back unmatched rather than tagged with the wrong or missing crew
- Worst case
- A number with nothing legible left on the panel gets no caption at all and is flagged for review, rather than a guessed name landing in the metadata
Import the event's entry list once, with driver and co-driver columns mapped, before you start tagging. Queue each stage folder as its own batch as it comes off the card; the written metadata is what your editing tool, DAM, or delivery platform reads from that point forward — your attention goes to the frames flagged as unmatched rather than retyping names on the ones that already matched cleanly.
Manual vs OCR vs AI vision
| Metric | Manual | Basic OCR | RaceTagger |
|---|---|---|---|
| Time to caption a full stage folder with driver and co-driver names | Significant hands-on time, cross-referencing the entry list photo by photo | Still needs a manual pass to attach names — OCR alone reads a number, not a crew | Batch-matched against the entry list automatically; your time goes to the unmatched frames |
| Co-driver name coverage | Depends on whether you remember to type it every time, for every photo | Not addressed — number recognition doesn't include entry-list names | Written automatically whenever the co-driver column is mapped in your entry list CSV |
| Consistency across a multi-day or multi-round season archive | Varies with fatigue and whichever convention you were using that day | No structured metadata output to be consistent about | Same entry-list-driven fields applied the same way every stage, every round |
| RAW file handling | Large files slow down manual review and captioning tools | Depends on the tool — some require a JPEG export first | Reads RAW via the embedded preview, no pre-conversion needed |
| Cost model | Your time, photo by photo, for the whole event | Compute cost plus the manual name-entry pass it still requires | Credits — 1 credit per photo analyzed; new accounts start with free credits |
Practical tips
- 1
Map your entry list's driver and co-driver columns explicitly at import, not just the car number
The columns you map are what ends up in the caption — skipping the co-driver column at setup means every photo comes back driver-only.
- 2
Decide before the event which fields belong in the caption (human-readable) versus keywords (searchable) — driver, co-driver, team, event, class
A caption that reads like a sentence and a keyword list built for search serve different buyers; setting the mapping once saves reworking it stage by stage.
- 3
Keep a consistent event-name and keyword format across every round of a season, not just within one event
Season-long search only works if the same event, series, and crew fields are written the same way every time — a naming convention set once at the start of the season pays off in every later search.
- 4
Re-import the entry list if it changes mid-event, and re-run tagging for that stage's folder
A late entry or a withdrawal that isn't reflected in your list means that stage's photos won't carry the crew's names until you update it.
- 5
Check whether your delivery platform or agency spec reads IPTC, XMP, or both before you finalize your field mapping
Some delivery pipelines and DAMs prioritize one metadata standard over the other — confirming this once avoids a caption that's written but not actually read on the receiving end.
The takeaway
A rally car number is half the story — the entry list is what turns it into two searchable names. Mapping driver and co-driver columns once at import, and letting that structure write itself into every photo's metadata across every stage, is what makes an archive findable by the people actually looking for themselves in it.
Stop typing the co-driver's name in twice a day
Try it free on a previous rally event's stage folders — see the driver and co-driver names land in the caption automatically. 1 credit covers 1 photo, and new accounts start with free credits.
Try it free →Questions photographers ask
Does it write both the driver's and co-driver's names, or just the driver's?
Both, as long as your entry list CSV has separate driver and co-driver columns mapped at import. Rally is set up as a crew-based entry, so both names carry into the caption and keywords together.
What happens to photos where the car number can't be read at all?
No caption is written and the photo is flagged for manual review, rather than guessing a crew from context. It's honest about what it can't read.
Can I control which fields go into the caption versus the keywords?
Yes — you map your entry list columns (driver, co-driver, team, class, whatever you include) at import, and that mapping determines what lands in each metadata field.
Does my delivery platform need to support both IPTC and XMP, or just one?
RaceTagger writes to EXIF/XMP/IPTC, but which fields your specific delivery platform or DAM actually reads depends on that tool — worth checking your spec once before an event so your field mapping matches what's read on the receiving end.
If the entry list changes mid-event, do I need to re-tag photos I already processed?
Only the stage folders affected by the change. Re-import the updated entry list and re-run tagging for that stage; folders already matched against a correct list don't need to be redone.
Keep reading