hier j’ai eu une sequence de 4051 photos découpée en 3 , aujourd’hui je viens d’avoir une autre sequence de 89 photos découpée en 2 . je crois avoir trouvé un bug qui intervient du coté de panoramax . sur les deux sequences à l’endroit où il y a un probleme une image a eu le timestamp modifié de 1 heure exactement .
exemple sur la premiere sequence :
photo Interval_20251109_111409_002018_Output.jpg
timestamp avant/apres envoi : 12:55:28/12:55:28
photo Interval_20251109_111409_002019_Output.jpg
timestamp avant/apres envoi : 12:55:32 / 13:55:32
photo Interval_20251109_111409_002020_Output.jpg
timestamp avant/apres envoi : 12:55:34 / 12:55:34
et peut être que ça a aussi impliqué le split à ce niveau car le timestamp suit l’image qui a gagné 1 heure
j’ai progressé dans ma recherche . il se pourrait que le probleme viennent d’une combinaison de josm + corrélation gpx +panoramax … ouf compliqué
j’explique quand j’utilise josm +corrélation gpx , josm modifie le timestamp des images et ajoute +1 heure aux photos ( à toutes les photos) , ce qu’il ne fait pas quand je déplace seulement les images et que j’enregistre les nouvelles coordonnées . En modifiant les timestamp josm introduirait une modification qui induit en erreur panoramax qui ajoute + 1 heure en plus à 1 image selon des conditions que je n’ai pas identifié .
au passage je viens juste de comprendre que panoramax construit l’ordre de la sequence à partir du timestamp des images et non pas à partir de l’ordre lexicographique des noms des fichiers images ( please ne pas me taper ) , ce qui donne dans le cas ci dessus , un deplacement de la photo dans la sequence à cause du +1 heure , et déclenche un split distance par la suite .
pour etre plus precis sur l’ordre des sequences et le split distance .
imaginons que j’ai 2000 images dont les noms sont nxxxx.jpg
l’odre lexicographique donne n0001.jpg , n0002.jpg , … , n0999.jpg , n1000.jpg , n1001.jpg, … , n1999.jpg , n2000.jpg . images séparées de 1 m en ligne droite .
imaginons que l’ordre du timestamp suit l’ordre lexicographique dû au fonctionnement de la caméra avec un décalage de +1 seconde à chaque fois .
Si une erreur intervient à l’image n1000.jpg qui voit sont timestamp modifié de 3600 secondes , l’ordre de la sequence basé sur le timestamp deviendra : n0001.jpg , … , n0999.jpg , n1001.jpg , … , n1999.jpg , n2000.jpg , n1000.jpg . mais entre n2000.jpg et n1000.jpg il y a 1000 mètres de distance ce qui declenche un split distance .
--sort-method [filename-asc|filename-desc|time-asc|time-desc]: Strategy used for sorting your pictures. Either by filename or EXIF time, in ascending or descending order. [default: time-asc]
donc on peut decider de l’ordre dans la sequence lors de l’envoi , par defaut il est basé sur le temps ascendant . donc pour eviter les soucis à cause des modif sur le timestamp , il faudra que j’envoie la sequence en utilisant l’option
Complément :
Pour ma part, avant l’envoie des photos, je fais systématiquement un panoramax_cli check-sequences ...
Ça me permet de vérifier que la séquence correspondra à ce que je souhaite, avant de faire le téléversement.
et la commande avait indiquée aucune erreur sinon j’aurais pas envoyé ( 4051 images !) , c’est pour ça que je crois que du coté de panoramax , il y a eu ajout de 1 heure sur l’image Interval_20251109_111409_002019_Output.jpg ce qui a par la suite declenché le split
ceci dit j’ai trouvé une solution de contournement maintenant j’utilise la commande avec ces options
dans mon cas le GPSTimeStamp prend 1 heure quand je passe par une corrélation . Mais comme c’est toute la sequence qui prend une heure ça n’aurait pas du poser probleme . Il s’est passé quelque chose de plus mais quoi ?
il y a une autre concidence entre les deux exemples cités ci dessus , j’ai envoyé les deux sequences autour de 1 heures du mat . est ce ça la cause ?
) , ce qui donne dans le cas ci dessus , un deplacement de la photo dans la sequence à cause du +1 heure , et déclenche un split distance par la suite .