Panoramax Méthodes d'acquisition

Bonjour,

Je propose de recenser les principales méthodes d’acquisition de photos pour panoramax. L’objectif est de tirer le meilleur parti de nos précieuses données acquises avec le matériel dont chacun dispose (pas obligé de se construire une google car). Ça passe par l’identification des problèmes rencontrés. Ça pourrait déboucher sur des recommandations à l’acquisition ou au traitement pour améliorer ou ne pas perdre d’information, voir des propositions de nouveaux logiciels dédiés.

C’est une réflexion complémentaire au stockage de la précision (Stocker la précision de la géoloc dans les photos).

3 Likes

Les paramètres physique d’une photo sont :

  • Position en 3D
  • Orientation en 3D
  • L’heure de prise de vue
  • L’angle de vue
  • Les distorsions optiques

Pour chacun de ces paramètres, idéalement, on voudrait avoir une valeur approximative la plus précise possible et une évaluation de l’incertitude sur cette valeur. Par exemple, la direction horizontale de la photo est de 217,123456789° avec une incertitude de 12°.

L’angle de vue et les distorsions sont des caractéristiques de l’appareil de prise de vue. Ils ne doivent pas changer d’une photo sur l’autre. De nos jours, les distorsions sont normalement corrigées en interne à l’appareil d’acquisition.

Pour une vue à 360°, même si on voit dans toutes les directions, il y a toujours une direction de prise de vue correspondant au centre de l’image et une éventuelle inclinaison.

Pour les prises de vue, on a principalement les smartphones et les action-cams à cadrage tradionnel (mais souvent large) ou panoramique (360°).

J’ai voulu faire des essais avec un appareil photo. Même en ayant pris l’Olympus Pen E-PM1 (Test Olympus Pen E-PM1 - Les Numériques) qui est assez compact, c’est encombrant sur le tableau de bord de la voiture.

Par expérience, le smartphone va bien derrière le parebrise de la voiture ou tenu à la main à pied ou en vélo (pas top pour la sécurité dans ce dernier cas, je le réserve aux pistes cyclables). Sinon, c’est l’action-cam si on veut fixer sur le vélo ou la moto (à cause des vibrations), sur le toit de la voiture en panoramique…

Pour l’acquisition de la position et de l’orientation, on pense en premier lieu au GPS/GNSS. C’est le GNSS classique à quelques mètres près ou le GNSS différentiel RTK à quelques centimètres avec le réseau centipede par exemple (https://centipede.fr/). Dans les deux cas, si la réception satellite est mauvaise (relief, végétation, canyon urbain…), la précision baisse. S’il n’y a plus de signal (tunnel, intérieur de bâtiment, souterrain…), il n’y a plus de position. Par ailleurs, par défaut, la position GNSS ne permet pas de connaître la direction de prise de vue. Pour essayer d’améliorer ces deux points (perte de réception et détermination de la direction), on peut ajouter au récepteur GNSS une centrale à inertie (IMU : Inertial Measurement Units) qui va comporter trois accéléromètres, trois gyroscopes voir trois magnétomètres (pour faire un compas magnétique). Des fois, il y a même un capteur de pression pour faire une IMU à 10 degrés de liberté (exemple en bricolage : Module IMU 10 DOF V2.0 Grove 101020252 Seeed Studio - Capteurs spatiaux | GO TRONIC). Pour les véhicules à roue, on peut aussi rajouter des capteurs de roue.

Par exemple, la puce UBlox F9R fait GNSS différentiel, IMU à 6 degrés (accéléromètres et gyroscopes) et une entrée pour un capteur de roue. Je suis en train d’essayer de lui transmettre la vitesse du véhicule récupérée sur la prise OBD de ma voiture.

Il vient ensuite la question du lien entre les parties prise de vue et positionnement.

Ils peuvent être ensembles dans un smartphone ou une action-cam. De nos jours, tous les smartphones ont du GNSS intégré et au moins trois accélémromètres. Les gyroscopes et les magnétomètres sont moins systématiques. Je n’ai pas connaissance de téléphone ou d’action-cam permettant de faire du GNSS différentiel (avec précision centimétrique). Sinon, on a prise de vue et positionnement sur deux équipements distincts. Le défi est alors de relier les deux sources de données.

Dans le cas d’un système intégré, il peut quand même manquer l’information sur la direction de prise de vue. Par défaut, on va supposer que les vues sont prises dans la direction de déplacement. Dans le cadre de prises de vue latérales, il faut aussi pouvoir définir manuellement l’angle entre la direction de progression et celle de prise de vue. Ça va pas mal si on est en voiture, tant qu’on ne fait pas de marche arrière. Pour un équipement accroché sur un deux-roues, il faudrait aussi tenir compte de l’inclinaison du véhicule (roulis ou roll en anglais). Quant à l’appareil tenu à la main, c’est encore plus approximatif. D’ailleurs, j’avais essayé les acquisitions avec un stabilisateur/gimbal comme cette séquence :
https://www.mapillary.com/app/?pKey=547606869561829

Mais j’ai arrêté, ne pouvant pas mettre en même temps le smartphone et l’antenne RTK sur le stabilisateur.

Ça nous amène au cas où image et position sont acquis avec deux appareils différents. Premier problème, les capteurs ne sont pas au même endroit. Second problème, il faut synchroniser les deux sources de données.

Si on n’est pas en GPS différentiel, la précision sur la position fait qu’on ne va pas trop s’inquiéter des quelques centimètres voir décimètres de décalage entre photo et GPS. Néanmoins, la question de la synchronisation temporelle se pose. Par exemple, on a une action-cam sans GPS (ou qu’on ne trouve pas assez précis) couplée à un GPS externe, il faut être plus précis que la seconde. Si on se déplace à 10 m/s (36 km/h), une seconde est équivalent à 10 m. Dommage quand je vois que mon Garmin Extrex 30 est pratiquement métrique en terrain découvert.

Si on est en GNSS différentiel, on voudrait pouvoir indiquer le décalage entre l’antenne et le capteur photo. Dans ma voiture, j’ai plus de 40 cm entre l’antenne aimantée sur le toit et le smartphone placé derrière le pare-brise. La synchronisation temporelle se pose aussi de manière encore plus critique. Si je roule à 30 m/s (108 km/h), une erreur de 0,1 s sur l’heure entraine une erreur sur la position de 3 m. Dommage quand on a un récepteur précis à 3 cm.

Le problème de la direction de prise de vue existe aussi, comme pour un système intégré, si l’information n’est pas fournie par la caméra.

Maintenant, les problèmes en pratique.

Il y a une discussion sur le forum voisin sur la synchro action-cam/GNSS. Même si la cam prend les photos de manière régulière dans le temps, ce n’est pas évident de synchroniser. Certains modèles récents enregistrent l’heure des photos à la milliseconde mais il faut quand même recaler entre l’heure de la cam et celle du GPS. Il peut aussi y avoir des dérives de l’heure de la cam. Certains peuvent-ils faire des retours sur leurs expériences de synchro avec une cam?

Moi, j’utilise des smartphones Android pour la prise de vue et récepteur GNSS externe. Si j’utilise l’application Mapillary (GNSS interne ou externe), toutes les images pointent à 90° avec une altitude de 0 m. Je constate aussi que les images ne sont pas bien positionnées le long de la trace avec des irrégularités. J’ai l’impression qu’il fait les géotaggage des photos après l’enregistrement de la photo sur la SD. Des fois, ça rame sur la SD et la photo se retrouve positionnées trop loin. Accessoirement, je ne peux pas indiquer de décalage entre antenne et smartphone (ni la direction de prise de vue mais comme c’est déjà n’importe quoi…).

Si j’utilise OpenCamera, les coordonnées sont arrondies à plusieurs mètres en horizontal avec mes smartphones. Par contre, l’altitude est enregistrée (au mètre?). Il n’y a pas de direction de prise de vue enregistrée. Je dois nécessairement reprendre ça, ce que je fais avec JOSM. Il faut ajuster manuellement le décalage temporel en utilisant des repères visuels comme des virages, rond-points, passages piétons… En étant optimiste, je dirais qu’on peut atteindre le dixième de seconde mais ce n’est pas stable dans le temps. Ça peut même changer au sein d’une longue séquence. Avantage avec JOSM, on peut indiquer le décalage entre caméra et antenne GNSS, ainsi que la direction de visée par rapport à l’axe de déplacement.

En fait, quand on cherche un peu sur Android, on apprend que l’heure fournie par le système n’est pas considérée comme fiable. Elle se recale de manière un peu irrégulière sur le réseau. Si on veut des mesures temporelles fiables, il y a d’autres fonctions comme milliS qui donnent un temps depuis le démarrage de l’appareil. Par ailleurs, Android n’étant pas un OS temps réel, je ne sais pas si on peut avoir de manière fiable une mesure du moment de prise de vue d’une photo. Est-ce qu’on pourrait avoir un processus style : demande de prise de vue, retour que la photo est prise (transfert en mémoire), noter l’heure(milliS) et ensuite compression jpg et enregistrement sur SD? Est-ce qu’on peut avoir un délai prise_de_vue/mesure_milliS stable? Je demande juste la milliseconde. :sweat_smile:

Par ailleurs, avec le F9R qui intègre une IMU, je dois pouvoir récupérer l’orientation du véhicule et, potentiellement, détecter quand on est en marche arrière (ou simplement utiliser l’orientation du F9R pour déduire la direction de prise de vue, les deux étant supposés solidaires).

Je reprends après une petite pause.

Donc, la première étape est de faire l’acquisition avec le maximum d’informations. Par exemple, chez u-blox, on voit dans le message NAV-POSLLH qu’on a non seulement les coordonnées mais aussi l’estimation de la précision:

Si on a des informations sur l’orientation, il faut aussi enregistrer. Message NAV-ATT avec le F9R :

image

On note d’ailleurs qu’il y a aussi une estimation de la précision de l’orientation.

À priori, on peut mettre presque tout ça dans les données exifs (discussion sur la précision) à part la précision sur l’orientation.

Néanmoins, il faut réussir à transférer tout ça aux photos avec la bonne synchro.

Si on n’a pas l’information sur l’orientation, il faut essayer de la reconstituer en supposant que c’est dans l’axe de progression (ou un angle défini par l’utilisateur). On peut essayer d’exploiter des informations sur la vitesse/direction de progression si elles sont fournies. Je pense aussi qu’il faut essayer de tirer parti de la nature du véhicule qui supporte la caméra. On peut au moins distinguer les 4 roues (qui tournent à plat), les 2 roues qui se penchent pour tourner et les mesures à main levée où on ne peut pas dire grand chose :rofl:.

Au niveau de panoramax, je pense qu’il serait bien de pouvoir stocker non seulement ce genre d’informations mais aussi la trace GNSS voir les données brutes RINEX, UBX… Ça pourrait permettre à d’autres d’affiner les calculs de positions et orientations, éventuellement en conjonction avec d’autres outils comme la reconnaissance de points communs entre photos voisines, façon OpenSFM de Mapillary (mais en moins foireux).

Dans l’idée de fournir avec les photos des infos complémentaires dont la trace, il y a aussi qu’actuellement, ne sachant pas comment transférer toutes les informations dont je dispose, je me dis que ça pourrait permettre à d’autres de le faire ultérieurement, éventuellement en automatique.