Clips get the same query line as everything else on the board

Most advice about organizing references quietly assumes every file is a still. That falls apart the moment a folder has motion reference, animatics or filmed lighting tests sitting next to the photographs — Finder's preview column stutters on the fifth clip, thumbnails go blank until you click, and the impulse is to build a second, video-only system that never actually gets built. The better answer is not a separate system: it's treating a clip as a file with a few more properties than a still, indexed the same pass, findable with the same line.

That only works if the tool doing the indexing actually reads video and image files in one pass rather than treating video as an afterthought bolted onto an image organizer. Coii Ref does — a .mov sitting next to a .heic in the same folder gets the same treatment: dimensions read, a thumbnail generated, and a place in the index it never has to leave.

The reason this matters more than it sounds like it should is that reference work rarely separates cleanly into "the video project" and "the image project." A lighting study shot as a short pan is also a still-frame reference the moment you screenshot the right instant; a motion-capture clip sits on the same board as the concept art it's informing. Any system that makes video a second-class citizen — its own folder, its own naming convention, its own mental bucket — recreates exactly the divide that a single reference board is supposed to erase. The steps below assume the opposite: that a clip belongs wherever the still it's related to belongs, and that the search reaching one should reach the other without switching modes.

Step 1: Point one root at the mixed folder, not two

If clips and stills already live together — a shoot folder with both photographs and a few reference takes, an animation project with animatics next to concept art — register that folder once rather than splitting it into an images library and a separate video library. The first pass reads both in the same sweep.

Splitting video into its own workspace only makes sense when it genuinely lives somewhere else on disk — a scratch drive for raw footage, say. Where it already sits beside the stills, one root keeps the whole shoot searchable in a single query instead of two.

Step 2: Search clips with the keys you already know

type:video and ext:mov work exactly the way type:image and ext:heic do — same keys, same syntax, no video-specific mode to learn separately.

That consistency is the actual point of indexing video at all, rather than just leaving clips in Finder and images in a proper library. A query built for stills — a tag filter, a date range, a rating floor — carries straight over to type:video with nothing rewritten, because both media types were read by the same pass and are stored in the same index.

Step 3: Tag and rate clips the way you already do for stills

A clip gets a rating and a tag vocabulary the same way an image does. There's no separate "video tags" list to maintain, which matters most on a project where a clip and a still are documenting the exact same idea — a lighting reference shot as both a still frame and a short pan, say, and you want both to answer to the same tag.

Building a tag vocabulary that holds up applies here without modification — the advice about keeping the list small and reserving tags for genuinely subjective distinctions doesn't change because some of the files being tagged happen to move.

Step 4: Write notes for the moment, not just the file

A clip often has one moment worth remembering rather than the whole thing — a specific camera move at the two-minute mark, a lighting change partway through. A short note on the file — "the pan at 1:40 is the reference, skip the rest" — does more work than a tag ever could, because it's specific to one file rather than a category several files share.

Step 5: Put clips on a canvas the same way as a still

A canvas doesn't distinguish between a still plate and a video plate — both get placed, both get arranged next to the reference they're informing. What changes is the resolution behind the thumbnail: proxies are written at the canvas's own resolution rather than the source file's, so a board carrying a dozen 4K clips scrolls exactly like a board of photographs instead of stuttering to load full-resolution footage nobody needs to see at full size while arranging a layout.

Step 6: Review a shortlist without opening a separate player

Once a query narrows a folder down to a handful of candidates, the next question is usually "which of these is actually the right clip," and that's a review problem rather than a search problem. Playing a shortlisted clip inline, one after another, without leaving the grid or opening a separate video app for each file, is what turns a list of twelve results into a decision rather than twelve more files to individually double-click.

That inline playback is deliberately basic — enough to confirm a clip is the right one, not enough to trim or grade it. Anything beyond confirming which file is right belongs in dedicated video software, which is exactly the boundary the next section draws explicitly.

Where this is a draw, not a win

It would be dishonest to leave this at "video works here" without saying where it works better somewhere else. refern indexes video too, and its playback is built out further than this app's: frame-by-frame stepping, scrubbing on hover, and exporting an A-B section straight from the canvas — their own description of it, checked today. None of that exists here. What's written above is real — one index pass, one query line, one tag vocabulary, canvas-resolution proxies — but it's about finding and arranging clips, not editing them. Anyone whose actual need is frame-accurate scrubbing or trimming a section out of a clip is better served by refern or a dedicated video tool, and this page won't pretend otherwise.

Where this app still earns its place even for someone who also owns a heavier video tool is the part before playback: getting from "a folder of four hundred clips" to "the twelve that matter" in one query line, on the same index that already covers every still in the library. A dedicated video tool is rarely also a reference search engine for the images sitting next to that footage — the two jobs tend to live in separate applications regardless of which one wins on playback, and this app is built to be the one doing the finding rather than the one doing the editing.

A worked example: forty motion studies and no folder structure

A folder of forty short motion-capture reference clips, dumped flat with timestamped filenames and nothing else, is a common state for this kind of footage to arrive in. Registering the folder is a minute of work; the first pass reads dimensions, format and duration off every file without asking for a single tag. From there, a query narrows the forty down to whatever's actually relevant to today's task —

— and tagging becomes something that happens to the handful actually pulled onto a board, rather than a prerequisite standing between the folder and being useful.

Say three of those twelve end up genuinely useful for the project at hand. Tagging just those three, rating them, and dropping them onto a canvas next to the concept art they're informing takes a few minutes — the other thirty-seven clips stay exactly as untagged and unrated as they started, which is fine, because nothing about the workflow required touching them to get value out of the three that mattered. That's the pattern worth repeating across a whole archive of footage: index everything up front, touch by hand only the fraction that actually gets used.

Common mistakes worth avoiding

Keeping video in a separate folder tree from stills "to keep things clean" — this is the single most common one, and it's the opposite of what actually keeps things findable, since it means running two searches instead of one whenever a task needs both media types. Waiting to register a video folder until it's been sorted by scene or shot — the first pass doesn't need that structure and works exactly as well against a flat dump of files. And assuming a clip needs a thumbnail generated by hand before it shows up in a search — the first pass generates one automatically, the same way it does for a still.

A quieter mistake is building a separate tag vocabulary for clips because "video feels different" — hero, reject, needs-review mean the same thing whether they're stuck on a still or a clip, and splitting them into video-hero and image-hero just doubles the vocabulary a query has to know about for no real benefit. And treating the inline player as a reason to stop owning a dedicated video tool — it isn't one, and step six above is about confirming a shortlist, not replacing whatever software actually cuts or grades footage.

What to do when the library gets large

Video files are larger than stills, so a folder of raw footage fills a drive faster than an equivalent folder of photographs — the indexing behaviour doesn't change with scale, but it's worth registering footage on an external or archive drive as its own root once it stops fitting comfortably alongside active work, rather than waiting until the internal drive is full to decide. Proxies written at canvas resolution mean a board doesn't get slower as the source footage gets larger, which is the detail that keeps a forty-clip board scrolling like a four-clip one.

The first pass itself takes longer on video than on an equivalent count of stills, simply because there's more data per file to read — a folder of a thousand short clips takes noticeably longer to index than a folder of a thousand photographs the same total size. That cost is paid once per root, in the background, and doesn't recur: the query line above runs at the same speed against a freshly indexed thousand-clip folder as it does the week after, once the first pass has actually finished. Splitting a very large archive of footage across more than one root — by year, by project, by shoot — is worth doing mainly to keep that first-pass window shorter per root rather than for any change in how search behaves afterward, since a query against in: one root or across several returns just as fast either way once indexing is done.

A clip that never gets reviewed is no more useful than a clip that was never indexed, so the review habit in step six is worth building deliberately rather than treating playback as an afterthought once search has already done the hard part. The whole workflow above — index, search, review, tag the handful that matter, arrange on a canvas — is the same shape whether the folder holds two hundred stills or two hundred clips; only the amount of raw data behind each thumbnail changes.

The fuller comparison against refern covers the playback gap named above in more depth, and a video-specific reference manager built for Mac covers the rest of the feature set this workflow draws on. The wider round-up of video reference tools is worth reading if playback tools like scrubbing and A-B export are the actual priority. Searching without tagging first covers the same "index before you label" principle that step one above leans on. Or try it against your own footage — thirty days, every feature, no card and no account, is enough to register a folder of clips and see whether one query line across both media types is worth the change.