.gpx und .mp4 zu was Mapillary-kompatiblen verheiraten?

Moin

Bin gerade dabei, mein Fahrrad technisch aufzurüsten …
Vor kurzem ein Navi, wenn auch nur ein einfaches, das Teasi von LIDL von kürzlich. Kann auch GPS-Spuren aufzeichnen, was ich schon 2x auch für OSM genutzt habe.

Sa. noch in eine im einen Saturn gerade runtergesetzte eine Actioncam investiert (Sony HDR-AS50). Mit den Einstellungen MP4 und 30 fps sollen über 8 h auf eine 64 GB-Karte passen, das passt zum Wunsch, auch lange Touren auf einer Karte mitschneiden zu können, u.a. als Gedächtnisstütze für Verbesserungen in OSM.

Beides alleine würde für meine eigenen OSM-Zwecke schon reichen.
Es würde sich aber auch anbieten, das eine oder andere Video auf Mapillary zu teilen, aber dazu müsste man wohl irgendwie das MP4-Video mit dem GPX verheiraten zu irgendeinem Datenwust, der kompatibel für Mapillary ist. Hat da jemand eine Idee? Entweder automatisch jedes x-te Bild, das entspräche wohl am ehesten der M.-Philosophie, wenn man die Bilder dort so anschaut … oder auch händisch gesteuerte Bildauswahl, aufwendiger, aber evtl. brauchbarer für andere …

An Software ist seit einer Weile Avidemux auf dem Rechner, damit wollte ich mal meine schon digitalisierten alten selbstgedrehten Videos weiterverwurschteln, bin ich aber noch nicht zu gekommen, und ffmpeg und das Zeugs, was man sich zur Sony runterladen konnte, was aber auf ersten Blick eigentlich nix groß kann …
Der Rechner hat Windows 7 und mit cygwin auch ein “Linux für Arme” drauf.

Kurzer Tipp der jetzt nicht direkt mit deiner Frage zu run hat aber mir eingefallen ist, weil ich auch die Sony HDR-AS50 zum mappen nutze!

Ich stelle die Cam mittlerweile zum mappen bevorzugt auf den Einzelbild-Reihenmodus. (und dort auf die Vorauswahl für unendlich viele Bilder) Das hat den Vorteil (gerade fürs mappen), dass du im Einzelbildmodus mit 4k mit 1Bild/Sek aufnehmen kannst. Mit einer genau abgestimmten Uhr kannst du später die Einzelbilder mit JOSM am GPX ausrichten. So ist zumindest mein Workflow.

Grundsätzlich kannst du das ganze natürlich auch mit Videos machen, wobei dann leider bei dieser Kamera das 4k flöten geht.
Je nachdem ob ich lieber für OSM mappe, oder lieber meine Fahrt als Video haben möchte (Ausflugsfahrten) schalte ich entsprechend um.

Falls du dann später Zeitrafferaufnahmen aus den Einzelbildern machen willst, kann ich dir *ffmpeg *ans Herz legen, insbesondere wenn du eine Grafikkarte hast die den h264_nvenc Codec (beschleunigt) nutzen kann.

Hierzu kopiere und bennene ich dann vorher die Bilder in einem temporären Ordner um, sodass eine fortlaufende Nummerierung 1.jpg,2.jpg,…,10000.jpg entsteht. Und rufe dann ffmpeg mit folgenden Optionen auf.

.\ffmpeg.exe -f image2 -i C:\Videobearbeitung\%05d.jpg -r 50 -vf "format=yuv420p" -vcodec h264_nvenc
-preset llhq -profile:v high -rc ll_2pass_quality -an -b:v 120M -pass 1 -2pass -1 -pix_fmt yuv420p C:\Videobearbeitung\output.mp4

Nur so am Rande und als Idee!

Also ich habe mit meiner GoPro auch nur Einzelbilder im 1 Sekunden Abstand aufgenommen und dann alles in der Console mit den mapillary Python Skripts die Bilder mit dem GPX verheiratet und hochgeladen.
PS: In den Skripts gibt’s auch was mit Video, habe ich aber nie getestet.

Nachtrag: und des gibt auch ein Video uploads Tutorial

Das klingt doch schon mal nach brauchbaren Ideen und Ansätzen! Danke!
Falls es Fr. was mit einer ersten großen Tour wird, dann eher im Videomodus, weil Schwerpunkt Ausflug in schöner Gegend :wink: Aber Serienbildmodus klingt auch nach testenswert …

Ich würde mal Tests mit Video und Einzelbildreihen machen.

Bei Video wird neben der geringeren Auflösung in Pixeln meist auch mit längeren Belichtungszeiten gearbeitet, da die Bewegungsunschärfe vom Mensch im Bewegtbild kaum wahrgenommen wird. Das fällt erst im Standbild auf.

Wenn es auf das Erkennen von Details ankommt, dürfte das Serienbild immer überlegen sein.

Für die Georeferenzierung von Bildern (“Verheiraten” von Bild und Track) gibt es etliche Werkzeuge (ich verwende GeoSetter), bei Video und Track dürfte das deutlich rarer aussehen. Ich hatte mal ein Navi mit eingebauter Kamera, das das konnte, sonst ist mir noch nichts dergleichen begegnet.

Wir haben mal aus nem Video immer die Keyframes extrahiert, auch mit ffmpeg, aber die Ergebnisse waren nicht super, d.h. da waren immer wieder verschmierungen/unschärfe. Ich würde da auch die Serienbildfunktion bevorzugen.

Gestern mal den Serienbildmodus für eine erste “Messfahrt” genommen, mapillary_tools runtergeladen und …

… verzweifelt … :roll_eyes:

Mal testweise die beiden ersten Bilder in ein eigenes Verzeichnis und GPS-Track und mapilalry_tools dazu kopiert.

Die Bilder haben den Zeitstempel 11:47, weil die Actioncam noch auf Winterzeit stand … :roll_eyes:
Die wahre Uhrzeit war so 10:43 GMT / 12:43 MESZ rum, genauer gesagt 56:24 min = 3384 sec Differenz.
Da fängt schon das Problem an, weil ich nirgends gefunden habe, ob das mit + oder - eingeführt werden muss oder gar andersrum gerechnet etc. pp. …

GPS-Datei fing etwas später an, da musste ich paar Zeiten dazufaken, die dabei entstandenen Dippfähler sind inzwischen gefunden …

Derzeitiger Aufrufversuch:
mapillary_tools.exe process --advanced --import_path . --geotag_source gpx --geotag_source_path test.gpx --offset_time 3384 --user_name morwas --local_time
… was eine Fehlermeldungskette rauswirft:

File "mapillary_tools", line 76, in <module>
File "mapillary_tools\command\process.py", line 145, in run
File "mapillary_tools\process_geotag_properties.py", line 89, in process_geotag_properties
File "mapillary_tools\processing.py", line 278, in geotag_from_gps_trace
File "site-packages\dateutils\tz\_common.py", line 22, in adjust_encoding
UnicodeDecodeError: 'ascii' codec dan't decode byte 0xe4 in position 11: ordinal not in range(128)
[4796] Failed to execute script mapillary_tools

Die sourcen sind runtergeladen …
Durchgehangelt könnte es was mit der local_time zu tun haben …
Also mal --local_time weggelassen, dann keine Fehlermeldungen mehr, aber auch noch keine geotags in den Bildern gefunden mit exiftools …
Mal mit -3816 versucht, so kommt man evtl. auch auf die richtige Zeit, auch nix, da dann eine Fehlermeldung kommt
“Error, capture times could not be estimated to sub second precision, images can not be geotagged.”
Versuche ich mal, mit --sub_second_intervall irgendwas anzugeben (die einzig passend klingende Option), schmeisst python wieder mit Fehlern um sich, weil smin vor Zuweisung verwendet wird …
Jetzt erst mal Nase voll …

Mit was bist du denn so unterwegs … Python 2.x oder Python 3.x? Windows? Linux?

Windows 7 direkt (oder alternativ mit einem älteren cygwin).
Ob bzw. welches Python da drauf ist, finde ich auf die Schnelle nicht.
Die relativ frische Linux-Kiste ist noch nicht ganz fertig.


python --version

Im Gegensatz zu Tcl und Perl finde ich auf diesem Laptop gerade keine extra installiertes Python (d.h. das letzte mal, als ich aktiver mit Python zu tun hatte, war wohl noch auf dem alten Laptop, also vor 2013 …), d.h. das mapillary-tool-Zeugs wird ein standalone-Teil sein …

beim cygwin wären wohl notfalls python 2.7 und 3.2 evtl. lauffähig mit dabei, falls ich mich mit den sourcen auf dem Rechner rumschlagen müsste, was ich eigentlich gerne vermeiden würde …
Hilfreich wäre erst mal, wie der Zeitversatz genau anzusetzen wäre (Vorzeichen, local oder MESZ, …) und wie das Sub-Gedöns zu umschiffen wäre …

Sorry, hatte übersehen, dass du mit dem Standalone .exe Tools arbeitest … hatte ich bisher noch nicht und selbst auch gerade nicht wirklich ein Windows am laufen.
Also local_time würde ich weg lassen und nur mit offset_time arbeiten.
Laut advanced-examples gibt man die Zeitdifferenz von Kamera zu GPS an. Sprich wenn die Kamera 11:47 hat und GPS Zeit eben 10:43 UTC ist, dann wäre es 64 Minuten, also irgendwas um die 3840 sek.
Kommt aber evtl. auch noch darauf an, ob auch deine Kamera eine “Zeitzone” in der Zeit mitliefert oder nicht, da musst du zur Not nochmal mit irgendeinem Tool (z.B. irfanview) die EXIF Daten des Bildes anschauen, was dort datentechnisch für eine Zeit drin steht.

Nö,

bei mir geht nur


wambacher@server2:~/osm/db/misc/monitor$ python --version
Python 2.7.15+
wambacher@server2:~/osm/db/misc/monitor$ python3 --version
Python 3.6.7

Übrigens habe ich selbst neulich erst wieder das Problem mit der Zeitdifferenz, da aber in JOSM. Wenn man das alle halbe Jahr mal macht braucht man ein paar Minuten, bis man sich im Klaren darüber ist, welche Differenz und dann die ganze Zeitzonenrechnerei. Habe mir irgendwann aber angewöhnt (nur neulich hab ich es vergessen zu kontrollieren), alle Zeiten auf UTC einzustellen und bevor ich einen Tracking starte, mir die aktuelle GPS UTC Zeit via GPSTest auf Android anzeigen lasse und dann in meiner Digitalkamera genau dieselbe Uhrzeit eintrage (ohne Zeitzone).

Zeitzone finde ich bei IrfanView nicht, einfach nur nackte 11:ungrad, also bei mir dann genauer 3816 sec mit Minuszeichen bei --offset_time?

Dann wäre der letzte Aufruf halbwegs richtig gewesen, trotzdem macht’s nix, wegen der schon erwähnten Fehlermeldung
“Error, capture times could not be estimated to sub second precision, images can not be geotagged.”
Diese subversive Sekunde kann mich langsam mal … :roll_eyes:

Dir ist schon klar, dass python nur ein Alias (Link) ist?


ls -la /usr/bin/python

und man das mit z.B. mit update-alternatives analog wie bei java auch ändern kann? :wink:

Demnach wäre die Subsekundenfehlermeldung egal. also mal einfach weiter machen mit Authentifizierung und so, aber anscheinend mag das Tool keine Passwörter mit Umlaut … grummel Also eins ohne organsiert … Angeblich sind jetzt die zwei Testbilder hochgeladen … Wo sieht man die jetzt?

Theoretisch demnächst unter https://www.mapillary.com/app/user/BENUTZERNAME

Wenn du angemeldet bist müsstest du auf der rechten Seite eine Leiste mit deinem Feed haben. Dort werden in der Regel dann auch bis zur Veröffentlichung “Pending images: #” angezeigt.

Klaro, nur kann ich das bei mir nicht machen, da ich sonst andere (nicht von mir geschriebene) Programme ändern müsste.

Und wer weiss, wie es bei dem Kollegen aussieht.

Gruss
walter