Site web
Groupe Facebook
Wiki
Pour la portabilité, je m'y emploie, mais avec FLY!II, il y a des choses à revoir pour que le "cocher" non touché par la grâce de la création numérique ne passe pas tout le reste de son existence à maudir dieu sait qui, quoi ou surtout moi!
Après examen de recopies d'écran glanés ici ou là et expérience personnelle à l'appui, je me suis rendu compte à quel point la qualité d'une scène "photoréaliste" dépend pour sa libre création de l'assimilation d'une foule de petites choses liées en elles, telles que tonalité de départ, gamme de couleurs, finesse du grain, conversion de dimensions, etc...
En fait, il est tout aussi facile d'obtenir de la bouillie que du piqué digne d'un appareil photo moyen format à partir d'un même document si un détail nous a échappé en cours de route.
Personnellement, j'utilise la séquence suivante pour des orthophotos pancho de départ :
. Assemblage (si vous avez pris soin de récupérer des .tiff ayant les mêmes coordonnées en latitude et en jouant avec la taille de la zone de travail du programme graph, c'est du gâteau!).
. Amélioration de la définition de l'image (presque toujours nécessaire!) et harmonisation de l'échelle de gris si besoin est sur les images rectangulaires constituant la mosaïque d'origine.
. Adoption de la tonalité définitive pour adaptation à une config type de ColorBMP correspondant à la région (photo du bled, souvenir de virée).
Mon petit doigt me dit que beaucoup de gens n'osent pas reparamétrer ColorBMP, alors moi je dis : osez, osez... diminuez la dominante bleuâtre, pour commencer.
Pour tout dire, je lorgne toujours sur le coté obscur du simple-à-faire avec des moyens limités (freeware...). La saisie et la transformation d'image dans un cadre logiciel restreint mais ouvert étant le but à atteindre; il faut entendre par restreint : un nombre minimal de programme pour ne pas trop avoir à faire du transit temporaire et par ouvert : qui permet l'acceptation d'un grand nombre de format de données (photographiques, formes vectorielles, etc...).
Pour bien faire, il faut à l'heure actuelle récupérer et bien souvent traduire les données pour Arcexplorer, par exemple, extraire et traduire pour un programme de DAO, retraduire au format shp pour terrascene, récupérer le .tga dans un prgm de retouche pour intégration photographique, fusion, correction chromatique et retour pour "sliceage mûr", simple non! Je veux dire par là un tantinet coton pour le quidam normal, même bien intentionné.
Résumons... le king pourrait dire : nous voulons un engin spatial qui traite le Geotiff, le vmap0, .shp, .E00, etc... qui édite les tracés pour supprimer les zigs et les zags induits par disons... une certaine imprécision (!) des données hors Amérique du Nord ; bref, ArcExplorer, Shapefile, Autocad, un miniPhotoshop dans un même corps pour copuler avec terrascene.
J'ai effeuillé Idrisi, mais il ne fait pas tout et il faut aligner les biftons pour être réglo, maintenant je vais tâcher d'explorer Spring, il faut être polyglotte, c'est du bêta, mais c'est prometteur et gratuit. Bon, d'accord, l'appellation Spring est peut-être mal choisie, String, puique c'est Brésilien, aurait été plus évocateur, mais enfin! :D