Build a Searchable Visual-Reference Library Without Copying Every Image Into Every Project

A reference collection becomes reusable the moment you can ask it a question it was never organised for. Not "show me the folder from the March job," but "show me every still where something passes across a tabletop."

That capability does not come from copying files into a tidier set of folders. It comes from splitting one thing into four. The source file is the image itself, sitting where you put it, untouched. The catalog record is the database entry that knows the file exists. Tags are the attributes you assign. A saved query is a stored question that reads those tags and returns whatever currently matches. Only the first of those four is an image. The other three are the index, and the index is what you are actually building.

Before any of it: findability is not permission. A saved query that returns a client's unreleased product shot has told you the search works. It has told you nothing about whether you may keep, share or reuse that frame. Those are separate questions with separate owners, and this article does not answer them. It assumes you have already sorted out what you are allowed to hold and use, and starts from there.

What belongs in the catalog

Pick the collection deliberately rather than by default. The safest starting point is material you own or that is unambiguously reusable — your own stills, your own test footage, open-licensed images whose terms you have recorded. Then decide, in advance, what stays out.

Restricted client material is the case that catches people. The instinct is to import it and add a "confidential" tag, then filter it out of everyday searches. That works right up until someone saves a query that doesn't include the filter, or a colleague imports the catalog database, or the tag gets renamed during a cleanup. A tag is a label, not a lock. The reliable boundary is placement: a separate catalog database, or a separate machine, or simply outside the tool. Decide that before you demonstrate anything to anyone.

Folder structure remains useful for the originals — you need to know where a file physically lives, and you need enough context to find it again if the catalog goes away. But folders are a poor retrieval system, because a file lives in exactly one of them. A still of a hand passing a frosted glass over a table is a tabletop image and a passing image and a translucent-material image, and a folder tree forces you to pick one. That is the whole reason the catalog layer exists.

Tags that describe what a camera can see

Build the vocabulary from questions you have genuinely asked, not from adjectives you might one day need. digiKam's manual describes a hierarchical tag tree whose categories sit independent of folder location (Tags View), which is precisely the property you want: one source file, filed once, answering several different questions later.

The tags worth creating name observable relationships. Something passing between hands or across frame. A product resting on a surface. Two faces sharing an eyeline. A foreground object partly blocking the subject. A reflection carrying the product. A translucent material between camera and subject. Each of these is a thing you can point at in a frame and argue about briefly. "Aspirational," "premium" and "moody" are interpretations — useful in a conversation, unreliable as a filter, because two researchers will not apply them the same way twice. If you need them, put them in a caption or notes field. Don't make them a query axis.

Keep the vocabulary shallow and orthogonal. A nested path like Tabletop / Translucent / Passing is one tag in one branch, and the moment a still is a passing shot over a surface you have to decide whether it belongs there or somewhere else, which is the folder problem wearing a new hat. Separately applied tags for passing, tabletop and translucent let the same image sit in all three sets, and let your queries combine them later. One image carrying several tags is a feature. One image filed in one deep branch is a limitation you'll rediscover in six months.

Source and use information belongs in its own fields, not smuggled into aesthetic labels. Where the file came from, who holds it, when you captured it, what it was used for — these are facts about the image, not properties of its content, and mixing them into the tag tree produces searches like "translucent + licensed 2024," which is not a visual question. Record what you know about origin and use; leave the judgement about reuse to the process that handles it. A practical note: if you already have duplicated reference folders from previous jobs, consolidating or deleting them is a different job with its own risks. Nothing here requires you to touch them.

Save the question instead of another copy

The expensive habit is duplicating files. Every project gets its own reference folder, and the good passing shot from last spring gets copied into this spring's treatment folder, and now the same image exists in four places with four slightly different sets of tags, and a correction to any of them is a correction to one quarter of the problem.

A saved query replaces the copy. digiKam's Search View documents Quick Search and Advanced Search, where conditions on metadata combine, and saved searches retain a query rather than a hand-assembled collection (Search View). The saved search is a live filter. It stores the criteria, not the results. Add a tag to an image and the image joins the relevant saved searches; remove one and it leaves. No new file is created, and the library stays at its original count.

Two mechanical details matter more than they look. First, Meet All and Meet Any are not the same thing, and the manual distinguishes them because a query that accidentally uses the wrong one returns a plausible, wrong set. Write down which one each saved query uses — in the query's name if the tool allows it, otherwise in a short note you keep alongside the catalog. Second, conditions can be grouped, which means a saved query is really a small expression: a grouped pair combined with something else. Read it the way you'd read arithmetic, and check the grouping rather than assuming left-to-right.

And keep the permission line intact here too. That a saved search returns an image means only that the tags match. Search membership is not usage rights, and treating a query result as a cleared reference set is how a well-organised library becomes a liability.

Know which layer holds what

Before you trust any of this outside the application, understand that three storage places are in play and they are not interchangeable.

The catalog database holds records, album membership, saved searches, and any rating, pick flag or grouping the application invented. The image file may hold embedded metadata. A sidecar — a small companion file, typically sharing the image's base name with a different extension — may hold the same metadata outside the image. digiKam's Metadata Settings page documents choices about writing to the sidecar only versus the image and sidecar together, which source to read from, pending or lazy writes, and how sidecars are named (Metadata Settings). Settings and file format together determine what actually gets persisted.

Two consequences follow directly.

A pending write can bite you at the worst moment. If tag changes are queued and not yet written, you can copy an image whose sidecar still describes the state before your edit. The copy is faithfully made and quietly wrong. Before any handoff, make sure the queue is empty and the write you expect has happened.

A read-source preference can make a field look missing when it is merely elsewhere. If the application reads from the embedded metadata in one context and the sidecar in another, the same file shows different values in the two places. That is a configuration difference, not data loss — but you won't know which one you're looking at unless you record the settings you used.

One more distinction worth holding on to: a backup of the catalog database is not a portable handoff. Restoring a backup recovers your catalog, with your saved searches, on an installation that understands that database. It does not produce a folder you can give to someone else. The two operations solve different problems, and conflating them is how people promise portability they haven't tested.

A twelve-image fixture with two saved queries

Everything below is a designed plan, not a performed test. The twelve stills, the catalog, the saved searches and the sidecar round trip have not been made or run. What I can do now is compute the expected results by hand, write them down, and describe what a real run would confirm or contradict. If you build the fixture yourself, use your own original images — that keeps the exercise entirely clear of the permission question this article doesn't decide.

Twelve original stills, deliberately overlapping, tagged across three observable devices: passing (P), tabletop (T), translucent (L). The table records both what each frame contains and the tags applied in the first pass.

One row is deliberately one tag short. Still 06's frame contains a hand entering at the edge to set that tool down, so passing belongs to it; the first pass never applied that tag. Leave the gap in place while you reproduce the baseline counts below. The edit section later in this article closes it, and what that edit does to the two queries is the point of the exercise.

Three overlapping tags is the point: 01 and 08 carry all three, 06 carries only one, 12 carries none.

Now the two saved queries, with their expected membership written out before anything is run.

Query A — passing AND tabletop (Meet All): 01, 02, 08, 09 → four images.

Query B — passing OR translucent (Meet Any): 01, 02, 03, 04, 05, 07, 08, 09, 10, 11 → ten images.

Several checks fall out of that without opening the application. Query B is larger than Query A because OR admits everything on either axis, including 05, 07 and 10, which have nothing passing in them at all. Neither query returns 06 or 12, and between them the two queries reach ten of the twelve — so if a run of both queries accounts for all twelve stills, something has been joined incorrectly, most likely a group set to Meet Any when it should be Meet All. And 12, with no tags, is invisible to every query you will ever write. It is in the library and unreachable, which is worth seeing once.

Changing one tag, without a new file

Here is the edit that demonstrates the whole idea. Close the gap noted in the table: still 06, whose frame has a hand entering at the edge to set a tool on the surface, never received the passing tag. Add it.

Predicted result before running: Query A gains 06 and returns five images — 01, 02, 06, 08, 09. Query B gains 06 as well and returns eleven. The library still holds twelve files. No image was copied, moved or renamed. One catalog record changed.

The reason both queries move is that 06 already carried tabletop and now carries passing, so it satisfies both the AND pair and the OR pair. A different change behaves differently. Take translucent off still 10 instead, on paper: Query B drops to nine images, because 10 was in that set only through the translucent axis. Query A does not move at all, because 10 was never on the passing axis. Before you look, you can say which saved queries should move and by how much. When the observed result matches the prediction, you have evidence that your query really is reading the tags you think it is. When it does not, you have found a misconfigured condition, a duplicate tag with a similar name, or a tag applied to the wrong file.

The handoff check: one image, both files, a separate context

A saved query is not a deliverable. Sooner or later an image has to leave — into another tool, another person's machine, another catalog — and the question is what travels with it.

Use still 01, because it carries all three tags plus a caption and a source note, making it the most demanding single test case in the set. Write down your hypothesis first, so the test can contradict you: keyword tags and a caption are the most likely things to arrive, since they map onto widely used metadata fields, while the branch structure of a hierarchical tag is the first thing to verify, because arrival as a flattened list is a common outcome. Saved searches, album membership and any catalog-only rating or pick flag are not image data at all. Nothing carries them; they are constructs of your database.

Then, in order: confirm the metadata write queue is empty; check which write route is selected for that image; copy the image and its sidecar together into a test folder, preserving the base-name pairing; and open or import that folder in a separate test context rather than another project. Compare field by field. Record what arrived, what didn't, and what arrived in a different shape. Leave the original in place throughout.

What you are producing is a short handoff note that travels with the files: the source, the application and version, the file format, the metadata route you used, and the fields that did or didn't survive. The originals stay home. The catalog stays home. What the recipient gets is the image plus whatever actually made the trip.

Two routes and an honest note

A working library of this kind is small and slightly boring. Twelve images, three tags, two saved queries you can explain without notes, and a one-paragraph record of what the handoff preserved. The value is recoverable visual knowledge — being able to ask for a passing shot over a surface and get a real answer — not tag volume.

Keep it that small until something demands growth. Add a tag when a question you have actually asked cannot be expressed with the ones you have. Add a saved query when you catch yourself rebuilding the same filter for the third time.

What remains to be done is the part no plan can substitute for: building the fixture in a named version of the application, watching Query A and Query B return what the truth table predicts, making that one tag edit and confirming the membership moves without a new file, and running the sidecar round trip into a separate context to see which fields arrive intact. Until that happens, everything above is a design with arithmetic attached. And even after it happens, one successful round trip proves what that route preserves in that application at that version. It does not prove that every field survives everywhere, and no documentation or database backup will tell you otherwise.

Frequently asked questions

What are the four parts of a reusable visual-reference library?

The source file is the image itself, untouched. The catalog record is the database entry that knows the file exists. Tags are the attributes you assign. A saved query is a stored question that reads those tags and returns whatever currently matches. Only the source file is an image; the other three are the index, and the index is what you are actually building.

How should I handle restricted client material?

A tag is a label, not a lock. The reliable boundary is placement: a separate catalog database, a separate machine, or simply outside the tool. Decide that before you demonstrate anything to anyone. Also, findability is not permission: a saved query returning an image means the tags match, not that you may keep, share, or reuse it.

What kinds of tags are worth creating?

Create tags that name observable relationships: something passing between hands or across frame, a product resting on a surface, two faces sharing an eyeline, a foreground object partly blocking the subject, a reflection carrying the product, or a translucent material between camera and subject. Keep the vocabulary shallow and orthogonal. “Aspirational” or “premium” are interpretations; put them in captions or notes instead of making them a query axis.

What does a saved query do, and what should I watch?

A saved query stores criteria, not results; it is a live filter. Add a tag and the image joins relevant saved searches; remove one and it leaves. No new file is created. Watch “Meet All” versus “Meet Any,” since the wrong one returns a plausible, wrong set, and check grouping as you would read a small expression. Search membership is not usage rights.

What should I understand before handing off an image?

The catalog database, image file, and sidecar are not interchangeable. A pending metadata write can mean you copy an image whose sidecar still describes an earlier state; empty the queue first. A read-source preference can make a field look missing when it is merely elsewhere. A backup restores your catalog, not a portable handoff. Saved searches, album membership, and catalog-only ratings are not image data and will not travel. One successful round trip proves only what that route preserves in that application at that version.

Further reading

• Trace a Treatment Reference Back to Its Source Before You Describe It — For the origin fields, this shows how to trace a saved image back to its maker, date and credit, keeping attribution separate from permission.
• Build a Searchable Script Concordance for a Series Bible — A parallel exercise for anyone tempted to trust query counts: it builds a searchable index over a script corpus and insists counts describe occurrences, not importance.