Match Result Model v1

Rôle et frontière

Un Match Result décrit un calcul descriptor-level réussi entre deux Feature Sets d'une Candidate Pair. Les correspondances sont dans le Match File; aucune vérification géométrique, aucun inlier géométrique et aucun masque d'inliers ne font partie de ce modèle.

Les erreurs d'exécution appartiennent au Task Runtime et aux valeurs de retour. Elles ne créent pas de Match Result. Le modèle persistant possède deux états :

NO_MATCH (0) : match_count == 0, aucun asset;
MATCHED (1) : match_count > 0, asset obligatoire.

match_count est exactement le nombre de correspondances descriptor-level persistées après Lowe ratio et canonicalisation. Il n'existe ni raw_match_count ambigu ni inlier_count dans Match Result v1.

Identité et ownership

L'identité immuable est :

(candidate_pair_id, feature_set_id_a, feature_set_id_b,
 matcher_kind, matcher_version, parameter_fingerprint)

Elle porte une contrainte UNIQUE. feature_set_id_a appartient à candidate_pair.image_id_a et feature_set_id_b à image_id_b. Les Feature Set IDs ne sont jamais triés numériquement.

Schéma Project DB v10

match_results impose en SQL : statut dans (0,1), 0 <= match_count <= 8192, SHA de 32 octets, chemins non vides et tailles strictement positives lorsqu'ils sont présents. Un CHECK conjoint impose :

NO_MATCH => match_count = 0 et SHA/path/size NULL
MATCHED  => match_count > 0 et SHA/path/size tous présents

La création vérifie aussi atomiquement l'ownership A/B avant l'INSERT. Les API load/find/list conservent l'ordre stable par match_result_id; close/reopen ne change aucune identité ni métadonnée.

Reuse

NO_MATCH est directement réutilisable sans asset. MATCHED ne l'est qu'après validation du chemin, de la taille, du SHA-256 réel, du format complet, du type et de la dimension des descripteurs, des Feature Set IDs A/B et du compte. Une ligne existante dont l'asset est absent ou corrompu déclenche un recalcul. Le fichier est republié atomiquement et les champs résultat/asset de cette même ligne sont réparés transactionnellement; son ID et son identité scientifique à six parties restent inchangés. Aucune identité artificielle ne contourne la contrainte UNIQUE.

Suite

Le prochain modèle possède ses propres statistiques géométriques, dont un éventuel inlier_count.

Geometric Verification Model v1 est désormais l'enfant scientifique persistant de ce résultat dans Project DB v12.

NEXT: GEOMETRIC VERIFIER v3

2.5 KiB Raw Blame History