https://bugs.kde.org/show_bug.cgi?id=510251

Vladimir Sitnikov <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected]

--- Comment #1 from Vladimir Sitnikov <[email protected]> ---
A softer alternative to a strict on/off toggle:

Today each face on a photo is classified independently, so two regions can both
end up tagged as person X even when the engine's runner-up for one of them is a
plausible match that would make the photo consistent. Instead of disallowing
duplicates outright, the recognizer could keep the top-K candidates per region
with their scores and pick the per-photo assignment that maximizes joint
likelihood under a soft preference for distinct identities:

* If the gap between candidate #1 and #2 for a region is large, keep #1 even
when it duplicates another region's identity — this preserves the legitimate
cases (mirrors, reflections, posters, picture-in-picture, two photos in one
frame).
* If the gap is small for at least one of the duplicating regions, swap that
region to its #2 — yielding a consistent assignment without overriding a
confident match.
This is a tiny bipartite matching problem (faces × candidates, per photo),
trivially solvable by Hungarian or even brute force given typical face counts.
A single tunable threshold — max acceptable score loss per swap — controls the
behaviour: at threshold = 0 it degenerates to today's behaviour, at threshold =
∞ it strictly disallows duplicates, so the original on/off proposal becomes a
special case of this knob.

For context: I wrote a post-recognition audit over the SQLite DB that flags
photos where the same person tag appears on non-overlapping crops (likely
mis-recognition) or overlapping crops (redundant annotation). On my library
duplicates are frequent enough that resolving them at recognition time would be
a noticeable improvement over fixing them by hand afterwards.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to