JPEG progressif

Bonjour,

Je contribue à Panoramax depuis quelques temps à partir de vidéos séquencées avec un script Python maison. J’ai récemment changé la chaîne de traitement du script, basée auparavant sur FFmpeg + ExifTool, pour OpenCV + piexif + ExifTool (geotag uniquement).

J’en ai profité pour ajuster l’export des fichiers JPEG avec ces paramètres OpenCV : [cv2.IMWRITE_JPEG_QUALITY, 88, cv2.IMWRITE_JPEG_PROGRESSIVE, 1, cv2.IMWRITE_JPEG_SAMPLING_FACTOR, 0x411111].

Mais hier, en tentant de téléverser une séquence sur l’instance panoramax.openstreetmap.fr via la CLI, j’ai obtenu un message du style module 'h3.api.numpy_int' has no attribute 'geo_to_h3' sur chaque image.

Après mise à jour de geovisio_cli, le téléversement s’est bien lancé mais la séquence n’a pas été publiée, les images étant toutes marquée broken.

Les seules différences entre les images issues de l’ancien script, toujours téléversées sans problème, et celle du nouveau se situent au niveau des tags EXIF et des options d’export JPEG.

Pour tester, j’ai donc converti une quinzaine d’images de cette même séquence avec XnConvert en désactivant l’option “progressif”. Et cette fois la séquence a bien été téléversée et traitée → 79b706d7-5747-4392-be81-10769cb72ac6.

Du coup, est-ce que des images en JPEG progressif (ou avec d’autres options d’export) posent problème pour téléverser sur Panoramax ?

Bonne après-midi.
Campanu.

C’est soit juste le JPEG progressif qui coince (mais je crois avoir testé), soit une combinaison avec le sampling factor (lui est bien plus gênant).

A quoi correspond cette valeur 0x411111 dans openCV ?

Merci @cquest du retour.

Dans la doc. d’OpenCV la valeur correspond au sous-échantillonnage 4x1,1x1,1x1 ce qui semble correspondre au mode 4:1:1. Mais d’après Wikipédia ce n’est pas un paramètre courant.

Du coup je crois que je me suis emmêlé les pinceaux :sweat_smile: l’idée de base c’était de garder un maximum de qualité, comme dans XnConvert avec image. Mais ça ressemble plus au mode 4:4:4.

Attention à la “fausse qualité”… car ici vu qu’on part d’un flux vidéo déjà compressé, on a une recompression qui va générer des artefacts. Si on pousse les paramètres de qualité, on va générer des fichiers lourds en grande partie pour reproduire ces défauts…

Pour l’échantillonnage, inutile de le pousser au delà de celui de la vidéo d’origine.

Exemple si la vidéo est en 4:2:2:

  • la couleur y est encodée par paire de pixels horizontaux (Chroma subsampling - Wikipedia)
  • si on la ré-encode en 4:4:4, c’est à dire pixel par pixel, ça pendra plus de place sans aucun gain de qualité, vu que l’info a été perdue bien en amont

Il faut essayer avec les paramètres par défaut.

1 Like

Pour vérifier si le sous-échantillonnage était en cause, je viens de téléverser 2 séquences d’images en JPEG progressif, une en 4:4:4 et une autre en 4:2:0, et les deux ont été traitées avec succès :slight_smile:

C’est vrai que ne je ne m’étais pas posé la question de l’échantillonnage côté vidéo. Et effectivement, pousser les paramètres de qualité ne recréera pas l’info, ça reste de la compression avec pertes.

Vu que les vidéos de ma dashcam ont un format de pixel yuvj420p d’après FFmpeg (donc sous-échantillonnage 4:2:0), je vais laisser de côté le paramètre 4:4:4.