News Panoramax.openstreetmap.fr : stockage et floutage 360

Contribuer Collecte photos
,
1

Quelques news à propos de l’instance panoramax d’OSMFR…

Stockage triplé

Le versement d’une grosse partie du stock d’images que nous avions récupéré de Mapillary est venu remplir assez rapidement les disques qui avaient été installés pour démarrer.

Ces disques disponibles n’étaient pas bien gros, des 3To mais une douzaine quand même.
Les disques sont organisés en grappes de 6 avec 2 disques de redondance… donc il y avait dans les 24To utiles.

6 disques de 10To ont été ajoutés dans la baie de stockage la semaine passée, puis testés, avant d’être ajoutés dans le pool de stockage, ce qui fait 40To utiles de plus soit environ un triplement.

La baie peut encore contenir 42 disques… et on pourra à terme aussi remplacer les 3To.

Petit bug à régler avant de se relancer dans les versements…

Un petit bug a été trouvé dans la chaîne de traitement des images, qui provoque une recompression de celles-ci qui malheureusement augmente fortement leur taille.
Ceci explique pourquoi le stockage s’est si vite remplit (environ 7To de perdus).

Une recompression des images déjà versées a démarré pour récupérer de l’espace… mais il vaut mieux attendre que le bug soit corrigé avant de refaire des versement en masse. La correction est en cours (et prioritaire).

Mise à jour: le bug est corrigé :slight_smile:

Et les sauvegardes ?

Pour l’instant, il n’y a pas de sauvegardes des photos… cela implique un doublement du stockage ou le recourt à du stockage « glacier » dans le cloud mais lent à restaurer et cher sur la durée.

Floutage des photosphères (360°) : nettement mieux !

Le floutage n’était pas très bon sur ce type de photos en grande partie à cause de leur grande largeur.

L’algorithme de computer vision qui est utilisé (YOLOv8) réduit par défaut les images pour avoir le plus grand côté à 2048 pixels avant de faire la détection et cette forte réduction rendait trop petit les visages et plaques à détecter dans de nombreux cas.
Un changement de paramètre évite désormais cette réduction sur les images très larges comme les 360 et la détection est nettement meilleure.

Un nouvel entraînement du modèle est aussi prévu pour encore améliorer la détection.

11 Likes
2

Le bug de recompression a été corrigé :slight_smile:

Vous pouvez verser sans retenue !

3

J’ai tenté de verser sans retenue, et j’ai eu un timeout au milieu d’un gros dossier.
En relançant la même commande, l’upload reprend au bon endroit, top ! :clap:
Mais de nouveau timeout, est-ce que le serveur vit un moment difficile ?

Est-ce que ce serait possible de mettre une option pour avoir un retry automatique en cas d’erreur, afin d’éviter l’intervention humaine ?

Est-ce que le traitement des images 360 étant plus lourd, ça aide si je mets --wait pour faire mon upload ?

1 Like
4

Meme probleme de timeout de mon cote en upload de photo non 360.

mais vu les stats sur serveur API ca semble etre le serveur
https://stats.uptimerobot.com/mQX5Vi5YW2/794575288

5

Idem pour moi, j’ai des timout très souvent.

6

idem.
Si ça peut aider, le timeout m’arrive presque systématiquement à la 175e photo, et il me faut ensuite attendre 4 ou 5 mn avant de pouvoir relancer. Mais ça redémarre là où ça s’était arrêté :+1:t5:

7

Il y a un pépin sur un disque système, qui ne sert pas au stockage des photos. Une reconstruction raid est en cours ce qui a quelques effets secondaires.

8

Suite des news…

  • Stabilisation du problème de disque système… pas parfait, mais nettement mieux.
  • Floutage 360 : c’est beaucoup mieux, avec deux effets de bord
    • la détection des objets lointains est meilleure, mais la détection des objets très proches peut ne pas se faire car ils sont trop gros… la solution que j’envisage c’est une détection multi-échelle, une passe taille réduite et une autre plein définition
    • la détection dans les images les plus grosses (comme celles prises par Stéphane et son fameux V6M) peut saturer la mémoire du GPU…
  • Correction d’un problème de floutage sur les photos extraites de vidéo avec ffmpeg… c’est pas parfait, l’idéal étant de ne pas demander à ffmpeg de générer des fichiers JPEG mais des PNG qu’on compresse ensuite.

Point stockage sur le serveur OSM-FR :

  • on vient de passer le cap des 4 millions de photos ! :chart_with_upwards_trend:
  • 13.6To occupés par les photos… en cours de recompression suite au bug passé qui leur a fait prendre du poids inutilement
  • 2To pour les images dérivées, les versions de basse définition ou les versions tuilées pour les images 360°
  • 52Go pour la base de données postgresql qui indexe les photos et sert à l’API
  • 47Go d’extraits d’images floutées tels que les panneaux de signalisation

On approche ainsi des 30% d’occupation de notre espace de stockage de photos.

J’ai aussi relancé des uploads du stock d’image récupérées de mapillary, celles de @overflorian !

Et voici un petit classement des contributeurs actuels :wink:


     name     |  count  
--------------+---------
 StephaneP    | 2274165
 JLZIMMERMANN | 1277369
 cquest       |  272978
 Blueberry    |  145486
 gitouche     |   74313
 zorglubu     |   25177
 overflorian  |   14953
 vnourdin     |    4751
 Yod4z        |    4014
 eMerzh       |    2579
 trouyer      |    2440
 Rom1         |    1755
 tykayn       |    1567
 Rémi_        |    1408
 Cayenne17    |     921
 Ydel         |     155
 JitenshaNiko |      64
 jcr83        |      19

Pour terminer… certaines images qui n’avaient pas pu être traitées pour une raison ou une autre (problème avec l’API de floutage ou autre) on été remises en traitement et leur nombre a été divisé par 10 (il y en a moins de 500 résiduelles).

2 Likes
9

Les images que j’ai faites pour Lons-le-Saunier cochent toutes les cases : dans les 80Mpx, 360°, et extraites de vidéos avec ffmpeg, en jpeg. @lmagreault il va peut-être falloir patienter pour les envoyer.

Tu as une idée de la raison de ce souci avec ffmpeg ? C’est lié aux métadonnées ou pas du tout ?

10

C’est l’encodeur de sortie qui n’est pas prévu pour du JPEG mais du MJPEG et privilégie semble-t-il la rapidité à la qualité.

J’ai trouvé plusieurs posts qui parlaient de ça sans toutefois constater le souci de conformité du flux jpeg.