Use “Import the roster (CSV)” in Recued. Add everyone to the roster from a spreadsheet in one go — their key, the name messages should use, and their email address — instead of typing each person in after the first scan.
Import the roster (CSV)
Use “Import the roster (CSV)” in Recued. Add everyone to the roster from a spreadsheet in one go — their key, the name messages should use, and their email address — instead of typing each person in after the first scan.
Complete workflow
Use Photo Attribution in Recued to match one event's photos to the people you know, write a warm line for each picture, review them, and send everyone their own. Faces are matched on your machine; your photos are never copied; sending asks first. First install two programs on the server: face_recognition (pipx) and libvips (brew install vips). Then allow their actions on each tool pack's Access tab. Open “Scan an event folder” for the rest of the setup.
You are viewing one recipe in this workflow. Installing it opens the complete pack so its other recipes and background automations arrive together.
Use “Scan an event folder” in Recued. Compare every photo in one event folder against the people you know, and record who appears in each picture. Photos stay where they are and are never copied. Matching happens on your own machine.
Use “Write the photo lines” in Recued. Look at each scanned photo and write one warm line naming the people recognised in it. A small copy with its embedded details removed is what the model sees, and the original is never sent. Run it again until the queue is empty.
Use “The roster” in Recued. See everyone Recued can recognise, whether each person can actually be written to, and who has been retired — and open any of them from here, which is the only way in to a person.
Use “Review photos before sending” in Recued. List the photos waiting for a look, with the line that will arrive alongside each one and the names it was written for. Open a photo to approve it, rewrite the line, or leave it out.
Use “Review one photo” in Recued. See the picture itself beside the names Recued matched in it, correct the line it wrote, and say whether it is ready to send — the one place a wrong name or a wrong sentence can be caught before it reaches somebody.
Show all 16 recipes
Use “Look at one person” in Recued. See who a roster entry actually is — their reference photo shown from your own folder, beside the name and address Recued will use for them — so a wrong or duplicated face is something you can see rather than guess at.
Use “Set someone's details” in Recued. Fill in an email address and the name that messages should use for one person on your roster. A field left blank keeps what is already there rather than clearing it. The key derived from their reference photo cannot be changed.
Use “Retire a person” in Recued. Take somebody off the roster without deleting anything they are attached to — a duplicate left behind by a renamed reference photo, or someone who should not be sent to any more. Their photos stay on record; they simply stop being matched and stop being sent to.
Use “Export the roster (CSV)” in Recued. Copy out everyone on the roster as a spreadsheet, or - on an empty roster - get the column headings the importer expects, so you can fill them in and import the list instead of typing it.
Use “See who is ready to receive” in Recued. List everyone with approved photos waiting, and separately everyone recognised who has no email address yet. Send each person from here. Nobody is dropped quietly, because a missing address is the usual reason a photo never arrives.
Use “Re-describe a person” in Recued. After changing someone's name, rebuild the stored names on their photos and queue those photos to be written again. Photos already approved are left alone and counted, because somebody signed those off.
Use “Skip a photo” in Recued. Leave one photo out of the sending queue and release everyone who was waiting on it. Their other photos are untouched, so this cancels one picture for everyone in it rather than cancelling a person.
Use “Send one person their photos” in Recued. Send one person a single message carrying every photo of them that has been approved. A fresh copy of each picture is made with its embedded details removed, and that copy is what travels.
Use “Records runtime” in Recued. It helps you complete this workflow using the connections and settings you choose.
Use “See what has been delivered” in Recued. Show who has received which photo and when, one row per person per picture, with the message it arrived under. It reads information without changing anything.
What this does
Adds people to the roster from a spreadsheet, so you are not typing an address in for each person after the first scan.
One approval covers the whole file.
Getting the file right
Run Export the roster (CSV) first. On an empty roster it gives you exactly one line — the column headings this importer expects. Paste that into a spreadsheet, fill in a row per person, save as CSV, and import it. Nothing to spell correctly, because the headings came from the pack rather than from a readme.
Already have a list in another spreadsheet? Open the import from the pack, choose the file, and match the key, the name and the email to its own columns — the choices are read from the file's header row, so they cannot be misspelled either.
The columns
The key is the identity, and it has to match the reference photo's file name in your roster folder without the extension. A file called 001.jpg means a key of 001; a file called Maggie Chen.jpg means a key of Maggie Chen. Get this wrong and the import still succeeds — you simply end up with a person nobody is ever matched to.
The name is what messages say. It is free to be different from the key, and that is the point: the file name only has to be stable, never pretty.
The email is what makes someone sendable. A person imported without one is recorded normally and just cannot be sent to until you add it.
What it checks, and what only you can judge
This roster is self-contained. It does not read your contacts, so nothing outside it can tell two entries apart — the checking is all here.
The same key twice is refused outright. The key is the identity, so the first row wins and the second is reported with its line number. Nothing is silently overwritten.
Two keys sharing one email address are both kept, and listed. That is deliberate: family@… used by two people in a household is a real roster, and merging them automatically would destroy it. Only you can tell one person entered twice from two people at one address. Retire whichever is wrong.
A blank key is recorded and counted separately. Nothing can ever match it — a scan only ever produces a name — so it sits on the roster doing nothing until you retire it.
Importing the same file twice is safe
A row whose key already exists is never added a second time, so a corrected export can be re-run without making duplicate people. If the row is identical to the one already held, that is all that happens — it counts as already on the roster.
When somebody's details have changed, you decide
If a row's key matches somebody already on the roster but the details differ — a new address, a corrected name — the import asks you in advance what that should mean. There are three answers and the right one depends on which list is more current, yours or the file's:
- Tell me about them (the default) — nothing is written for that person and
they are listed with their line number. Use this when you do not yet know which version is right. Nothing can be lost by choosing it.
- Keep what I already have — the roster wins. The file's version is ignored and
the person is counted under Left as they were. Use this when you have been correcting people by hand and the file is the older list.
- Use what the file says — the file wins and the person's details are replaced.
They are counted under Updated from the file. Use this when the file is the system of record and your roster has drifted from it.
⚠ Only the columns the file actually carries are replaced. A column you did not map is not touched, so choosing use what the file says cannot blank out information the file never mentioned. The key itself is never rewritten — it is the identity, and a row with a different key is a different person.
⚠ There is no undo. Use what the file says replaces what was there. Run it with Check first turned on to see how many people it would change before it does.
To change one person without importing anything, use Set a person's contact.
Check first
The guided import always rehearses before it writes. From the plain form, turn on Check first. Every line is read and checked, the counts come back exactly as they would, and the first rows are shown as they would be written — but nothing is.
How it works
Inspect the data fetches, transforms, gates, and output this recipe runs.
Settings
Configurable at install. Defaults shown — change them anytime in Recued.
file
setting
=
[object Object]
delimiter
setting
=
,
column key
setting
=
key
check first
setting
=
false
column name
setting
=
name
on conflict
setting
=
tell me about them
column email
setting
=
email
column real name
setting
=
full name
Uses (3 operations)
core.storage.data-file-read
recued-core.photo-attribution.face_profile.import
recued-core.photo-attribution.face_profile.search
Trust & control
What installing this recipe would let it do. Recued grants these permissions at install — review them there before approving.