Je m’excuse si ce message aurait du être dans un topic existant.
Je voulais partager une méthode que j’utilise pour supprimer la partie inférieure de mes photos à 360° prises avec une gopro max2. Cette méthode n’ajoute aucun logo : elle consiste simplement à recadrer l’image.
convert recadre l’image et exiftool ajoute dans les méta data l’information que l’image ne couvre pas une sphère complète, pour que les visionneuses affichent correctement la photo.
Pour le faire en batch, avec 4 processus en même temps pour que ce soit plus rapide:
mkdir out && find . -type f -name '*.JPG' -print0 | xargs -0 -P 4 -I {} sh -c 'convert "{}" -crop 7680x2840+0+0 ./out/{} && exiftool -CroppedAreaImageHeightPixels=2840 -overwrite_original ./out/{};'
Ça permet également de réduire légèrement la taille des fichiers. Dans mon cas, le poids des photos diminue d’environ 17,5 % (moyenne sur ~2900 photos). Est ce que c’est pertinent pour économiser de la place sur les serveurs ?
En soit, l’envoi de ces photos est tout à fait valide, il n’y a pas de raisons de l’empêcher. C’est juste que la visionneuse a du mal à reconnaître que c’est une photo 360° juste coupée en bas, et non pas une image classique (non 360). C’est pour ça que les affichages sont un peu cassés. Je vais voir pour corriger ça… Bottom-cropped 360° are not rendered nicely (#468) · Issues · Panoramax / Clients / Web viewer · GitLab
Je ne pense pas que ce soit une bonne idée car le ratio 2:1 est un standard pour les photos équirectangulaires.
Il faudrait des metadonnées supplémentaires pour savoir quel est l’angle de champ vertical ou alors vérifier que c’est bien admis et/ou documenté que par exemple une image en 7680x2840 et pas 3840 n’a pas 180° mais 133.125° d’angle de champ vertical.
On peut adapter la visionneuse standard de Panoramax, mais ce n’est pas l’unique façon de consulter les images, pas sûr que tout le monde gère bien cela.
Par ailleurs, 2840 est une valeur qui ne tombe pas pile non plus sur les bornes à 8 et 16 pixels, il serait préférable de faire du 2848 si on valide ce principe.
J’ajoute que faire cela avec imagemagick (convert) va dégrager l’image car elle sera décompressée et recompressée. jpegtran par contre permet de ne garder que cette bande centrale sans aucune perte (pas de décompression/recompression).
D’ailleurs, le gain en poids peut aussi provenir de la recompression JPEG qui a peu de chance d’utiliser le même facteur de qualité que l’original.
j’ajoute que, grâce à la compression jpeg, le gain de poids du fichier est le même en repeignant simplement la bande du nadir en noir au lieu de couper l’image (le gain vient surtout des informations supprimées dans la bande noire)
Tu peux tester avec :
jpegtran est plus indiqué pour modifier une image JPEG sans recompression (et pas besoin de coder un script)
Si l’on n’utiliser pas jpegtran et si on veut vraiment comparer ce qu’on gagne en éliminant/ramplaçant le haut/bas de l’image, il faut le faire, il faut le faire en prenant l’image, en la convetissant sans modifier ces zones et en comparant avec la version modifiée, comme ça on aura exactement l’effet de la suppression et pas mélangé à celui de la recompression.
Le gain devrait être quand même assez faible car les parties hautes et basses sur une image equirectangulaire sont étirée et il n’y a donc que peu de détails qui vont très bien être compressés par JPEG.
Effectivement, le mieux c’est de le faire pour comparer, voici mes tests d’hier pour indication.
L’image de base fait 3.2Mio pour 5760×2880 (Qoocam 3 Ultra). Je la transforme en 5760×2000.
les résultats dans l’ordre :
la bande nadir repeinte en noire avec “magick” (2.5 Mio)
pareil avec jpeglib (2.5 Mio)
la commande convert sans couper l’image pour constater l’impact de la re-compression jpeg (3.1 Mio)
la commande convert pour couper la bande nadir (2.5 Mio)
la commande jpegtran pour couper la bande nadir (2.4 Mio)
Perso je n’avais pas pensé à cette méthode pour économiser du stockage, et c’est vrai que le toit de ma voiture n’apporte pas beaucoup de valeur… On peut éventuellement appliquer le même traitement sur le haut de l’image… (mais est-ce souhaitable ?)
Personnellement, je trouve que la bande du nadir est trop visible en noir.
De mon côté, j’avais scripté la copie/extension de la bande de 50px au dessus des 600px du bas de l’image, et ça permet d’avoir un masquage moins agressif :
Voici la commande, basée sur la dimension des JPG de la GoPro Max2 : magick "source.jpg" ( -clone 0 -crop 5760x50+0+2230 -flip -resize 5760x600! ) -gravity South -composite "resultat.jpg"
Il y a sans doute une perte liée à la recompression JPG par magick, mais en regardant les images à 100%, je ne constate pas de différence à l’écran. Et dans l’exemple ci-dessus, l’image JPG passe de 3.16 Mo à 3.04 Mo.
Si ces images sont utilisées par exemple pour regénérer de l’ortho-voirie, détecter des nids de poules voire déterminer automatiquement le type de revêtement, et bien ça donnera n’importe quoi sans que ce soit facilement détectable.
On ne devrait vraiment modifier les photos qu’à la marge, pour l’instant le logo en bas d’image est la seule chose qui est communément admise (voire un aplat).
Je comprends cette réserve, et du coup, je ne le referai plus.
Mais je précise que j’avais volontairement fait en sorte que le “flou” obtenu soit automatiquement identifiable comme artificiel. J’avais initialement fait des tentatives où l’effet était vraiment quasi invisible, mais comme c’était “faux”, je n’ai pas poursuivi dans cette voie.
L’idée était de “flouter” le photographe, comme les visages des gens qui sont eux aussi floutés.
Quelle solution serait préférable pour cela ?
Car vraiment, je suis personnellement pas fan des “trous noirs” (et puis, c’est hyper dangereux si on tombe dedans !!! )
Peut-être qu’on pourrait imaginer de récupérer juste la couleur dominante de la bande des 50 px au dessus des 600px à masquer, et appliquer cette couleur à la bande masquée ?
(j’avais abandonné les tentatives de flous sur la bande nadir, car c’était beaucoup trop gourmand en processeur pour des gros volumes de photos : là, c’est quasi instantané puisque ce n’est que du redimensionnement)
J’avoue que je ne sais pas a quel point c’est documenté et utilisé.
D’après ce que je comprends, l’application Google Camera, en mode Photosphère, ajoute ces métadonnées pour indiquer la portion de la sphère qui est présentée :
Cropped Area Image Height Pixels
Cropped Area Image Width Pixels
Cropped Area Left Pixels
Cropped Area Top Pixels
Full Pano Height Pixels
Full Pano Width Pixels.
Dans les outils que j’utilise, la visionneuse Aves sur Android et Panoramax (sauf en mode avance automatique) s’en servent déjà pour afficher correctement l’image. Par contre la visionneuse intégrée à JOSM les ignore et déforme l’image pour couvrir toute la sphère.
Est ce que le problème rencontré en mode rapide pourrait venir du fait que, quand Panoramax génère des images en basse résolution, ces métadonnées ne sont pas ajoutées?
Donc dans ce cas jpegtran fait encore mieux en gain de place sans perdre de qualité ?
Même si je comprend maintenant que la compression d’une zone de couleur uniforme sur la photo revient quasiment au même en fait…
Si mettre des gros pixels ou une couleur uniforme permet de conserver le gain de place et ne complique pas la réutilisation, je pense que j’utiliserai cette méthode !
Sinon il y a jpegmask qui permet de remplacer le nadir par une couleur uniforme en gérant le parallélisme et sans recompression, donc sans perte de qualité. Dans le cas présent cela donnerait jpegmask --mask black@x2840 srcdir/*.jpg dstdir/. Comme ça pas besoin d’écrire un script et de réinventer la roue.
jpegmask a pas mal d’autres options, notamment la gestion des nadirs non-circulaires (pas utile dans le cas présent) et le floutage, mais ne gère pas le calcul automatique de la couleur du nadir en fonction des pixels juste au-dessus. Je suppose que cela pourrait s’ajouter…
)
