Forty thousand images isn't a number to plan around. It's the point where scrolling already stopped working

Nobody sits down and decides to build a forty-thousand-image reference library on purpose — it's what a folder looks like after several years of a job that involves collecting references, spread across however many drives you've owned in that time. The question that actually matters at this size isn't "how do I organize all of this" — it's "how do I make it searchable without redoing years of collecting from scratch," and the honest answer is that you don't redo anything. You point a tool at the folders as they already exist and let a first pass read them.

That distinction matters more than it sounds like it should, because the alternative — the thing most people picture when they imagine "properly organizing" forty thousand images — is a weekend spent renaming, sorting into a fresh folder scheme, and re-filing everything by hand. Nobody with a library this size actually has that weekend, and the honest answer is that they shouldn't spend it that way even if they did: the folder structure that already exists, however inconsistent it looks, is the product of years of decisions that made sense at the time, and search is a better tool for finding things in it than a fresh reorganization would be.

1. Point it at the folder you already have, not a folder you build for it

This is worth stating as the very first step precisely because it's the one most people assume they need to skip — the instinct at this size is that something this large deserves a proper setup first. It doesn't. The setup is pointing it at what already exists.

There's no import step that requires restructuring anything first. Coii Ref indexes a folder where it sits — subfolders, whatever naming scheme you've used for a decade, all of it — and reads dimensions, EXIF and colour off each file without moving, copying or renaming a single one. If your forty thousand images live across a "Studio", a "Client work" and an "Old Mac backup" folder that have never been unified, none of that needs to change before you start.

2. Start the first pass and leave it alone

This is a background job you start and walk away from, not a foreground task you babysit. It reads every file once, writes a thumbnail and — for video — a proxy, and updates the database as it goes. There's nothing to tune and nothing that needs to finish before the rest of the app is usable; files that have already been read are searchable while the rest of the folder is still being worked through.

3. Expect video to take longer than stills, and plan the order accordingly

If part of your forty thousand is footage rather than photographs, that's the slower half of the pass — a proxy has to be written for each clip at canvas resolution, where a still only needs a thumbnail. If you're impatient to start searching a specific subset, pointing the tool at your stills folder first and adding the video folder afterward gets you a working library sooner without losing anything from the folder you add second.

4. Don't rush to tag everything before you've searched anything

The instinct at this scale is to feel like the library isn't "done" until every image has a tag. Resist it. EXIF and dimensions are already searchable the moment the first pass finishes, and that alone answers a surprising number of real questions:

type:image width:>4000                     large enough to actually use
type:video ext:mov added:<2024-01-01       older footage, by date
in:studio -has:notes                       one folder, not yet annotated

Tag the parts you search often, as you search them, rather than tagging the whole forty thousand up front on the theory that you'll need it later — most of it you won't, and the ones you do need get tagged the moment you go looking for them anyway.

5. Trust the watcher instead of re-running the whole index

After the first pass, the job that keeps forty thousand files accurate isn't a periodic re-import — it's the watcher, running continuously, turning a Finder rename or a moved subfolder into the smallest re-scan that makes the database true again. A file you renamed last week doesn't need you to do anything; the database already reflects it. This matters disproportionately at scale, because a library this size that needs a manual re-import every time you tidy a folder is one you'll stop tidying.

6. Handle drives that aren't always plugged in as a normal case, not an exception

A forty-thousand-image library rarely lives on one disk. If part of it is on an external drive that isn't always connected, that's fine — when it comes back online, the watcher reconciles what changed on it rather than treating every file as newly discovered. You don't need all your drives mounted at once for the parts that are connected to be fully searchable.

6.5 Resist the urge to consolidate everything onto one drive first

If your forty thousand images are spread across three or four drives, the instinct before indexing is often to consolidate everything onto one big drive first, so there's "just one place" to point the tool at. Skip that step. Indexing works the same whether it's reading one drive or four, and a consolidation project is exactly the kind of multi-day undertaking this whole approach exists to avoid. Point the tool at each drive's folder as a separate root if that's how they're organized, and let search work across all of them the same way it would if they were one.

7. Search across the whole thing with one line, regardless of which drive a result lives on

Once indexed, a query doesn't care which folder or which drive an image is actually sitting on — tag:any:texture,material rating:>=4 returns results from your internal disk and your external archive in the same grid. This is the payoff for the folder-based approach: the organization scheme you already had is still exactly what it was, and search sits on top of it rather than requiring you to consolidate everything into one place first.

7.5 Don't fight your existing folder names on the way in

If a decade of collecting has left you with folder names like 2019 stuff and misc 2, the temptation before indexing is to rename everything into a clean, consistent scheme first. Don't — that's the reorganization project this whole approach is meant to avoid, and a folder called misc 2 indexes exactly as well as one called Texture References. The folder name only matters as a label you read in Finder; once a file is indexed, what makes it findable is its EXIF, its dimensions, and whatever you tag and rate it with afterward, none of which cares what the enclosing folder happens to be called. Rename folders when you have a real reason to, not as a prerequisite for search to start working.

8. Give the first tagging pass a narrow, realistic scope

Once the index is done, the temptation is to try to tag the whole forty thousand in one long push. Don't. Pick the slice you actually need right now — this year's additions, one project's worth of folders, the images you've rated highest — and tag that slice properly instead of tagging everything shallowly. A library where a few thousand images are tagged well is more useful than one where forty thousand are tagged with a single generic label applied in a rush, because the second kind of tag doesn't actually narrow anything down when you search it.

9. Let the first index double as a light cleanup pass

Because indexing reads dimensions and EXIF off every file, it's a natural point to notice things you'd otherwise never see — a folder of images all saved at a suspiciously small size, a batch with no EXIF at all suggesting they came from a screenshot rather than a proper source, files with dimensions too small to be useful for the work you actually do. None of this requires a separate pass; it falls out of filters you'd run anyway once the index is done, like width:<500 to see what's actually too small to keep bothering with.

What to do once forty thousand becomes a hundred thousand

The workflow above doesn't change at ten times the size — it's the same first pass, the same watcher, the same query line — but the discipline around when you tag starts to matter more.

It's worth being honest about what actually changes and what doesn't as a library grows past this point. What doesn't change: the first index is still a background pass, the watcher still handles everything afterward, and a query still returns results as fast as it did at a tenth the size, since it's filtering an index rather than re-scanning files on disk each time. What does change is your own relationship to the material — nobody has a mental map of a hundred thousand images the way they might have of a few thousand, and the query line stops being a convenience and becomes the only realistic way you'll ever find anything again. That's not a problem to solve; it's the actual shape of what a library this size is, and it's why getting the tagging habit right early, on a small enough slice to be realistic, matters more than any one-time organizational decision about folder structure ever will. At six figures of images, tagging everything is not a realistic goal at any point, and it was never the plan; the goal is a library where the fraction you've actually tagged and rated is the fraction you actually use, and the rest sits there, indexed and searchable by type, date and dimensions, waiting for the day you go looking for it specifically. Split genuinely unrelated bodies of work — old client projects you'll probably never reopen — into their own workspace folder rather than one growing pile, so a search for this year's project doesn't have to filter past a decade of ones that are finished.

If your images are spread across several drives that come and go, organizing references across multiple external drives goes further into that specific setup. For how this compares to a tool with an on-device auto-tagger that can suggest tags across a library this size automatically — a real capability Coii Ref doesn't have — the comparison with refern covers that gap honestly, including where it matters most for an untagged library this large. And if proxies and what they're actually for is unclear, what a proxy file is explains the piece that makes video at this scale behave like stills do.

VFX artists and anyone working with large plate libraries tend to hit this scale earliest, simply because a project's worth of footage generates more files than most people's entire personal collection — reference libraries for VFX artists goes into that specific case. And once the index is done and you're deciding what's worth tagging first, rating and filtering your best references is the natural next step — rating is often faster than tagging and narrows the "what do I even start with" problem down quickly.

A library this size is exactly the case worth testing before paying for anything — the trial runs thirty days with every feature on, long enough to index a real folder this large and see how search actually performs against your own material rather than a demo.

Point it at the real thing on day one rather than a small test folder — the first index taking a while in the background is the only part of this workflow that scales with size, and starting it immediately means it's already done, or well underway, by the time you're ready to actually evaluate whether the search and tagging on top of it are worth paying for. A month is enough time to index the whole library, tag a realistic slice of it, and know for certain whether this fits how you actually work before the trial runs out.