Dans les outils qu’il serait intéressant de développer, il y en a un qui pourrait détecter les photos de mauvaise qualité en commençant par :
Un tel outil pourrait être développé lors d’un hackathon ou comme projet pour des étudiants.
J’ouvre le sujet pour réunir les idées et suggestions.
Si possible à rendre techniquement applicable aux séquences photos auprès des auteurs, avant que ceux-ci les publient, c’est à dire utilisable coté client à chaque fois qu’un auteur le souhaite, et au delà du repérage
Une fois la qualité des photos et/ou séquences notées, les notes automatiques seront-elles utilisées, notamment en lien avec les filtres de qualité ?
Si tout cela est proposé, chaque auteur pourra alors repérer lui-même ses séquences jugées de faible qualité, et prendre ses responsabilités, soit avant (ci-dessus) soit après leur publication.
On va déjà commencer par évaluer dans quelle mesure on peut déterminer qu’une photo est “moche” avant d’imaginer où le faire, avant le versement (client), au versement (serveur) ou plus tard (serveur ou bot externe comme panoflat).
Pour préparer une proposition de projet étudiant, il faut contextualiser pour/et motiver ! 
C’est la rentrée. C’est le bon moment pour le faire (avant 14/9, de mon coté).
Il faut suffisamment de travail pour 4 à 6 étudiants en école d’ingénieur à bac+4 pendant 1 an, soit 100h/personne tout compris, soit 400 à 600 h.
La qualification des photos en luminosité et contraste est triviale.
La qualification en netteté est simple.
La qualification de la colorimétrie demande un peu plus de travail.
On est loin du compte pour occuper 500h.
Mais je vois comment les occuper en créant une interface de
La proposition donnera de la visibilité à OSM, panoramax, aux FOSS et aux communs en général, pour ce jeune public (qui en moyenne en ignore à peu près tout). Ca me dit bien.
Après, il y a le plus souvent concurrence (mesurée), avec plus de propositions que de groupes à affecter. D’où le soin à apporter aux propositions
Outre le contenu du projet, la question de la licence applicable au code python produit – pour laquelle les étudiants candidats au projet devront donner leur accord – est ouverte. Avez-vous des suggestions ? Quelles sont les licences les plus utilisées actuellement dans l’écosystème OSM pour ce type d’outil ?
Je ne suis pas sûr que ce soit si simple. Entre des photos en terrain encaissé (naturel ou artificiel) et d’autres en terrain dégagé avec un grand aplat de ciel dégagé (ou, au contraire, des tas de petits nuages 
), contrastes et luminosités peuvent varier pas mal, les zones où on attend de la netteté aussi. Plus photos normales versus 360°.
oui, pour luminosité et contraste, obtenir un histogramme non biaisé par la projection équirectangulaire sera à faire.
Si l’on veut exclure de l’analyse qualitative les zones des zénith et nadir réels, il faudra supposer les photos déjà traitées par panoflat, avec angles de roulis (gite) et de tangage (assiette) probables connus inscrits en exif, avec un redressement préalable de la projection avant de couper.
Le projet peut être progressif. En terme de qualification voire d’amélioration des images, je pense qu’on peut dans un 1er temps déjà bien avancer avec des critères globaux sans avoir à segmenter les images pour des analyses et critères combinés zonaux plus fins et souvent inutiles. Il ne s’agit pas de faire de la détection de motifs.
D’ailleurs, pour rester dans le cahier des charges évoqué là concernant la recevabilité des photos dans panoramax, des améliorations locales sont exclues.
Du reste, il est possible que des bibliothèques python toutes prêtes et avec une licence utilisable/compatible panoramax existent déjà. C’est le 1er point qu’il faut que je vérifie !
Ne pas oublier qu’on parle d’un stock de millions de photos (et d’un flux quotidien de 100 à 200 000 photos), il faut donc que les calculs soient assez simples pour permettre le passage à l’échelle.
Pour rester dans le domaine FOSS, le logiciel de gestion/traitement de photos Digikam utilise des modèles qui détectent la (mauvaise) qualité des photos (cf. doc).
Leur IA peut aussi corriger l’orientation de la photo automatiquement (rotation de 90°, 180° ou 270°) ce qui serait aussi pratique (et pas trop hors sujet).
Dans la série vues préoccupantes :
Pour la vue capot en 360° : cela doit correspondre à une valeur fortement négative de l’angle de tangage. Pour que la visionneuse n’ait pas à faire le travail (élémentaire ?) à chaque fois que quelqu’un consulte la photo, ne s’agirait-il pas “simplement” de mettre à 0 le tangage (et aussi l’azimut exactement vers l’avant (@) ) dés que la valeur de tangage est plus basse qu’un seuil donné (par exemple -30°) ? *
(@*) si la caméra pique du nez, c’est probablement qu’il y a eu un problème de fixation / de serrage affectant également l’orientation azimutale.
vues inversées : il y a inversée et inversée. vue arrière, qui recule quand on clique sur la flèche vers l’avant, comme là ? Faudrait-il ici intervenir sur les photos, ou sur l’affectation des actions vers l’avant/vers l’arrière des 2 flèches blanches de la visionneuse dés que l’orientation de la vue sort de l’intervalle [-90°, 90°] centré sur la direction du déplacement réel ?
Par vue inversée je pense que JLZIMMERMANN veut parler de celles où le ciel est en bas et la terre en haut. On peut voir ça comme un bug de la caméra ou, plus probablement, une photo prise à un instant où une secousse a perturbé les accéléromètres de la caméra qui s’est trompée sur la direction de la gravité.
Pour ceux qui voudraient des exemples de photos “moches” pour tester ou entraîner leurs algorithmes, j’ai tagué un certain nombre de photos et séquences avec :
Reste plus qu’à faire une recherche (j’ai tagué bien plus de photos que ces quelques exemples, dommage que le filtre ne permette pas de faire une recherche par tag).