Il me semble que vu les résultats et l'explosion de taille sur le serveur de tuiles pour produire les différents niveaux de zoom, il serait judicieux d'une part de convertir les JPEG en une seule image PNG géante par un prétraitement minimaliste conservant toute la résolution et les couleurs, puis convertir ce PNG en un fichier unique à codage progressif permettant au serveur de répondre directement à une requête de tuile).
Même si on a 6,5Go de données avec les tuiles iniales en JPEG, leur conversion en une seule image PNG ne devrait pas dépasser les 50 Go. Ensuite pour produire les images aux autres niveaux de zoom (en divisant par 2, puis 4, puis 8 chaque dimension), cela peut se faire en quelques heures et toutes ces images ensemble ne représentera pas plus de 50 Go non plus. Donc un total voisin de 100 Go au lieu des 139Go obtenus, tout en conservant toute la précision et la colorimétrie. Avec un codage progressif dans une seule image, pour pourrait réduire le volume d'un tiers environ, soit de l'ordre de 65 Go (et très probablement beaucoup moins car plus on zoome et plus la redondance devient importante et le codage différentiel devient performant). Si le serveur de tuile utilise ce seule fichier unique à codage progressif, le nombre d'accès I/O pour une tuile ne sera jamais supérieur au niveau de zoom, tout en profitant d'un cache en mémoire élevé et efficace pour les premiers niveaux. Aure intérêt : on sollicite beaucoup moins les systèmes de fichiers et l'OS. Faire 16 I/O pour récupérer une tuile à servuir au nieavu 16, sachant que les premiers niveaux sont presque toujours en cache (et qu'il y a ensuite une grande chance que des tuiles voisines soient aussi demandées, de sorte qu'on augmente le nombre de hits sur les tuiles différentielles de pas mal de niveaux supplémentaires), permettrait d'avoir un serveur de tuile à la fois très performant, et très stable. Des solutions existent déjà (et servent justement pour afficher sur le web des photos à très haute résolution et de grande taille en pixels). On en a une démo sur Wikimedia Commons, qui sait même servir une unique image JPEG sans codage progressif à la volée pour un affichage tuilé "à la demande", le code Javascript ou le code Flash côté client pouvant s'occuper lui-même de faire la recomposition des niveaux progressifs, ou s'il ne le supporte pas, utilisant une autre requête du serveur pour qu'il renvoie les tuiles fusionnant les niveaux progressifs différentiels). C'est très rapide, très efficace, et cela permet à tout le monde de pouvoir regarder même sur un navigateur avec peu de mémoire des photos très grandes et en très haute résolution (en utilisant le chargement progressif, à partir du niveau de zoom le plus bas dans une zone d'afichage de tailel réduite tenant dans la fenêtre disponible). Une telle solution n'est-elle pas possible pour les serveurs de tuiles TMS et pour optimiser leur stockage local (notamment pour optimiser le système de fichiers utilisé) et réduire aussi les temps I/O en maximisant l'utilisation de son cache mémoire, donc aussi pour pouvoir servir plus de requêtes vers plus de monde ? Le 5 février 2013 01:47, Sébastien Dinot <sebastien.di...@free.fr> a écrit : > Bonsoir Jean-Guilhem, > > Jean-Guilhem Cailton a écrit : >> Les orthophotoplans de Toulouse, réalisés à partir de prises de vue >> aériennes de juillet 2011 et 2007, avec une taille de pixel de 12,5 >> cm, et libérés par Toulouse Métropole, sont disponibles en TMS sur >> wms.openstreetmap.fr. > > Existe-t-il un « howto » ? :) > > J'avais effectué quelques essais de mon côté avec GDAL (gdalbuildvrt + > gdal2tiles.py) mais : > > - j'obtenais au final 2,5 millions d'images pour 139 Go de données alors > que les 416 tuiles initialement fournies par la ville de Toulouse > représentaient 6,5 Go de données ; > > - la manipulation entraînait une dégradation légère mais perceptible de > l'image ; > > - le traitement nécessitait 65 heures de calcul sur mon PC, les outils > n'étant pas multithreadés et ne sachant pas tirer partie des 4 cœurs > disponibles. > > La curiosité technique me pique donc : quels outils as-tu utilisés ? > Sont-ils complexes ? As-tu fait des choix particuliers qui expliquent le > faible dégradation de qualité de l'image finale par rapport à l'image > initiale ? _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
