GoPro & Linux

Hello,

Je viens de publier une partie de tes demandes.

Les widgets acceptent à présent :

Code:

<widget width="160" height="40" position="top-left" align="vertical">
....
    <with-label>false</with-label>
    <with-picto>false</with-picto>
....
</widget>

J'ai regardé également pourquoi le texte était moche lors du rendu image par image. Il faut que tu modifies la couleur du texte :

Code:

    <text-color>#ffff0000</text-color>

J'ai modifié la valeur du canal alpha

Et j'obtiens :

Bonjour,

Super ! je vais tester ça illico

Pour le canal alpha, je ne pige pas trop, d'autant moins que ça fonctionne parfaitement avec alpha à FF sur une vidéo.
Alpha est bien l'opacité, non ? Si elle est nulle on ne devrait pas voir le dessin ?

J'ai testé les margin-xxxx en lieu et place du margin tout court, ça marche nickel

En revanche, il y a un problème d'affichage dynamique des valeurs calculées par delta.
Voici 4 frames successives au changement de "seconde". On passe par 4 valeurs différentes.
Cela produit un effet désagréable toutes les secondes lorsque les valeurs varient.



Est-ce du à ton filtrage sur 3 cycles ?

@+
Pulsar33

Ah oui, là tu as trouvé un joli problème.

J'ai enfin compris. J'ai fait une correction que j'ai mise en ligne. Je pense que cela devrait être bon...

Du coup, j'ai ajouté une option pour la génération du CSV (puisque le but est de pouvoir visualiser les données sans faire de rendu qui est long !!!)

Et jusqu'à présent, la génération du CSV était échantillonnée toutes les secondes. Or lors de la génération de la vidéo, on échantillonne bien plus.

Avec la commande "telemetry" on peut ajouter l'option "--rate 25" pour 25 fps. Et ça affichera toutes les données, comme si on était dans la vidéo.

A présent, on voit bien les lignes "constantes" : data = 'C' (donc data = 'M' pour les mesures, data = 'P' quand c'est calculé / estimé)

Bien sûr le moyennage que je fais sur 3 points s'appliquent sur les données M ou P ; quand c'est constant, c'est constant

Sans doute un bug de moins.

Oupsss !

Je n'ai pas encore testé le mode telemetry mais ce que je peux dire :
- En mode image, tout semble très bien fonctionner
- En mode video, pente, vitesse et altitude restent bloquées aux valeurs initiales et la durée évolue curieusement alors que l'heure évolue normalement ( 0:00:08 au lieu de 0:01:19 par exemple)

Bonne recherche
Pulsar33

Bonjour,

Objectif atteint pour la génération sur fond vert, aux quelques remarques près ci-dessous

- le résultat avec alpha à 00 sur les widgets est satisfaisant mais je n'ai toujours pas compris cette contrainte en mode image contrairement au mode video.
- la variation à la seconde s'avère acceptable à défaut de mieux. Il n'y a plus de variation saccadée au passage des secondes sur la pente et la vitesse.
- les images générées ont le même format que la vidéo d'entrée (dans mon cas 720 x 576) mais ne respectent pas le DAR ( 16/9 dans mon cas).
- j'ai donc été contraint d'appliquer une correction géométrique sur l'overlay lors de l'incrustation avec Kdenlive, dont l'impact est forcément négatif.
- un effet pervers de la génération sur fond vert est que les fonds de contraste qui dans mon cas étaient gris semi-transparent apparaissent verts au final.

Il faudrait que je fasse une mesure précise de tout le processus mais je pense que [mode image + génération vidéo + chroma key sous Kdenlive] est notablement plus court que [mode video]
Je crains néanmoins que cela ne condamne les fonds de contraste semi-transparents

Voici un exemple de résultat en l'état actuel

Nota : la caméra étant juste au dessus du moteur, le son est parasité électriquement par celui-ci, d'où le bruit (inaudible en réalité). Pas eu le temps de le filtrer

Dans l'attente de la correction en mode video
Pulsar33

Bonsoir,

Tant que j'y suis, une petite incohérence :
Le marker position est bien ancré sur sa pointe (centre du bas de l'image) => c'est parfait
En revanche, les markers start et end sont ancrés au centre de leur image respective.
C'est gênant, surtout que je souhaite remplacer ces markers par des images asymétriques pour éviter qu'ils ne se chevauchent.
Nota : des images de 96 x 48 ont été acceptées mais des images de 96 x 96 n'ont pas été visibles.

Bonne soirée
Pulsar33

Bonjour

Essai du mode "compute" (telemetry) :
- La génération du csv est très rapide même avec l'option --rate 25
- Le post-traitement nécessaire du csv est très lourd (l'éditeur de texte galère) : remplacer , par ; puis remplacer . par , puis importer avec séparateur ;
- Importer directement le csv en l'état et remplacer les . par des , n'est pas plus rapide ni moins gourmand
=> suggestion : option --lang fre ou -- lang eng pour choisir un format francisé ou le format actuel
- L'importation du csv sature à 65536 lignes (on ne peut guère en vouloir à Libreoffice, c'est déjà énorme). Or pour 1h22 j'ai 123000 échantillons ...

A partir de là, on peut ajouter des filtres et des graphiques.
Pour l'instant honnêtement, je n'arrive pas à grand chose avec la pente.
J'essaierai à l'occasion de trouver des idées et faire des essais.

Bonne journée
Pulsar33

Bon ben là, la balle est dans ton camp

Je vais certainement faire des montages cet été. Donc va falloir que je corrige tout cela.

Ca va peut-être te choquer, mais j'utilise VIM pour ouvrir le csv (avec des plugins pour gérer les csv)

Bah non, ça ne me choque pas mais j'ai peu pratiqué Vim et je ne suis pas certain qu'il s'en sorte mieux sur un fichier de 123000 échantillons

Bref, pour l'instant, mon problème est que la commande video ne fonctionne plus.
Si tu pouvais au moins débloquer cela ...

Bon courage
Pulsar33

Pulsar33 a écrit:

Bah non, ça ne me choque pas mais j'ai peu pratiqué Vim et je ne suis pas certain qu'il s'en sorte mieux sur un fichier de 123000 échantillons

Bref, pour l'instant, mon problème est que la commande video ne fonctionne plus.
Si tu pouvais au moins débloquer cela ...

Justement avec vim, 10 lignes ou 100 000 c'est pareil, bref...

Quel est le problème avec le rendu vidéo.

J'ai réussi à générer ta vidéo de 6 minutes.

Le résultat de tous mes derniers essais est détaillé dans les quatre messages consécutifs ci-dessus ...
Entre autre, les valeurs pente, vitesse et durée sont bloquées ou erratiques en mode video contrairement au mode image

Pulsar33 a écrit:

- En mode video, pente, vitesse et altitude restent bloquées aux valeurs initiales et la durée évolue curieusement alors que l'heure évolue normalement ( 0:00:08 au lieu de 0:01:19 par exemple)

@+
Pulsar33

Pulsar33 a écrit:

Le résultat de tous mes derniers essais est détaillé dans les quatre messages consécutifs ci-dessus ...
Entre autre, les valeurs pente, vitesse et durée sont bloquées ou erratiques en mode video contrairement au mode image

Pulsar33 a écrit:

- En mode video, pente, vitesse et altitude restent bloquées aux valeurs initiales et la durée évolue curieusement alors que l'heure évolue normalement ( 0:00:08 au lieu de 0:01:19 par exemple)

@+
Pulsar33

Donc je devrais le voir avec ta video et ton gpx.

Quelle commande gpx2video utilises tu ? (Les options)

Pour info :
D'autres valeurs sont bloquées, y compris le déplacement du marker et de la carte selon le mode --telemetry utilisé avec la commande video
Il faudrait que je prenne note des différents essais mais ça ne t'apporterait pas grand chose, de toute façon, ça ne fonctionne pas.

Sans vouloir polémiquer, dès lors que tu dois remplacer tous les points par des virgules sur toutes les lignes, 10 lignes ou 123000, c'est forcément pas pareil, même avec Vim
L'intérêt d'importer et traiter sous Libreoffice, c'est de pourvoir tracer des courbes plus simplement et plus variées, mais aussi de pouvoir ajouter des traitement et comparer les résultats (comme le filtrage que je t'avais indiqué il y a quelques temps en langage excel)

@+
Pulsar33

Nos messages se sont croisés

Code:

/media/DATA/Workbench/gpx2video/build/gpx2video -q -m Jonzac04O.mp4 -g Jonzac04O-VG.gpx --offset 9000 -l layout576p04TP.xml --telemetry 3 -o Jonzac04TP.mp4 video

Pulsar33

Je t'ai mis en ligne une correction... en espérant que ça fixe le problème !

Merci
C'était quoi le problème ?

Je teste en fin de soirée sans doute
Pulsar33

Pulsar33 a écrit:

Bonsoir,

Tant que j'y suis, une petite incohérence :
Le marker position est bien ancré sur sa pointe (centre du bas de l'image) => c'est parfait
En revanche, les markers start et end sont ancrés au centre de leur image respective.
C'est gênant, surtout que je souhaite remplacer ces markers par des images asymétriques pour éviter qu'ils ne se chevauchent.
Nota : des images de 96 x 48 ont été acceptées mais des images de 96 x 96 n'ont pas été visibles.

Les markers font 132x200, il ne faut pas changer leur taille.
Et il suppose que la pointe est à 25 pixels du bord.

C'est le même process pour les 3 markers, donc si il y a un problème, il y a un problème sur les 3 markers.

Code:

<marker>...</marker> // pour changer la taille des markers

Ah ok pour les markers. J'avais juste changé la couleur du cycliste mais en revanche changé la taille de end et start, ce qui explique que 2 seulement ne fonctionnaient pas.
Je vais revoir ça.

Ok, j'ai vu la modif et j'ai lancé. C'est corrigé à première vue
Tests plus complets asap et retours demain

Merci
Bonne soirée
Pulsar33

Pulsar33 a écrit:

- le résultat avec alpha à 00 sur les widgets est satisfaisant mais je n'ai toujours pas compris cette contrainte en mode image contrairement au mode video.
- la variation à la seconde s'avère acceptable à défaut de mieux. Il n'y a plus de variation saccadée au passage des secondes sur la pente et la vitesse.
- les images générées ont le même format que la vidéo d'entrée (dans mon cas 720 x 576) mais ne respectent pas le DAR ( 16/9 dans mon cas).
- j'ai donc été contraint d'appliquer une correction géométrique sur l'overlay lors de l'incrustation avec Kdenlive, dont l'impact est forcément négatif.
- un effet pervers de la génération sur fond vert est que les fonds de contraste qui dans mon cas étaient gris semi-transparent apparaissent verts au final.

Attention, une image video n'a pas de composante alpha (elle ne peut être transparente.

Par contre, j'accepte la transparence pour générer les images.

Pour la résolution & le DAR, tu as le même problème en rendu vidéo alors ? Du coup une image de 50x50 devrait être déformée pour être appliquée sur ta vidéo. Quelle déformation, veux tu que j'applique. Je vais regarder ce problème.... en fait faut être capable d'afficher un carré, carré et un rond, rond !

Je réponds rapidement car on m'attend.

Non, une vidéo gère le DAR et n'a donc pas le problème.

Une vidéo a une résolution, un pixel aspect ratio et un display aspect ratio. Une vidéo en 720x576 peut être présentée en 16/9 si c'est ce que disent ses paramètres
Alors qu'une image, ben, elle a une largeur et une hauteur en pixels, point barre.

Je pense qu'il faudrait juste intégrer le DAR de la vidéo mais faudra que j'y réfléchisse plus. On voit ça demain.

@+
Pulsar33

Bonjour,

Pour la taille des images générées sur fond vert, tu utilises actuellement la résolution de la vidéo entrante (720x576 dans mon cas). Or comme déjà dit, une vidéo contient des paramètres qui définissent la taille d'affichage indépendamment de la résolution. Il est tout à fait possible d'encoder une vidéo en 720x288 (ratio de résolution 5/2) et qu'elle s'affiche nativement en 16/9 (DAR).

Si les images sur fond vert ont pour but de créer une vidéo qui sera ensuite incrustée avec un éditeur non linéaire, il faut passer par une commande ffmpeg pour assembler les images en une vidéo. On peut considérer que le DAR doit être introduit lors de cette étape, ce qui est tout à fait possible. Mais globalement du point de vue de ton projet, générer des images au format 5/4 lorsque la vidéo entrante est au format 16/9, je trouve ça un peu dommage.

Pour ma vidéo, avec Mediainfo, on voit :
Width                                    : 720 pixels
Height                                   : 576 pixels
Display aspect ratio                     : 16:9

Avec ffprobe (si tu préfères) on voit :
Stream #0:0(und): Video: mpeg4 (Simple Profile) (mp4v / 0x7634706D), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 5106 kb/s, 25 fps, 25 tbr, 12800 tbn, 25 tbc (default)
On retrouve facilement 720x576 ... DAR 16:9

Le format 720x576 est historique et toujours utilisé malgré la prédominance désormais des formats HD. De mon point de vue, il faut générer une image de largeur 576x16/9 et de hauteur 576. En gros, le plus simple est d'ignorer la largeur de la vidéo entrante. On obtient donc des images de 1024x576, c'est à dire le format utilisé pour le rendu de la vidéo.

En effet dans ce cas particulier, les ronds risquent de ne pas être ronds et les carrés pas carrés. Mais c'est déjà le cas en mode vidéo. Voici le rendu vidéo surchargé du rendu (identique) de l'image sur fond vert déformée comme je te l'indique.


@+ pour d'autres retours sur la commande video
Pulsar33

Bonsoir,

Pour exprimer les choses de manière plus formelle que ci-dessus, si la vidéo entrante est de résolution Width x Height et de ratio d'affichage DAR, la commande image doit générer des images de largeur=(DAR x Height) et de hauteur=Height

Concernant la commande video, j'ai tenté les valeurs 3, 2, 1 et 0 pour --telemetry. Je confirme ce que tu disais. Avec un gpx à la seconde, je ne vois pas vraiment de différence. Par principe, je vais conserver 3 surtout qu'il ne semble pas y avoir d'impact sur le temps de calcul.

Bonne soirée
Pulsar33

Mise à jour de mes constats :

A confirmer : [mode image + génération vidéo + chroma key sous Kdenlive] semble notablement plus court que [mode video]
Nota : Les markers font 132x200, il ne faut pas changer leur taille. Le point d'ancrage est situé à 66 x 175
Nota : L'importation du csv sous Libreoffice sature à 65536 lignes soit une vidéo de 43 minutes
Nota : Le post-traitement nécessaire du csv est très lourd : remplacer , par ; puis remplacer . par , puis importer avec séparateur ;

- BUG : perte systématique de la piste sonore du milieu de la vidéo jusqu'à la fin (qu'on arrête l'encodage ou qu'on le laisse terminer)
- Option --lang fre ou -- lang eng pour choisir un format francisé ou le format actuel pour la génération du csv
- Option Zoom automatique en fonction de la vitesse (4 paramètres) : (Zmax,Zmin) = F(Vmin,Vmax) (augmenter la portée quand on va vite)
- La variation à la seconde s'avère acceptable. Peut-on faire mieux si le gpx a une fréquence plus élevée ?
- Pourrait-on utiliser au choix un gpx ou un csv au format que tu génères y compris avec l'option --rate ?
- Le résultat sur fond vert avec alpha à 00 sur les widgets est satisfaisant mais cette contrainte en mode image est incohérente du mode video
- La commande image doit générer des images de largeur=(DAR x Height) et de hauteur=Height (Width doit être ignoré)
- Un effet pervers de la génération sur fond vert est que les fonds de contraste (gris semi-transparent par exemple) apparaissent verts au final

- perte (pseudo)aléatoire de certains widgets (pente, vitesse, durée) visiblement calculés par différence => corrigé
- le fond vert n'est présent que sur la première image (testé seulement en 576p) en mode image => corrigé
- finesse de la trace dans la map fonction de la résolution de la vidéo (actuellement pâteuse en 576p) => paramétrable, ok
- option rendu sur fond vert dans l'espoir de booster notablement les performances => solution partielle via image puis ffmpeg
- cercler l'icone vélo de jaune (surtout la pointe) au lieu de bleu (actuellement même couleur que la trace) => ok, assets modifiables
- option incrustation sans légende ni symbole => ok grâce à with-label et with-picto
- variation saccadée au passage des secondes sur la pente et la vitesse => corrigé

Bonne nuit
Pulsar33

Bonjour

Super le résumé

Pour libreoffice, quand je fais l'import je peux choisir le caractère de séparation. Et dans le formatage des cellules, je peux indiquer le format des nombres.

Je n'ai pas vu de GPX échantillonné à moins d'une seconde. Mais on pourrait calculer des points intermédiaires.

Je vais travailler sur le problème "alpha".
En fait l'option shadow sur le texte créé un hallo noir sur la vidéo car une vidéo n'a pas de canal alpha.
Mais lord du rendu en image, j'opte pour un PNG avec un canal alpha. Et la fonction shadow créé alors un hallo sur le canal alpha (et non noir). Dit autrement, ça fait un trou dans l'image. Et donc pas le rendu attendu lors de la superposition sur la vidéo.

Je vais corriger ce problème, comment ? Je ne sais pas encore. Mais en corrigeant cela, je pourrai faire une optimisation en générant une image que je ne régénère qu'à chaque rafraîchissement des données de télémétrie et non à chaque frame de la vidéo.

Ensuite, je fixerai le problème de l'aspect DAR.

Puis en 3eme, je dois régler un problème remonté par un autre utilisateur, c'est gérer les vidéos avec orientation (exemple gopro en mode portrait). Même si maintenant le rendu image solutionne partiellement le problème.

Bonsoir

progweb a écrit:

Pour libreoffice, quand je fais l'import je peux choisir le caractère de séparation. Et dans le formatage des cellules, je peux indiquer le format des nombres.

Le changement de caractère de séparation n'était utile que si l'on remplaçait les "points" par des "virgules" pour les flottants à l'extérieur de Libreoffice (éditeur de texte)
Importer en l'état et changer le format des cellules est non moins galère. Finalement j'ai trouvé comment faire :
Il faut sélectionner une Langue Anglaise dans le formulaire d'importation. Les flottants xxx.yyy sont alors compris, pas besoin de remplacer les points par des virgules.

Nota : Le post-traitement nécessaire du csv est très lourd : remplacer , par ; puis remplacer . par , puis importer avec séparateur ; => inutile
- Option --lang fre ou -- lang eng pour choisir un format francisé ou le format actuel pour la génération du csv => utiliser le choix de la lange anglaise lors de l'import

Bonne soirée
Pulsar33