lundi 19 septembre 2016

Construire son V4MPod pour prendre des photos à 360° - Partie 2

La première partie est sur cette page.

Géo-localisation

Géolocaliser des photos lorsqu'on est en extérieur ne pose pas vraiment de problème si on a l'heure de prise vue enregistrée dans la photo, ainsi qu'une trace gps, il existe un tas d'outils qui permettent de faire la corrélation entre les 2 informations pour retrouver la bonne position. Mais là, dans les gares parisiennes, à parfois plus de 20 mètres sous la surface, il était complètement illusoire de penser utiliser une localisation à base de satellites. La seule solution "pas chère", et pas trop rébarbative, c'est de construire de toute pièce un fichier gpx, et de faire une corrélation identique à des prises de vues extérieures, enfin presque...

 

J'ai essayé plusieurs techniques, plusieurs logiciels, pour essayer d'arriver à la solution la plus automatisable possible. Dans tous les cas, on est obligé de passer par plusieurs étapes différentes, j'ai juste choisi celle qui me semblait la moins mauvaise et qui se résume par :

  1. Vérifier la synchronisation des photos.
  2. Localiser manuellement des photos "clé".
  3. Créer une trace gpx depuis ces photos.
  4. Corréler les photos restantes depuis la trace gpx.
  5. Ajouter la direction (l'azimut) de la prise de vue.

La synchronisation n'étant pas parfaite entre les différentes Yi, l'heure enregistrée dans certaines photos peut être décalées d'une seconde. La première étape est de vérifier que toutes les photos prises au même instant ont le même "timestamp". Je l'ai fait en récupérant les valeur des tag ImgCreationDate d'une caméra, pour les recopier sur les autres. Je ne vais pas m'étendre sur cette procédure car ma méthode n'était pas très propre (je suis passé par un tableau), un script serait bien plus adapté.

Pendant les prises de vue sur le terrain, j'ai essayé le plus possible de faire des trajets rectilignes, et en prenant les photos à des intervalles fixes, ce qui donnait : je fais 4 pas, je m'arrête, photo, je fais 4 pas, je m'arrête, photo, je fais 4 pas, et ça continuait tout au long de la journée, parfois même dans mon sommeil...

Prenons l'exemple ci-dessous, situé dans la galerie commerciale de la gare Saint-Lazare.

Capture_gallerie_gare_saint_lazare_v4mpod.jpg
 

Mes images clés sont situées au point de départ (nord-est), à chaque quart de tour sur la gauche, puis au retour au point de départ. Je positionne manuellement les images de la caméra avant dans JOSM à l'aide du plug-in PhotoAdjust. Ces images ont maintenant des coordonnées stockées dans les tags exif de la photo.

Exiftool, est un puissant outil qui permet de manipuler les tags Exif des photos, et une de ses fonctions, le reverse geocoding permet de créer une trace gpx depuis les photos qu'on lui donne. Au préalable, il faut ajouter le tag gpsdatetime qui est manquant. Cela se fait facilement en reprenant le tag datetimeoriginal. La ligne de commande est :

exiftool.exe -if "not $gpsdatetime" "-gpsdatestamp<${datetimeoriginal}+01:00" "-gpstimestamp<${datetimeoriginal}+01:00" "path"
  • Les valeurs +01:00 sont optionnelles, elles indiquent le décalage entre l'heure locale et l'heure UTC utilisée par les récepteurs gps.
  • "path" est à remplacer par le chemin du dossier contenant les images à traiter.

Ensuite, on peut lancer la création du fichier gpx :

exiftool.exe -if "$gpslongitude" -p e:\gpx.fmt -d %Y-%m-%dT%H:%M:%SZ "path" >out.gpx
  • e:\gpx.fmt est le chemin vers le document qui indique comment un fichier gpx doit être structuré. il est disponible gpx.fmt.
  • "path" est à remplacer par le chemin du dossier contenant les images à traiter.
  • out.gpx est le nom du fichier généré.

Si on charge dans JOSM nos photos clés ainsi que la trace gpx, cela correspond bien :

Capture_josm_v4mpod_01.JPG

Mais...mais...un peu plus tard, il va falloir ajouter l'azimut des photos. Cela se fait à l'aide de la direction du prochain point de la trace gpx. Pas de souci. Sauf lorsque j'arrive à un angle, ou à la fin de mon parcours. Si je prends une photo, et qu'ensuite je tourne à 90°, la direction indiquée par le point suivant n'est pas du tout celle de la prise de vue. Si j'arrive à la fin de mon parcours, il n'y a plus de point pour définir la direction. La seule solution que j'ai trouvée, c'est d'éditer le fichier gpx dans JOSM pour ajouter des points pour indiquer la direction de la prise de vue.

Dans l'exemple ci-dessous, j'ai ajouté un point à moins d'un centimètre plus au sud de la prise de vue. C'est suffisant pour indiquer la direction de la photo, et ne perturbe pas sensiblement la suite de la trace.

Capture_josm_v4mpod_02.JPG
En rose, la trace gpx d'origine. Le point rouge est celui que j'ai ajouté pour "guider" la direction qui sera calculée.

Ensuite, il faut ajouter l'heure de ce nouveau point, sinon les outils de corrélation refusent de fonctionner correctement. Pour cela, j'ai utilisé GPX editor. Dans la capture d'écran ci-dessous, on voit très vite que certains points n'ont pas leur timestamp, il suffit d'ajouter le même temps que le point précédent. Le logiciel ajoute de lui-même une fraction de seconde, qu'on ne peut pas modifier, ou alors je ne sais pas comment le faire.

Capture_gpx_editor_01.JPG
J'ajoute un timestamp sur le point qui n'en possédait pas.

Il ne nous reste plus qu'à corréler les photos avec la trace gpx et ajouter la direction. Justement, en parlant de direction, il n'existe que très peu d'outils permettant de l'ajouter automatiquement aux photos. Mapillary propose un script python qui le permet, mais pour calculer la direction d'une photo, il regarde où est la photo suivante et pointe vers elle. Moi ce que je voulais, je l'ai expliqué plus haut, c'est utiliser le point suivant de la trace Gpx. J'ai donc modifié leur script de corrélation pour intégrer cette fonction. Il est disponible ici, mais n'est plus utile, car entre temps cette possibilité a été ajoutée dans le script d'origine. Avec lui, je peux en une seule fois écrire la position et la direction de la photo.

python geotag_from_gpx.py "e:\gare saint-lazare\cam_droite" "e:\gare saint-lazare\trace-saint-lazare.gpx" --time-offset 3600 --bearing-offset 90
  • e:\gare saint-lazare/cam_droite est le chemin du dossier contenant les images e:\gare saint-lazare\trace-saint-lazare.gpx est le chemin du fichier gpx
  • --time-offet 3600 est le décalage temporel en secondes entre le timestamp des photos et la trace gpx, ici 1 heure.
  • --bearing-offset 90 est l'angle en degrés entre la direction de la trace gpx, et l'orientation de la caméra. Pour la caméra avant, la valeur aurait été 0, 180 pour l'arrière, et -90 pour la gauche.  

C'est terminé ! On peut charger les photos dans Josm et les utiliser pour ajouter des données...sauf que...sauf que....

Capture_josm_v4mpod_03.JPG
Où sont mes 3 autres photos ?

Hey ho ! j'étais censé avoir 4 photos à chaque position, et pas une seule !

En fait, elles sont bien là, sauf que les groupes de 4 ont les mêmes coordonnées et se retrouvent parfaitement superposées. Impossible de sélectionner facilement celle qui nous intéresse. En pratique, les caméras ne sont pas les unes sur les autres, elles sont écartées de plusieurs centimètres, alors reproduisons cette réalité en les déplaçant par rapport à ce point central. Je n'ai pas trouvé d'outil existant pour déplacer des images en utilisant leurs coordonnées et leur direction, alors j'ai écrit un script qui le fait. Ouaip ! J'étais fier de moi lorsqu'il a commencé à tourner correctement :-) Tu peux le télécharger ici

python move_picture.py "e:\gare saint-lazare\cam_droite" 0.5
  • "e:\gare saint-lazare\cam_droite" est le chemin du dossier contenant les images
  • 0.5 est le déplacement à appliquer, en mètre, dans la même direction que celle stockée dans l'image.

Et voilà le résultat :

Capture_josm_v4mpod_04.JPG
 

Tu pourrais me dire que ce qu'on obtient, c'est 4 photos pointant dans 4 directions, mais pas une seule à 360°. C'est vrai, mais Josm ne sachant pas afficher correctement ce type d'image, il valait mieux en rester là, et il me fallait déjà environ 1h de travail de localisation pour 1h de photos. Mais si toi tu désires le faire, alors des outils comme Hugin le permettent, et ça peut donner ceci :

V4MPOD_viewer_360.JPG
Clique sur l'image pour visualiser le panorama.

 

Quant au résultat de tout ce travail de cartographie, il devrait être intégré prochainement dans l'application mobile Transilien, et est déjà visible sur le site web spécialisé dans l'affichage des données indoor présentes dans OpenStreetMap : OpenLevelUp

Budget :

Voici un récapitulatif de ce qui est nécessaire pour fabriquer le V4MPOD, et le budget nécessaire :

  • 4 Xiaomi Yi : 4x70€ = 280€
  • 4 cartes µSD 32Go : 50€
  • 2 Batteries avec 2 sorties USB : 53€
  • Pied de micro : 25€
  • Support Smartphone : 60€
  • Quincaillerie, câbles, etc : 20€

Total : environ 500€

Évolutions possibles :

  • Ajouter des caméras permettrait d'augmenter la surface de recouvrement entre photos, ou bien obtenir une photo sphérique, à la Google StreetView.
  • Je pense coller un disque métallique sur le capot supérieur en bois du V4MPOD pour venir y poser une antenne GNSS magnétique dans le cas d'une utilisation en extérieur.
  • Pour pallier la complexité de la localisation des photos en intérieur, je pense tenter d'utiliser un Lidar à bas coût, et utiliser des outils de SLAM (vidéo de démo) qui permettent de se positionner par rapport aux murs et obstacles divers. Si ce principe a l'air de fonctionner correctement dans des pièces vides, je ne sais pas comment cela se comporte dans des lieux parsemés de personnes en mouvement.
  • Mponerine reste une application assez basique, et lui ajouter des fonctions telles que le timelapse, ou la configuration simultanée de plusieurs caméras, pourrait être assez pratique.
  • Les caméras sont commandées depuis le smartphone, et le délai entre chaque capture ne peut pas descendre sous les 4 secondes, alors que les fonctions de timelapse internes à la caméra, peuvent descendre sous les 2 secondes. De même, les caméras ne réagissent pas toutes instantanément, il y a parfois plusieurs centaines de millisecondes entre l'une ou l'autre. Pour contourner ces problèmes, j'imagine bien des petits servo moteur qui appuieraient simultanément sur le déclencheur des caméras, ou alors, encore plus précis, venir se connecter directement sur le circuit imprimé de la caméra pour les déclencher depuis un module arduino, ou autre.
  • J'espère avoir le temps de monter le V4MPOD sur un vélo, et trouver un système de stabilisation pour corriger l'angle dans les virages.
  • La Géo-localisation des photos lorsqu'on n'a pas ou plus de trace gpx est assez rébarbative à faire, et en cas d'erreur il faut souvent revenir plusieurs étapes en arrière. Un logiciel facilitant ce travail serait un gros plus, et pourrait être utile dans de nombreux cas (tunnel routier, enregistrement corrompu, etc..). Si quelqu'un est motivé pour ajouter ces fonctions dans Josm, il pourrait rendre de grands services. Je me lancerais bien, mais le temps que j'apprenne les connaissances nécessaires, la localisation indoor sera devenu courante.

Depuis la création du V4MPOD, Yi technology (le nom du fabricant, qui s'est émancipé de Xiaomi) a sorti un nouveau modèle, la Yi 4K, et ils font partie du programme "Jump" de Google. A priori, dans cette configuration, les caméra sont parfaitement synchronisées entre elles à l'aide d'un genlock. C'est à suivre de près, mais le budget n'est plus le même. De quoi aller titiller la rolls des systèmes de prise de vue sphérique fait-maison, OpenPathView ? À surveiller aussi, l'API que commence à développer Yi : Yi Open Api, mais qui semble oublier pour le moment la première génération de caméra..

vendredi 16 septembre 2016

Construire son V4MPod pour prendre des photos à 360° - Partie 1

V4MPOD_Mponerine.jpg

Cartographier l'intérieur d'un bâtiment peut être une tâche très complexe, surtout s'il s'agit d'un environnement chargé de nombreux éléments comme...une gare... et c'est exactement ce qu'on m'a demandé il y a quelques mois, puisque Carto'Cité m'a sollicité pour le projet de la SNCF-Transilien consistant à cartographier dans OpenStreetMap l'intérieur des six grandes gares de Paris

Pour faciliter le repérage des différents éléments (services, commerces, guichets, etc...), il était évident qu'il fallait pouvoir prendre des photos à 360°. Les quelques produits disponibles sur le marché étaient soit de qualité assez moyenne, soit bien trop cher.

Mais rappelle-toi mon compte-rendu de l'opération libre de Chéméré, j'avais déjà 2 caméras grand-angles, des petites Xiaomi Yi. Il "suffisait" d'en ajouter 2, et de les faire fonctionner ensemble pour obtenir des photos sur 360°. Maintenant, je vais te montrer comment j'ai procédé.

Lire la suite

mercredi 6 janvier 2016

Mise à jour 2016 du calendrier de ramassage des déchets

 

 

Lire la suite

samedi 19 décembre 2015

Conversion de fichier csv vers ics

Après avoir manipulé les fichiers csv de ramassage des déchets de la CCVC, je cherchais à me passer du calendrier Google pour l'héberger chez moi. Très rapidement j'ai dû trouver une solution pour convertir les fichiers csv vers le standard iCalendar, dont l'extension est ".ics". N'ayant  […]

Lire la suite

mardi 3 novembre 2015

Comment contribuer à OpenStreetMap ?

Il existe de nombreuses façons de participer au projet OpenStreetMap, et beaucoup d'entre-elles ne demandent qu'un niveau modeste en informatique. Parfois il vaut mieux avoir de bons mollets et un certain sens de l'observation, que d'être expert en raccourci clavier. En voici une liste  […]

Lire la suite

dimanche 18 octobre 2015

Compte rendu de l'Opération Libre à Chéméré

IMG_20150925_160450_1_.jpg

Le week-end du 26-27 septembre 2015 se déroulait la 3ième édition de l'Opération Libre, cette fois-ci à Chéméré, en Loire-Atlantique. Je n'y étais pas principalement en tant que contributeur à OpenStreetMap, mais plutôt pour la prise de photos géolocalisées pour Mapillary. Préparatifs : Le programme  […]

Lire la suite

mardi 14 juillet 2015

Contribuer à Mapillary en voyage

support_voiture.jpg

Il y a quelque temps, je préparais une petite semaine de vacances en Irlande. Au programme, un road trip sur une partie de la "Wild Atlantic Way" . Cela signifiait un peu plus de 1000km en voiture à un rythme de touriste, c'est à dire...lent. La situation était idéale pour prendre le  […]

Lire la suite

lundi 25 mai 2015

Visite virtuelle de la nouvelle gare de Gorges

En tant que contributeur à OpenStreetMap, j'avais pour projet de faire un passage à la nouvelle gare de Gorges pour repérer les nouveaux aménagements et les intégrer à cette carte collaborative et libre. Parmi les méthodes possibles pour faire le repérage sur le terrain, il y a l'enregistrement de  […]

Lire la suite

samedi 25 avril 2015

Utilisation des fichiers du calendrier de ramassage des déchets

Après avoir traité le fichier csv contenant toutes les dates de ramassage des déchets de la CCVC, pour en créer un par zone, venons-en à une partie plus concrète : comment les utiliser. Si je veux pouvoir consulter le calendrier de collecte à n'importe quel moment, il doit être à portée de main, et  […]

Lire la suite

dimanche 19 avril 2015

Liens vers les calendrier Google de ramassage par zone

Ci-dessous, la liste des différentes zones avec le lien pour visualiser le calendrier en ligne, ainsi que l'adresse ical pour l'intégration du calendrier dans son compte Google. Aigrefeuille-sur-Maine bourg : Adresse ical :  […]

Lire la suite

dimanche 12 avril 2015

Traitement sur le fichier du calendrier de ramassage des déchets.

Excel_-_conversion_timestamp_-_date.PNG

Il y a quelque temps, j'ai contacté la Communauté de Commune de la Vallée de Clisson sur sa page Facebook pour tenter d'obtenir un fichier csv contenant les dates de ramassage des déchets par zone géographique. Mon constat était que : Le calendrier papier n'est pas très facile à lire. Si je parviens  […]

Lire la suite

samedi 11 avril 2015

Premier billet

Bienvenu sur cet espace dans lequel je parlerai d'un peu de tout, d'où son nom de "Butineur", et en particulier de pas mal de choses commençant par "Open". Il y aura donc d'OpenStreetMap, de l'Open Data, de l'Open source. Mais il sera aussi question de l'informatique en général  […]

Lire la suite

Haut de page