
A Mac with Apple silicon has a Neural Engine, a GPU and a handful of performance cores that sit idle for most of a photographer's evening. An AI culling app that runs on the machine puts them to work on the one job nobody wants: looking at every frame from a shoot and finding the plain misses. This guide explains what that kind of app does, what it should never do, and how to judge one before you hand it a wedding.
Culling has two halves. The first is mechanical: find the frames where the eyes are shut, the focus missed, the exposure is gone, the burst produced nine copies of one instant, or nobody is in the frame. The second is judgment: of the frames that survive, which ones tell this couple's story. A good app for Mac takes the first half and leaves the second alone.
That split matters more than any feature list. The mechanical half is where the hours go. A 4,000 to 5,000 frame wedding is four to eight hours of looking by hand, and most of that time is spent confirming that a frame is unusable, not deciding that it is great. The judgment half is the part of the job worth keeping, and it is the part a model trained on other people's taste gets wrong in ways you cannot see.
Kepla is built on that split. It clears the obvious misses, names the reason on every frame it sets aside, and hands you the clean frames to choose from. On the reference wedding we use for every number on the site, that is 4,812 frames in, 2,836 set aside with a reason, 1,880 clean frames left, 96 it would not judge, and 0 deleted. The choosing stays yours.
Cloud cullers ask for your card first. A wedding is 100 to 240 GB of RAW files, and the upload alone is the long pole: their own pages quote forty minutes to three hours for a shoot this size, most of it upload and queue behind other customers. A Mac app skips that step because there is nothing to send. Every frame is read where it already sits, on the card or on the drive you just copied it to.
Speed is the obvious win, but two others come with it. Privacy: a client's wedding never leaves the machine, which is a sentence you can say to the client without a footnote. And independence: with the wifi off, at a venue with no signal, the app runs at exactly the same speed. Nothing about the job depends on someone else's server being up.
| One wedding, 4,812 frames | Kepla on a Mac | A cloud culler | A full decode tool |
|---|---|---|---|
| Time until you can look | 4 min 22 s | 40 min to 3 h, upload and queue | 25 to 60 min |
| Has to upload your card | Never | 240 GB, every frame | No |
| Runs while the card copies | Yes, inside the copy | No | No, it fights for the disk |
| Works with no signal | Yes | No | Yes |
| A second pass | Seconds | Another upload | Another full decode |
Measured on a MacBook Pro M3 Max on battery, one 128 GB card of 4,812 frames, copying to two drives at 214 MB a second. Competitor ranges are the times their own pages quote for a shoot this size.
Four minutes is not a faster computer. It is four decisions about where the work happens.
The embedded JPEG versus RAW decode question gets its own article, because it is the one most people have not heard of and the one that saves the most time.
Because the app has your files in front of it, the rules about what it touches matter more than on a web service. Three lines are worth checking before you trust any local culler with a client's card.
It never deletes and never writes a reject flag. Deleting is obvious. A reject flag is subtler: it is one keystroke from gone inside Lightroom, and you have to trust it blind. Kepla writes neither. Everything it sets aside stays on the card and on both drives, with one of five plain reasons attached.
It never writes to your card. Sidecars go beside the copies on your drive. The card is read and nothing else.
It never judges taste. No opinion on the pose, the moment or the look. Only what a loupe can settle. When a frame is blurred in a way that might be deliberate, the app asks instead of deciding: those are the 96 uncertain frames on the reference wedding.
Take a shoot you already culled by hand. Copy the card, run the app during the copy, and compare two numbers: how many of its set aside frames you would have kept, and how many of its clean frames you would have thrown out. The first number is the one that matters, because a wrongly cleared frame is the failure you would never notice on a tool that hides its rejects. On a tool that prints the reason on the frame, you can check all of them in one filtered pass.
Kepla for Mac requires macOS 14 Sonoma or later and runs on Apple silicon and Intel as a universal binary, notarised by Apple. It is free through the private preview, and the first hundred photographers keep it at $99 a year for as long as they keep the app. Request Founding Access and we email you the short form and your place in the founding 100.
No. Kepla reads every frame on your Mac using the Neural Engine and GPU. Nothing is uploaded and there is no queue, so it runs at the same speed with the wifi off.
Yes. Kepla for Mac is a universal binary for Apple silicon and Intel, and requires macOS 14 Sonoma or later. On an older machine the promise is the same: if sorting does not finish before your card copy does, on battery, you owe nothing.
It reads them and writes XMP sidecars beside them. It never deletes, moves or renames a file, never writes a reject flag, and never writes to the card.
Lightroom decodes the RAW and works inside the catalog, so it competes with your import for the disk. Kepla reads the JPEG the camera embedded in each RAW, runs during the copy, and hands the result to Lightroom Classic through sidecars and a plugin.
Kepla for Mac clears the obvious misses from a card, names the reason on every frame it sets aside, and leaves the choosing to you. Nothing is ever deleted, moved or renamed. Free through the private preview · the first hundred photographers keep it at $99 a year.