Bon, je viens de vérifier que l'encodage se passe bien avec la vidéo 30 Hz constant Je relance l'encodage complet. Résultat dans environ 2 heures @+ Puls
Pour info : lors d'un point fixe de plus de 3 minutes avec ce GPS et 10 satellites utilisés, un outil de mesure fournit les déviations standard suivantes : Latitude 1.20 m Longitude 0.80 m Altitude 1.50 m
Ceci étant, sur la vidéo, la pente erronée de 59% ne varie pas pendant tout le point fixe de presque 2 minutes Juste avant le point fixe on passe par des valeurs farfelues lors de la décélération. J'ai vu fugitivement du 75%
Fin d'encodage dans un peu plus d'une heure @+ Puls
Et bien malheureusement ça ne vient pas de là Que la vidéo soit à 30 Hz constant ou variable telles qu'elles sont décrites plus haut, le résultat est le même Avec une vidéo à 30 Hz, on "épuise" les données moins vite qu'avec une vidéo à 25 Hz, et pourtant ça ne semble pas être dans le ratio 25/30
Va falloir être attentif ... Bonne soirée Pulsar33
progweb Posteur d'or
Messages : 577 Localisation : France VPH : ICE VTX Black Date d'inscription : 25/04/2020
Sujet: Re: GoPro & Linux Dim 27 Oct 2024, 17:49
Oui quand le déplacement est très faible, je le considère nul. Et je compte temps, moyenne à partir de 3-4km/h. Ça sera configurable.
Tes vidéos en 25fps sont correctes. Mes vidéos sont en 50fps et je n'ai pas vu le soucis.
Quand tu encodes une vidéo avec gpx2video, j'affiche l’avancement avec la durée de la vidéo.
Donc je ne devrais pas non plus afficher la bonne durée de vidéo.
Zut, j'ai fermé le terminal. Ceci étant, je n'ai que 00:21:03 de données pour ce trajet alors que la vidéo fait 01:00:01 L'encodage va jusqu'au bout de la vidéo avec les incrustations bloquées, c'est normal. Mais on voit bien à l'endroit où ça se bloque qu'on arrive au bout des données plus tôt en 25 Hz qu'en 30 Hz Au prochain encodage, je mémoriserai ce qui est dans la console à la fin
Pour la pente si je comprends bien, tu as bloqué à un moment où malheureusement le calcul était déjà parti en vrille à cause d'un déplacement trop faible. Le filtrage des données devrait résoudre ça et t'éviter de bloquer arbitrairement, ce qui présente toujours des effets de seuil.
A 00:19:20 la vidéo montre que je quitte le point fixe et ce n'est qu'à 00:19:32 que les donnée incrustées commencent à bouger. Tu affiches bien la bonne durée de vidéo et la vidéo générée fait bien la bonne durée aussi C'est juste que les données ne sont pas "consommées" assez vite dans un ratio que je ne m'explique pas
Je ne sais pas si c'est utile de chercher le bug dans ton code actuel puisque tu vas sans doute tout casser au niveau ré-échantillonnage Mais c'est un cas de test que je passerai sur les prochaines versions
Bonne journée Pulsar33
progweb Posteur d'or
Messages : 577 Localisation : France VPH : ICE VTX Black Date d'inscription : 25/04/2020
Sujet: Re: GoPro & Linux Lun 28 Oct 2024, 10:01
Mmh je vais rester concentrer sur l'amélioration des calculs.
As tu un gpx à me donner pour tester le filtrage ?
Aujourd'hui je travaille sur ma descente de la planvhe des belles filles qui est très représentatif des problèmes de précision gps !
Je te prépare un zip de données utiles ... @+ Puls
progweb Posteur d'or
Messages : 577 Localisation : France VPH : ICE VTX Black Date d'inscription : 25/04/2020
Sujet: Re: GoPro & Linux Lun 28 Oct 2024, 11:02
A 12:47:56 (à 15:25 du temps de lecture), je tombe à 6 km/h en pleine descente !
J'ai commencé par améliorer gpxtools pour travailler et afficher les données pour mieux tester...
Ci-dessous, la courbe de la latitude. On y voit bien "des plats"... et effectivement j'ai des points dans le GPX qui se suivent dont les coordonnées sont strictement les mêmes alors que le timestamp est différent !
Ce que l'on peut déjà faire (sans parler de fitre !), je ré-échantillonne en supprimant des points :
Les commandes pour faire cela :
Code:
# Convertion du GPX en CSV (mode raw "aucun traitement") ./tools/gpxtools -i activity.gpx --begin "2023-08-07 12:45:39" --end "2023-08-07 12:50:00" -o data-none.csv convert
# Interpolation à 3 seconds (donc je supprime potentiellement des points) ./tools/gpxtools -i activity.gpx --begin "2023-08-07 12:45:39" --end "2023-08-07 12:50:00" --telemetry-method=0 --telemetry-rate=3000 -o data-interpolate.csv compute
Note: gpxtools peut lire et convertir un gpx en csv ou inversement.
Le résultat sur la courbe de vitesse :
Bien sûr ce n'est pas la solution... on perd de l'info, on ne supprime pas forcément les bons points !
Pour afficher une courbe :
Code:
$ cat data.gnuplot # Title set title 'GPX2video Telemetry'
set grid
set xdata time set timefmt "%s" set format x "%H:%M:%S" set xlabel "Time"
set datafile commentschars "#"
# $1 : colonne 1 que je convertis en timestamp à la seconde # 7 : colonne 'latitude' plot "data.csv" u ($1/1000+7200):7 w lp t 'latitude' pt 5 ps 2 lt 5 lw 2 lc rgb "blue"
pause mouse close
Code:
$ gnuplot -p data.gnuplot
progweb Posteur d'or
Messages : 577 Localisation : France VPH : ICE VTX Black Date d'inscription : 25/04/2020
Sujet: Re: GoPro & Linux Lun 28 Oct 2024, 12:52
J'ai poussé la mise en place de ton filtre (pour test).
Code:
# Pour activer le filtre --telemetry-filter=1
L'implémentation (si tu veux changer les coeff) :
src/telemetrymedia.cpp : filter() - ligne 265
cette méthode est appelée à chaque ajout d'un nouveau point.
Bien sûr ce n'est pas la solution... on perd de l'info, on ne supprime pas forcément les bons points !
Je partage en effet cette idée. Il faut introduire le moins d'exceptions possibles. Je reformule mon message du 29 août à la lumière de ce qu'on s'est dit depuis :
Si la plupart des vieux GPS fournissaient des coordonnées à la seconde, il semble que désormais cette limitation est abolie. Comme par ailleurs, les vidéos sont encodées à des fréquences pouvant être comprises entre 25 et 60 Hz voire plus, avec même des valeurs exotiques genre 29.97 et même des fréquences variables, il faut bien se résoudre à rééchantillonner le plus proprement possible en fonction du timing de sortie. A cet effet il y a au moins deux méthodes basiques connues : le plus proche voisin et l'interpolation linéaire (le traitement vectoriel ne semble pas utile à ce niveau de précision souhaité).
Si tu veux t'en sortir, il faut procéder par étapes : 1) parser "bêtement" les données entrantes (GPX ou CSV) lat/lon/alt/time étant nécessaires et suffisantes pour faire le job 2) rééchantillonner celles-ci en fonction du timestamp de chaque frame de la vidéo de sortie, idéalement par interpolation linéaire entre les deux timestamp les plus proches. Je n'ai pas expérimenté d'autres données, n'en disposant pas, mais le même mécanisme s'applique sans doute aisément 3) Une fois cette liste ordonnée de points 4D obtenue et calée sur la vidéo de sortie (il est simplificateur de faire ce traitement d'un seul bloc), il convient de constater que les données de position 3D sont bruitées
Comme déjà dit et démontré, le bruit sur les lat/lon relativement à l'affichage nécessaire pour la map et la trajectoire n'est absolument pas significatif et un filtrage de ces coordonnées à cet effet est même plutôt défavorable car il aplatit les trajectoires. On utilise donc les lat/lon brutes pour la carte et la trajectoire.
En revanche, il n'en est pas du tout de même pour l'altitude ni pour la vitesse qui dérive des coordonnées 3D. Un filtre du deuxième ordre avec un coefficient d'amortissement de 0.7 sur 6 cycles donne de bons résultats. Ce filtre nécessite de mémoriser les deux points 3D précédents pour calculer le point courant et le résultat doit être décalé de 6 cycles pour absorber le retard dû au filtre. On utilise donc lat7/lon7/alt7 pour calculer les valeurs à incruster dans l'image 1 pour laquelle la carte et la trajectoire sont positionnées au même instant en fonction de lat1/lon1. On peut ainsi afficher une altitude et une vitesse propres.
Reste à calculer la pente qui n'a effectivement de sens que si la vitesse n'est pas nulle ou presque. Si la vitesse est inférieure au seuil choisi, on peut afficher des tirets, ce que tu faisais passé un temps il me semble pour certaines valeurs, ou conserver la pente en cours, ce qui n'est pas mauvais puisque même arrêté on est toujours "sur la pente". Je pense que la pente calculée à partir des coordonnées 3D filtrées devrait être relativement propre. Au pire on verra alors s'il faut lui faire subir un traitement supplémentaire. Il ne faut pas perdre de vue que ce que l'on doit afficher doit donner une bonne idée facilement perceptible de la réalité sans pour autant avoir une précision absolue. La pente du terrain ne varie pas violemment en permanence. Le filtre peut être assez fort sur cette valeur si besoin.
Voilà ma vision des traitements après corrections et précisions par rapport à mon texte précédent. Qu'en pense-tu ?
@+ Puls PS : du coup je n'ai pas fini l'archive que je devais t'envoyer. Je m'y mets maintenant
progweb Posteur d'or
Messages : 577 Localisation : France VPH : ICE VTX Black Date d'inscription : 25/04/2020
Sujet: Re: GoPro & Linux Lun 28 Oct 2024, 15:03
Pulsar33 a écrit:
Si la plupart des vieux GPS fournissaient des coordonnées à la seconde, il semble que désormais cette limitation est abolie. Comme par ailleurs, les vidéos sont encodées à des fréquences pouvant être comprises entre 25 et 60 Hz voire plus, avec même des valeurs exotiques genre 29.97 et même des fréquences variables, il faut bien se résoudre à rééchantillonner le plus proprement possible en fonction du timing de sortie. A cet effet il y a au moins deux méthodes basiques connues : le plus proche voisin et l'interpolation linéaire (le traitement vectoriel ne semble pas utile à ce niveau de précision souhaité).
Tout à fait... mais il y d'autres points à prendre en compte.
Effectivement les GPS permettent d'avoir des données toutes les millisecondes... mais dans les faits, je travaille depuis un GPX qui offre la plupart du temps des points échantillonnés à la seconde (voir davantage). Ce qui est logique, à vitesse constante, ça ne sert à rien d'avoir plein de points par exemple. De plus, les appareils (GPS vélo, GoPro...) ont des contraintes de taille.
Enfin, le dernier élément et le plus important, je n'échantillonne pas en fonction du nombre de fps... à vélo, à pied, à la nage... la vitesse varie suffisamment peu pour ne pas à avoir à actualiser les données à chaque image. Mais en voiture, moto, avion... il faut pouvoir échantillonné davantage. Donc ce paramètre "--telemetry-rate" est laissé libre à l'utilisateur. (son unité est la milliseconde). Par défaut, à 1000 ms. L'énorme avantage est que ça me permet de faire des optimisations lors du rendu. (pas besoin de refaire le rendu des widgets à chaque frame, mais à chaque changement des données).
Pulsar33 a écrit:
Si tu veux t'en sortir, il faut procéder par étapes : 1) parser "bêtement" les données entrantes (GPX ou CSV) lat/lon/alt/time étant nécessaires et suffisantes pour faire le job
Ce point est fait. J'ajoute également un filtre sur la validité de la donnée (exemple si le couple latitude / longitude est strictement le même que le point précédent, j'ignore le point).
On voit ici que le second point est forcément faux !
Pulsar33 a écrit:
2) rééchantillonner celles-ci en fonction du timestamp de chaque frame de la vidéo de sortie, idéalement par interpolation linéaire entre les deux timestamp les plus proches. Je n'ai pas expérimenté d'autres données, n'en disposant pas, mais le même mécanisme s'applique sans doute aisément
Exact (sans lien au framerate)
Le ré-échantillonnage est nécessaire pour le filtrage.
Exemple, ton filtre est un filtre passe-bas d'ordre 2. Et il a besoin d'un échantillonnage constant pour être correct ; "puisqu'il n'a pas la connaissance temporelle de chaque point".
Pulsar33 a écrit:
3) Une fois cette liste ordonnée de points 4D obtenue et calée sur la vidéo de sortie (il est simplificateur de faire ce traitement d'un seul bloc), il convient de constater que les données de position 3D sont bruitées
Comme déjà dit et démontré, le bruit sur les lat/lon relativement à l'affichage nécessaire pour la map et la trajectoire n'est absolument pas significatif et un filtrage de ces coordonnées à cet effet est même plutôt défavorable car il aplatit les trajectoires. On utilise donc les lat/lon brutes pour la carte et la trajectoire.
En revanche, il n'en est pas du tout de même pour l'altitude ni pour la vitesse qui dérive des coordonnées 3D. Un filtre du deuxième ordre avec un coefficient d'amortissement de 0.7 sur 6 cycles donne de bons résultats. Ce filtre nécessite de mémoriser les deux points 3D précédents pour calculer le point courant et le résultat doit être décalé de 6 cycles pour absorber le retard dû au filtre. On utilise donc lat7/lon7/alt7 pour calculer les valeurs à incruster dans l'image 1 pour laquelle la carte et la trajectoire sont positionnées au même instant en fonction de lat1/lon1. On peut ainsi afficher une altitude et une vitesse propres.
Reste à calculer la pente qui n'a effectivement de sens que si la vitesse n'est pas nulle ou presque. Si la vitesse est inférieure au seuil choisi, on peut afficher des tirets, ce que tu faisais passé un temps il me semble pour certaines valeurs, ou conserver la pente en cours, ce qui n'est pas mauvais puisque même arrêté on est toujours "sur la pente". Je pense que la pente calculée à partir des coordonnées 3D filtrées devrait être relativement propre. Au pire on verra alors s'il faut lui faire subir un traitement supplémentaire. Il ne faut pas perdre de vue que ce que l'on doit afficher doit donner une bonne idée facilement perceptible de la réalité sans pour autant avoir une précision absolue. La pente du terrain ne varie pas violemment en permanence. Le filtre peut être assez fort sur cette valeur si besoin.
Voilà ma vision des traitements après corrections et précisions par rapport à mon texte précédent. Qu'en pense-tu ?
Par rapport à ta solution de filtrage, je suis d'accord (d'ailleurs aujourd'hui je ne prends pas en compte le retard induit).
Je suis en train de mettre d'autres type de filtre : - filtre exponentiel simple - filtre exponentiel double
puis je vais remettre mon filtre... que je dois améliorer. En effet dans notre cas, le plus judicieux est d'utiliser un filtre moyenneur en utilisant les points voisins. On connait pour un point, les points précédents mais aussi les points suivants.
Ce type de filtre reste simple, et n'introduit pas de retard.
Pour l'instant à la vue des différents GPX que j'ai, je pense qu'on n'aura pas une solution unique et universelle qui marche automatiquement.
Mais l'utilisateur devra appliquer certains filtres en fonction de la qualité de ses GPX.
Je me demande si lisser également les valeurs calculées (vitesse, pente...) ne seraient pas bénéfiques également.
Je ne suis pas d'accord sur certains points mais je n'aurai pas le temps d'argumenter ce soir.
De la même manière, je n'aurai pas le temps de finaliser l'archive que je devais t'envoyer car justement, en vérifiant les éléments, je suis tombé sur des choses étranges. Les vidéos générées peuvent être de l'un ou l'autre type ci-dessous :
La durée des vidéos est de 6:21 dans les deux cas d'après le lecteur vidéo Le point fixe démarre à 3:26 et se termine à 4:49 d'après le lecteur vidéo Les durées gpx2video affichées à ces deux instants par la vidéo 25 Hz sont les mêmes que celles indiquées par le lecteur vidéo Les durées gpx2video affichées à ces deux instants par la vidéo 30 Hz sont inférieures respectivement de 2 et 3 secondes La durée gpx2video affichée à la fin de la vidéo 25 Hz est de 6:20 La durée gpx2video affichée à la fin de la vidéo 30 Hz est de 6:17
Les caractéristiques des vidéos sont les suivantes. Celles qui ont _ovl dans leur nom ont été générées par gpx2video Les autres sont les vidéos source de 6:21
Mais j'ai aussi eu des caractéristiques "constantes" sur des vidéos (plus longues) générées par gpx2video Je ne comprends pas cette indétermination. Y aurait-il une variable non initilisée dans tes traitements ?
Désolé pour ce retard (va falloir songer à passer à la fibre) Pulsar33
Bonjour, Merci pour les corrections et évolutions. Le problème 25/30 Hz est effectivement corrigé.
Coté ré-échantillonnage, je garde mes réflexions issues des échanges précédents pour moi pour l'instant, néanmoins les points ci-dessous en découlent en partie. Mon filtre ne peut pas fonctionner de manière satisfaisante si le retard n'est pas compensé et si les données générées sont à la seconde. Ce n'est pas les données d'entrée le problème. Elles peuvent varier aussi lentement qu'on veut. Mais un cycle d'une seconde et une constante de temps de 6 cycles, ça ne peut pas le faire. Je comprends bien que tu veux optimiser en réduisant le nombre de rendus mais ça n'empêche pas de faire les calculs des valeurs à la fréquence image de sortie. Il est alors toujours possible de ne pas faire le rendu si la valeur n'a pas changé assez pour que ce soit visible. Mais la valeur doit changer si l'on veut filtrer proprement.
Je n'ai pas encore fait d'essai qualitatif mais je crois que je vais devoir décaler le GPX car je l'avais calé en fonction du rendu d'avant et ce n'est plus la même chose. A première vue, les données sont à la traîne de 2 ou 3 secondes par rapport à la vidéo il me semble (à 25 comme à 30 Hz)
A première vue, les données sont à la traîne de 2 ou 3 secondes par rapport à la vidéo il me semble (à 25 comme à 30 Hz)
Je confirme. Il faut enlever les trois premiers points du GPX
Avec --telemetry-filter=3 --telemetry-method=3 --telemetry-rate=1000 c'est correct sur la vitesse mais la pente est toujours aussi perturbée
J'ai tenté --telemetry-filter=1 --telemetry-method=3 --telemetry-rate=40 et --telemetry-rate=66, c'est la cata sur la vitesse, ça ne fonctionne pas du tout
@+ Puls
progweb Posteur d'or
Messages : 577 Localisation : France VPH : ICE VTX Black Date d'inscription : 25/04/2020
Sujet: Re: GoPro & Linux Mer 30 Oct 2024, 11:06
Oui si tu mets un rate inférieur à 1000ms il faudrait changer le nombre de cycles dans ton filtre.
Regarde mon dernier message privé concernant la pente. A l'arrêt on voit l'altitude bouger !
Dans tes gpx, les données lat / lon sont plutôt propres mais l'élévation non. Alors que sur les miens c'est l'inverse.
Pour info : lors d'un point fixe de plus de 3 minutes avec ce GPS et 10 satellites utilisés, un outil de mesure fournit les déviations standard suivantes : Latitude 1.20 m Longitude 0.80 m Altitude 1.50 m
Mais en valeurs absolues, ça peut bouger beaucoup plus que ça. Ce n'est pas dramatique car ce sont des variations lentes. Cela n'explique pas les pentes qui passent de -35 à +58 en quelques fractions de secondes.
Historiquement, les GPS avaient beaucoup plus de mal à déterminer l'altitude que les lat/lon. C'est sans doute le cas de mon Sirf Star III Je suppose qu'on a fait des progrès depuis et aussi que les USA ne brouillent plus le signal public. Il faudrait que je fasse un trajet en enregistrant ce GPS et celui de mon téléphone en même temps sauf que l'appli de mon téléphone ne fournit pas directement l'altitude Il faudrait que j'en trouve une autre, peut-être celle-ci ?
@+ Puls
PS : oui cette application est parfaite, surtout en activant la correction d'altitude EGM96 dans les paramètres.
PPS : sur plus de 3 minutes, la position verticale de mon téléphone varie de 0.70 m seulement en valeur absolue !
J'ai fait des essais avec le GPS de mon téléphone enregistré par l'application GPS Logger qui fonctionne à merveille La version "Build telemetry points pool" fonctionne globalement mais : - le paramètre telemetry-rate ne me permet pas de tester mon filtre à la fréquence voulue - en filter 3 et method 3 la pente est totalement instable et je ne sais pas si je peux croire la vitesse La pente et la vitesse sont pourtant les informations les plus importantes, avant même la durée et la distance. Je ne sais plus trop quoi tester de plus tant que ce problème n'est pas résolu
J'ai aussi un problème déjà partiellement signalé sur les CSV. Il y a un sac de noeuds entre le mode anglais/français (pour les flottants) et le séparateur virgule/double cote Il faut ouvrir le CSV généré par "compute" en mode anglais séparateur virgule pour pouvoir faire des calculs Une fois mes traitements faits, comment dois-je régler l'exportation CSV pour que gpx2video puisse l'utiliser en entrée ? (je suis sous LibreOffice)
Enfin, est-ce que "Commits on Oct 31, 2024" est utile pour les choses que je teste ?
Dans l'attente de tes commentaires et évolutions, j'ai fait un enregistrement simultané de mon GPS BT-338 via l'application Serial Bluetooth Terminal et de celui de mon téléphone via l'application GPS Logger J'ai lancé "compute" sur les fichiers obtenus avec les paramètres --telemetry-check=false --telemetry-filter=3 --telemetry-method=3 --telemetry-rate=1000 J'ai ensuite comparé les écarts et j'obtiens les écarts maximum suivants sur 3889 secondes : dLat : 0,0001139 dLon : 0,00019655 dEle : 12,784 On est donc au millième de degré sur les lat/lon et à plus de 10m sur les élévations Je pense qu'en effet mon GPS BT-338 assez ancien n'est pas très efficace sur cette variable. Par ailleurs il ne dispose pas de la correction du géoïde contrairement à l'application GPS Logger Cependant, comme déjà dit, je pense que ces dérives d'élévation sont "lentes" et ne peuvent en aucun cas être responsables des instabilités de la pente qui d'ailleurs existent aussi avec le GPS du téléphone
Je viens de comparer ma dernière trace utilisée avec la version GPX skip point if same time du 7 mai par rapport à la dernière version, il n'y a pas photo. Concernant le positionnement lat/lon et la vitesse, je n'ai pas vu mieux depuis cette version du 7 mai Pour l'altitude et pour la pente surtout, il y avait encore du boulot à l'époque mais c'est pire aujourd'hui
Bon, et bien après vérification plus poussée, il y a un problème pour les vidéos à 30 Hz que je n'avais jamais testées avec la version GPX skip point if same time du 7 mai C'est parfaitement synchro au début mais ça se décale au fur et à mesure (ex : 16 secondes de retard des données après 26 minutes de vidéo) Il faut que je génère la vidéo entrante à 25 Hz pour vérifier qu'il n'y a pas ce problème avec elle
Sujet: Re: GoPro & Linux 
