Culling

[gansosilva]

@ncoevoet What an amazing tool congratulations!!

I'm testing it out in my wedding workflow... I have a question about culling: I can't filter by album, right?

That would be similar to what I used to do in Narrative Select.

[ncoevoet]

Hello,
thanks, i'm glad you like it !

I didn't think of culling filtered by albums, i will check how to implement that next week thank for the idea !

[gansosilva]

Thanks for the quick response! I wanted to share more detailed feedback that could help shape the culling workflow for wedding photographers.

I'm a Brazilian wedding photographer with 27 years of experience, and I'm genuinely excited to contribute to such an amazing open-source project. This kind of tool is exactly what professional photographers need.

About the /scenes page:

The concept is great but has a few gaps:

1. Thumbnails are too small to evaluate expressions and closed eyes. A minimum of 600-800px would help, along with a zoom function similar to Photo Mechanic's "Z" key, which activates a Loupe mode directly on the contact sheet without opening a new window, with zoom levels up to 800% via an adjustable slider. That kind of instant zoom without leaving the culling view is a game changer.
2. The Cull button only processes X-marked photos, not the full scene culling.
3. The entire wedding appeared as a single scene with 997 photos. The grouping needs to be more granular.

A "Cull this scene" button:

It would be a game changer to have a button that opens the full Culling view filtered to just that scene's photos, with burst detection, blink flags, and quality scores all in narrative context, similar to how Narrative Select works: "cull scene by scene, not frame by frame."

The unique opportunity: semantic scene detection:

Neither Narrative Select nor AfterShoot does this today. Both tools group photos by time gaps and visual similarity, but neither understands the narrative context of what is happening. Facet already has AI tagging, face recognition, and quality scoring. It could be the first tool to automatically identify and separate wedding narrative moments: bride getting ready, groom getting ready, ceremony entrance, vows, first kiss, cocktail hour, dinner, party.

This would be a game changer not just for culling speed, but for editing too. When you already know which group is which moment, the entire post-production workflow becomes faster and more organized. This is where Facet could leave Narrative and AfterShoot completely behind.

Close-ups Panel during culling:

One feature I used constantly in Narrative Select was the Close-ups Panel. During culling, a single keyboard shortcut opens a panel showing all faces in the photo simultaneously, with open/closed eye status and focus score per face. For a group photo with 30 people, this saves minutes per image. It would be incredible to have something equivalent in Facet's culling view.

Learning from culling decisions:

This is perhaps the most powerful opportunity. If the photographer does the entire culling workflow inside Facet, keeping, rejecting, comparing, every single decision feeds the AI model directly. Over time, Facet learns that photographer's style, eye, and creative instincts. This would eliminate the need for external tools like Photo Mechanic and close the complete workflow loop inside Facet. The more you cull, the smarter it gets. No other tool does this as a complete integrated loop.

Portuguese language support:

Facet already supports English, French, German, Spanish, and Italian, but Portuguese is missing. Brazil is one of the largest wedding photography markets in the world, and PT-BR support would open Facet to a huge community of photographers.

Keep up the incredible work! 🙌

[ncoevoet]

Thanks for the detailed feedback — it lines up closely with what's in the next release (available shortly):

• Narrative moments: Facet now identifies what's happening in a photo and groups a shoot by activity rather than only by time gaps.
• "Cull this scene" opens the full culling view for a single moment, with a loupe zoom directly on the contact sheet, larger previews, and per-face open/closed-eye and focus indicators.
• Also: full-scene culling, more granular grouping (so a whole wedding no longer collapses into one scene), learning from your keep/reject decisions over time, and Brazilian Portuguese support.

Your points on thumbnail size, the close-ups panel, and scene-by-scene culling shaped this directly.

Thanks again, and please keep the feedback coming.

[jarppiko]

Hello @ncoevoet and massive thanks for the project! This is something I have been waiting ever since AI started to become a reality.

I have just started experimenting with Facet and I have few requests that might be more questions how to do things with Facet. Bit of context. My use case is hobbyist's travel photography. Therefore I review/cull the photos always with the timeline in mind. I also shoot often bracketed shots to ensure I cover the dynamic range.

Proposal 1: sort by "Date Taken" in the Culling view

I am struggling how should I view the analysis results since Culling view is not sorted by timeline and I am not certain has the culling view correctly recognized e.g. panorama or bracketed shots that form a set and should not be reviewed as single photos. Adding "Date taken" as sorting option for culling view would be helpful.

Proposal 2: Quick toggle of show/hide photos

Since the Culling-view does not really cut for me due to the lack of timeline sorting, I have tried to use the Timeline view. In Timeline view there is "show all" in case some photos are filtered out. But this removes the filters instead allowing me to toggle filters on/off quickly. This view would be useful in culling photos if I could quickly toggle the filters off and back on.

Proposal 3: Inverse selection

I it easy to select favorites, but I would like to be able the inverse the selection and reject the others. Then it would be clear to me which photos are about to get deleted. Just having the small red favorite heart is not enough of visual clue.

Proposal 3: Automatic detection of panorama and HDR sets

Another feature that I am missing is to tell Facet that these photos are a HDR/panorama set so those should not be scored as individual photos. Automatic panorama detection would be even better :-)

Proposal 4: Detection of unnecessary shots in a bracketed sequence

I am getting greedy already, but since switching bracketing on/off in camera takes bit effort, I tend to shoot bracketed almost all the time. Even in conditions it is not needed. If the HDR detection could automatically reject unnecessary shots in a bracketed sequences, that would be helpful.

Proposal 5: Comparison view

If there are few photos of the same subject, I would like to manually do comparison. Bit like Lightroom's Compare view. But this might be something that is better to do this in Digikam or photo editor of choice. This could be a Culling view for the selected photos?

Proposal 6: Details pop-up as a side panel

The pop-up provides lot of useful information. Maybe even too much for a pop-up? How about instead of a pop-up this would be a statically placed side panel which content changes based on which photo is selected ("click" option") or hovered on ("Hover" option)? This would make it easier to compare certain aspects of a photo since the information would be always in the same location.

Final words

I also had an issue what to do with photos I have selected/rejected, but while writing this I realized the "Cull to folder" will allow me to delete the rejects that is exactly what I want to do.

Finally, massive thanks for making Facet. Absolutely fantastic work. ❤️

[ncoevoet]

Thanks — this is a genuinely useful report, and one of your points turned out to be a worse bug than you described. Everything below is landing in the next release, not available in the version you're running today.

Panorama and HDR sets (your 3rd point) — the HDR half is fixed, and it was bad

You were right that Facet had no idea what a bracket is. The consequence was worse than "scored as individual photos": burst detection groups on framing and capture time, which describes an exposure bracket precisely, so each set was collapsed into a burst and the whole set hidden behind a single frame chosen by score. That frame was as likely to be the −2 EV one as the correct exposure. On a 126k-photo library I tested against, that was 226 bracket sets, every single one swallowed.

Facet now derives the exposure ladder from EXIF it already stores (f_stop / shutter_speed / ISO), so nothing needs rescanning and no image is decoded:

python facet.py --detect-sequences

About a minute on 126k photos. It also runs automatically at the end of every scan and as a step of --upgrade-db, so after upgrading you only need to run it by hand if you want the labels immediately.

To answer your wording precisely: scores stay per-photo — that doesn't change and shouldn't. What changes is that the set is presented as one thing. In the gallery a new "Best of bracket" display option (on by default) shows only the base exposure; in culling, brackets get their own granularity where every frame is pre-marked keep, because the set was shot to be merged, not to compete. Confirming a bracket group deliberately records no comparison pairs — preferring one rung of an exposure ladder says nothing about your taste, and feeding that to the personal ranker would bias every later ranking.

Config, if you want to tune the detector — everything has a working default, so you only add this block to change something:

"sequence_detection": {
  "enabled": true,
  "max_gap_seconds": 3.0,
  "max_hamming": 10,
  "min_frames": 3,
  "min_step_stops": 0.5,
  "min_span_stops": 1.0,
  "step_tolerance_stops": 0.34
}

step_tolerance_stops is the one that matters: it's how uneven the EV steps may be, and it's what separates a real bracket from a hand-held run drifting through changing light.

Panoramas are deliberately not done. I tried the cheap approach — panorama frames should form a "chain" on the stored embeddings (each similar to its neighbours, dissimilar to distant ones) where a burst forms a "clique". The topology separates cleanly, but when I actually rendered the top candidates, none of them were panoramas — they were ordinary reportage sequences. Embeddings encode semantics, and every frame shot in one spot shares those. Brackets worked because the EV ladder is self-verifying (the step sizes landed exactly on 1, 1⅓, 1⅔ and 2 stops — the camera's own AEB increments, which can't happen by chance); panoramas have no equivalent tell in metadata. Doing it properly needs geometric confirmation — feature matching and a homography between consecutive thumbnails, checking for a consistent one-way translation. That's the plan, but I'd rather ship it late than ship a detector that mislabels your reportage.

Unnecessary shots in a bracketed sequence (your 4th point)

Auto-cull can now drop the flanking exposures — but only where the base frame clips neither shadows nor highlights, i.e. only where bracketing genuinely bought you nothing. Where the base clips, the extra frames are doing their job and are left alone; and a set whose base has never been measured is left alone too, since unmeasured isn't the same as unclipped. On the test library that flagged 55 of 226 sets.

One caveat so you're not hunting for it: this is currently the trim_brackets flag on POST /api/culling/auto, not a config key and not yet a checkbox in the auto-cull dialog. Dry-run is the default, so you can preview the split before anything is written.

Sort by Date Taken in Culling (your 1st point)

Added, as Oldest first in the sort menu — plus an arrow button beside it that reverses whichever sort mode is active, so every mode now works both ways. Oldest-first is also the one mode that orders the photos inside each group by capture time, which is the only order a bracket or a panned sequence reads correctly in.

Quick toggle of show/hide (your 2nd point)

Fixed, with one correction to the diagnosis: that banner belongs to the gallery, not the Timeline — the Timeline navigates into the gallery with a date filter applied, and has no hide-filters of its own. "Show all" was indeed one-way; it now offers "Restore filters" to put back exactly what you had.

Inverse selection (your other 3rd point)

Added to the selection bar: select your keepers, invert, reject.

Worth knowing though — rejected photos already get more than the small heart: they render desaturated and dimmed with a persistent badge. That only shows in edition mode, which may be why it looked like the heart was the only signal. If you're not in edition mode, that's the first thing to turn on.

Comparison view (your 5th point)

You guessed the answer yourself: it is the culling view for the selected photos. That side-by-side with synced pan and zoom already existed inside the culling darkroom, it just couldn't be reached for an arbitrary set. There's now a Compare action on any 2–4 selected photos in the gallery — scroll to zoom, drag to pan, every pane moves together and swaps to full resolution past fit scale.

Details pop-up as a side panel (your 6th point)

Added as a "Side panel" option in the tooltip menu. It docks the same details in the right-hand drawer instead of following the cursor, so a given field is always in the same place from one photo to the next — which was your actual point. It shares that drawer with the filter sidebar rather than taking a strip of its own, so the grid keeps exactly the width it has with filters open, and it keeps the last photo you hovered instead of blanking when the cursor leaves the grid.

Two honest limitations: it needs a window of at least 1280px (below that a permanent 320px strip costs more than it gives, so the option isn't offered), and it currently follows hover only — you asked for it to work with the "click" option too, and that isn't in yet. It's a small change and I'll add it.

To have it on by default:

"viewer": {
  "defaults": {
    "tooltip_mode": "panel"
  }
}

Cull to folder

Your instinct was right, with one caveat worth knowing before you rely on it. Moving rejects to a folder works out of the box. Sending them to the OS trash is deliberately behind a config flag, off by default:

"viewer": {
  "cull": {
    "allow_trash": true
  }
}

And destination folders are checked against an allow-list — by default that's just your scan directories, so if you want to cull somewhere else, add it:

"viewer": {
  "export": {
    "allowed_target_dirs": ["/path/to/somewhere"]
  }
}

Every action defaults to a dry run that returns exactly what it would move or trash, so you can look before anything happens. After a real move or trash, run python database.py --cleanup-missing-photos to drop the moved files from the database.

---

Thanks again — the bracket bug in particular would have gone unnoticed for a long time without your report, and it was quietly hiding two frames in three of every bracketed set. Please keep it coming.

[ncoevoet]

Quick follow-up, @jarppiko: all of the above is now merged to master as 1.9.0 "Chatoyance" — it's no longer "the next release", it's in.

The one thing I said wasn't in yet, is in. The docked side panel followed hover only when I wrote that reply; it now follows both hover and click, which is what you actually asked for. A parked panel has no reason to insist on one gesture — and hover never fires on a touch screen, so on a tablet the rail was unreachable despite 1280px being exactly a tablet's width. Clicking a photo now feeds the rail as well as toggling its selection, and clicking the same photo again doesn't blank it. Pressing Space on a focused card does the same, so the panel is reachable without a mouse at all.

Two caveats from that reply that have not changed, so you're not hunting for them:

• The panel still needs a window of at least 1280px. Below that the option isn't offered at all — a setting that silently does nothing is worse than no setting.
• trim_brackets is still a flag on POST /api/culling/auto, not a config key and not yet a checkbox in the auto-cull dialog. Dry-run remains the default.

One thing worth knowing that wasn't in that reply: the viewer now tells you when a newer Facet has been released, so you won't have to watch this repo to find out. It's edition-only and checked server-side once per interval, the request carries nothing but itself, and updates.enabled: false stops it entirely.

On upgrading: --detect-sequences runs automatically at the end of every scan and as a step of --upgrade-db, so you only need to run it by hand if you want the bracket labels immediately. Roughly a minute on 126k photos, no rescan and no image decode.

Panoramas remain deliberately undone, for the reason above — the embedding topology separates cleanly but the candidates it surfaced were reportage sequences, not panoramas. That one needs geometric confirmation, and I'd rather ship it late than mislabel your travel sets.

Thanks again for the report — the bracket bug was the most valuable thing anyone has sent me.

[jarppiko]

Wow,that was quick! I will give it a try this weekend.

I understand the panorama part is more challenging since detecting a panorama sequence from random shots is non-trivial.

Few questions about the bracket detection:

1. Does the bracket detection work with just 2 photos? I often shoot -3EV, 0EV just to avoid burnout highlights.
2. Is the "base image detection" based on 0EV exposure or is it automatically detected based on lack of full black and burnout?
3. Did I get it right that step_tolerance_stops defines the minimum stop change in a bracket set to separate brackets from random exposure correction tuning?
4. Is min_span_stops the minimum exposure range of set regarded as a bracket set (-2EV, 0EV, +2EV = 4EV)?

And the new update-notification is a great idea!

EDIT. I noticed you couldn't resist the panorama feature either 😄

[ncoevoet]

Thanks — and yes, guilty on the panorama front 😄

2-photo brackets — not by default: sequence_detection.min_frames is 3. You can set it to 2 and pairs will be detected, but two things get worse:

• The base frame comes out as the darker one, so a −3EV/0EV pair gets centred on the −3EV shot instead of the 0EV keeper.
• The check that tells a real bracket from "I dialled in some compensation and reshot" needs at least two steps to work. With one step it can't do anything, so ordinary reshoots start reading as brackets.

For your case the default is probably the better outcome anyway: the pair stays a burst, and scoring picks the lead — which for −3EV/0EV is almost always the 0EV frame.

Base image — neither, as it happens. No exposure-bias EXIF tag is read and there's no clipping analysis. EV is worked out per frame from aperture/shutter/ISO, the frames are sorted by it, and the middle one is the base — chosen by position, because the base is a property of how the set was shot rather than of how the frames came out. sequence_ev_offset is then each frame's distance from that base, signed the way the camera labels it (−2 dark, +2 bright).

step_tolerance_stops — what you're describing is min_step_stops (0.5): the smallest EV change that counts as a step at all. step_tolerance_stops (0.34) asks a different question — are the steps all roughly the same size? A camera bracketing steps evenly (1, 1 or 2, 2). Shots drifting through changing light don't — 0.7, then 1.9 — and get rejected. The 0.34 is how much unevenness is allowed before a run stops looking deliberate.

min_span_stops — yes, first-to-last total. −2/0/+2 is 4 stops, against a default of 1.0.

Panorama — fair, I did say it was hard. It was, and what shipped is deliberately modest about it. The idea is simple enough: compare each frame with the next and look for steady movement in one direction across the whole run. A burst wobbles around one spot; a sweep keeps travelling. It reads the small stored thumbnails, so it adds nothing to scan time.

The limits are worth knowing before you rely on it:

• It misses some panoramas on purpose. Vertical sweeps, and ones shot in only a few positions, don't move enough to be told apart from ordinary reportage. I'd rather miss a panorama than label a sequence of someone's photos as one, so it's tuned to be right when it speaks up (~96%) and to stay quiet when unsure.
• Short sweeps won't register — it wants 8 frames by default. Below that they look like bursts.
• It gets things wrong in both directions, which is why 1.10.1 added corrections: mark a set as not-a-panorama from culling, or flag a missed one from the gallery. Both apply on the next detection run rather than instantly, since it's a batch pass.
• The thresholds came from my own library — 26 panoramas and 8 near-misses checked by eye — so a different shooting style may want them adjusted.

Exposure was the first thing I tried, incidentally, and it was useless: one confirmed set was shot on locked exposure, another on auto.