Qualification de la qualité des photos : récap des travaux en cours

Bonjour à toutes et à tous !

Voici une petite mise à jour sur les avancées de l’implémentation du score de qualité des photos, qui peut encore évoluer (c’est une base de travail pour faire avancer ce vaste chantier). Il reprend des éléments qui sont discuté sur le ticket Gitlab ici.

Comme initialement proposé, seules les données qui peuvent être calculées à partir des balises EXIF disponibles sont utilisées (pas d’analyse des pixels des photos, car cela serait trop coûteux pour relire tout le stock actuel).

Traitements côté API

L’API va calculer des valeurs brutes en utilisant les métadonnées des photos (largeur, infos GPS) et les transmettre via des réponses JSON et des tuiles vectorielles. Les valeurs brutes incluent la précision GPS en mètres et la densité de pixels horizontale (nombre de pixels par degré de champ de vision).

Cela permet à tout utilisateur/développeur de créer des filtres et des statistiques selon ses besoins. C’est aussi vrai pour le visualiseur web Panoramax, qui calculera la note finale de qualité.

Pour que cela fonctionne, les photos doivent inclure les balises EXIF/XMP suivantes :

  • Dilution de la précision GPS : Exif.GPSInfo.GPSDOP ou Xmp.exif.GPSDOP
  • Mode différentiel GPS : Exif.GPSInfo.GPSDifferential ou Xmp.exif.GPSDifferential
  • Erreur de positionnement horizontale GPS : Exif.GPSInfo.GPSHPositioningError ou Xmp.exif.GPSHPositioningError
  • Champ de vision de la caméra ou longueur focale + marque + modèle

Si tout est bien configuré, les valeurs seront précises. Si aucune balise n’est présente, les valeurs resteront inconnues. Plusieurs solutions de repli existent en fonction de la marque et du modèle (voir ici pour le GPS ou via la table des caméras pour la largeur du capteur).

Visualiseur Web

Le visualiseur web recevra les données de l’API via des tuiles vectorielles. Il utilisera les deux indicateurs pour calculer un Score de Qualité, qui apparaîtra dans la fenêtre de métadonnées des photos et pourra être utilisé pour le style ou le filtrage des cartes.

Calcul du score

Le visualiseur web utilise actuellement ces valeurs pour établir son score de qualité.

Précision GPS

Précision GPS Note
<= 1m A
<= 2m B
<= 5m C
<= 10m D
> 10m ou inconnu E

Densité de pixels horizontale

C’est l’indicateur du nombre de pixels sur l’horizon de la photo par degrés d’angle de vue. La notation est différente selon que les photos soient en 360° ou non, afin d’encourager la prise de photos 360°, qui sont plus appréciées par les utilisateurs finaux. Encore une fois, cette échelle de notation est adaptée pour les besoins du visualiseur web, mais chacun peut adapter selon ses besoins :wink:

Note Densité pour 360° Densité pour non-360°
A >= 38 px/deg Impossible
B >= 20 px/deg >= 60 px/deg
C >= 15px/deg >= 38px/deg
D < 15px/deg >= 15 px/deg
E valeur inconnue < 15 px/deg ou valeur inconnue

Score de qualité

Le score final de qualité est calculé en fonction des notes pour le GPS (1/5 de la note finale) et pour la densité de pixels horizontale (4/5 de la note finale). À ce jour, environ 60 % des photos ont un score de qualité calculé à partir de valeurs précises ou de bonnes estimations. Le reste des photos n’a pas suffisamment de métadonnées pour obtenir une valeur précise et reçoit donc une note de E.

Et après ?

La discussion est ouverte ! Vous pouvez proposer des modifications dans le classement, la méthode d’évaluation (tant que ça reste basé uniquement sur les balises EXIF), que ce soit ici ou sur le ticket gitlab.

Je dois encore créer une documentation expliquant cette méthodologie dans le visualiseur web, ainsi qu’une autre pour expliquer les balises EXIF nécessaires, afin d’encourager les contributeurs à bien les renseigner.

À moyen terme, nous proposerons un outil d’édition en ligne pour améliorer les métadonnées des photos (ajouter la valeur du champ de vision, améliorer la position GPS, etc.), afin que chacun puisse contribuer à améliorer la qualité du stock de photos.

1 Like

Plutôt que d’avoir 2 densités pour les photos 360 ou non, j’appliquerai plutôt un bonus d’une lettre pour les photos 360


On n’a pas du tout pris en compte l’âge de la photo… ça serait aussi un indicateur intéressant à intégrer selon vous ?

1 Like

Est-ce que tu as un listing du type marque/modèle/fov pour le stock actuel ?
L’idée est que je regarde si ça correspond à ce que j’ai de mon côté.

On a abordé le sujet avec Florian l’autre jour, ça dépend si on considère le score comme purement de qualité (auquel cas la fraîcheur ne rentre pas en compte) ou de pertinence (dans ce cas fraîcheur à intégrer). J’aurais eu tendance à ne pas prendre en compte la fraîcheur dans cette note, mais par contre qu’on ait notre calque par défaut dans la visionneuse qui fasse un combo qualité+fraîcheur.

Pas de listing direct modèle → FOV mais on réutilise le fichier modèle → largeur du capteur ici (et complétée ici) pour calculer le FOV selon la longeur focale ici.

Je pense qu’il s’agit également de prendre en compte les photos de GoPro classiques qui prennent des photos de 270°, c’est-à-dire mieux qu’une photo classique mais moins bien que 360°.

Justement le ratio pixels/degré de champ sur l’horizon est neutre, c’est pour ça que je l’ai proposé car il indique à quel point on peut zoomer sur des détails lointains.

Ensuite on peut bien sûr considérer qu’une photo qui couvre un champ large 360 étant le maxi) a plus d’intérêt.

Les GoPro sont plutôt de l’ordre de 180° (fisheye).

Autre intérêt pour les panoramiques pris par exemple au smartphone en tournant et là, oui tu peux avoir du 270° et la densité pixels/degré sur l’horizon reste toujours une métrique neutre.

1 Like

Dis moi si je me trompe sur le calcul.
Je prends pour exemple la Gopro 11. Les valeurs que je trouve sont :
sensor width : 6.74
focal length : 2.7
pixels horizontaux : 5568

J’applique degrees(2*arctan(6,74/(2*2,7))) et j’obtiens 102.6°
Le problème, c’est que les valeurs constructeurs donnent 122° à l’horizontal.

Ca nous fait une densité de pixel qui varie de 45 à 54. Bon, on peut se dire… “pas de quoi fouetter un chat” pour un indice de qualité. Dans le cas présent ça ne fait même pas changer de note.

La question que je me pose c’est si l’écart de FOV théorique/réalité reste toujours dans des valeurs acceptables.

Je pense que les données constructeurs sont assez arrondies et que ça a un impact important sur les calculs trigo.

Et puis il y a les histoires de FOV sur la diagonale ou en horizontal/vertical…

C’est plus simple sur les 360, là au moins on sait qu’on a 16 pixels par degré à l’horizon sur une GoPro Max, donc environ 3 fois moins que la Hero 11.

Surtout que les données constructeurs sont pas toujours simples à trouver, ça s’est fait à coup de recherche en ligne et creuser dans des pages de spécifications obscures de capteurs… sur les valeurs dans le fichier d’origine (qui vient de OpenSfM) il y a sans doute moins d’approximations.

bonjour

j’ai une bizarrerie avec la qualité des photos telle qu’implémentée actuellement sur l’instance IGN.

Avec le compte sig_bayonne, on utilise toujours le même matériel (Gopro max).

La plupart des séquences apparaissent en vert kaki (qualité C) à l’exception des plus récentes (31 octobre) qui apparaissent en orange (qualité E).

La seule différence pour moi entre ces séquences, c’est leur date. Je note également que chez mes voisins angloyes c’est le même chose, ce sont les séquences de novembre qui apparaissent en orange.

Autre chose qui me parait étrange, quand on zoome :


La ligne est orange mais les points sont verts !

bonjour
mon message était peut-être passé inaperçu (envoyé le 24 décembre :santa:)
En tout cas le soucis perdure pour le moment. Cela ressemble plus à un bug d’affichage qu’autre chose.

Effectivement le message est passé entre les mailles du filet (ou du sapin :christmas_tree: ), j’ai fait un ticket ici et je vais regarder en détail : Quality score : different rendering between sequence & pictures (#216) · Issues · Panoramax / Clients / Web viewer · GitLab

1 Like