nouvel essais pour textures sat

[guesnel]

la premiere scene que j'avais faite pour Fly1, ( brest ), j'avais utilisé des images sat glanées a droite et a gauche
résultat , j'avais pas pensé a la rotondité de la terre et apres le 1er texturage j'avais LFEC LFRB et LFRJ étaient bien plaqué mais dés qu'on alait sur LFLV et LFRQ il y avait un bon décalage

en ce moment j'expérimente un tecnique qui semble un peu mieux quoi que plus longue et ardue

je prend une image de nima en B/N qui est orthonormé et je procède ainsi

- je récupere la même zone en image sat ( la définition n'a pas d'importance car je vais en fait travailler sur la couleur )

je met l'image sat a la même echelle que l'autre
je cherche l'inclinaison a donner par secteur ici environ 3° horaire( cause de la rotondité)
je prélève de petites surface de l'image sat que je plaque a l'endroit désiré
POUR CELA je plaque cette image en calque a 40% d'opacité, ce qui permet de bien poser l'image je travail en fait avec les ombres et les secences de pixels
une fois toute la zone couverte je travaille la saturation pour redonner de la chaleur a l'image et je tour est joué
Jusqu'a maintenant j'utilisais colorBMP mais pas toujours satisfait du résultat puisqu'on moyenne sur une teinte
je mets a cette adresse l'exemple d'une construction
et deux pics de Fly2 en vol mais ne faites pas attention aux couleurs pales
c'est la derniere phase qui concistera a donner de la saturation correcte
voir a l'adresse :http://gilles.guesnel.free.fr/travaux/
allez y pour les remarques

[roland_lfor]

c'est très très interressant mais comment as tu récupéré les images couleurs (à droite et à gauche, c'est ou ?)

Quelle est leur résolution ?

[BOB_J]

Alors là, moi je dis bravo, expérimentons, en attendant des images couleurs SPOT5 libres (pardon, pour SPOT5, je n'ai pas pu résister à lancer une blague!)

Je dois te dire que j'ai un peu potassé, essayé, remanié, transmuté et le pb, c'est naturellement la perte de résolution dûe aux franges avec une photocomposition en surperposition simple.

Pour la question de Roland, nous avons un sacré choix dans les images Landsat. Les capteurs (multispectral) de ce type de satellite permettent d'obtenir une image couleur à environ 30m/pixel de résolution.

Une bonne partie des images couleurs à 10m/pixel fournies par une foule de sociétés spécialisées en animation sont obtenues par composition entre images couleurs à 30m et panchro à 10m. L'exemple le plus diffusé est la France vue du ciel de M-sat, un CD à quelques dizaines de balles.

La première difficulté est d'obtenir des images prises à la même époque, ensuite certaines opérations deviennent complexes lorsque la résolution, la finesse de l'image est critique et c'est précisément notre cas avec nos 7,5m/pixel : en substance, les blocs de pixels de l'image couleur ne devraient servir que d'échantillons, chaque couleur étant répartie sur des surfaces délimitées par les formes et les niveaux de gris présents sur l'image n/b.

On colorise du 50cm par pix n/b avec du 30m couleur sans bavure, parole, c'est faisable et j'ai des solutions mais en pro et avec du temps devant soi...

Je suis personnellement toujours revenu sur une colorisation directe, par masques (style "gouvernemental" US) ou par ColorBMP, cette dernière solution restant la plus rationnelle, même si elle nécessite du doigté dans le paramétrage de cet utilitaire. Il est vrai qu'il faut avoir une sacré patience pour jongler avec les curseurs, mais une fois que j'ai ma palette, bingo! ensuite, j'ajuste les tonalités n/b pour que ça colle pour d'autres phototypes.

La finesse du produit à slicer joyeusement est d'une importance capitale pour l'aspect du produit fini. En général, les images SPOT gagnent à être régénérées, le filtrage bilinéaire adoucissant bézef en finale.

J'attaque les actions Photoshop pour simplifier...

Bon courage!

[roland_lfor]

J'en profite pour te remercier Bob : à la suite de tes explications de Juillet, je me suis mis à faire quantité d'essais et j'avoue que j'étais plus que sceptique sur la phase colorisation.

En fin de compte c'est très impressionnant pour peu que l'on se donne le temps de trouver la bonne palette. Je garde toujours la même maintenant et je ne fait qu'ajuster les "levels" en fonction de l'image.

Comme tu le préconisais le traitement amont dans PSP 7 par exemple (unsharp mask et automatic contrast enhancement) permet de changer complêtement le piqué de l'image finale et donc le réalisme de la scène.

La première fois que j'ai essayé de faire une scène bord de mer, je me suis aperçu qu'il fallait founir un masque en blanc et noir sous peine d'être "tout terrestre".

Phénomène interressant, on peu faire des dégradés et des niveaux de gris sur ce masque pour gérer des transparences variables.

C'est très sympa sur des bancs de sable ou des embouchures de bras de mer : on voit le fond de l'eau en transparence

Par contre le découpage des cotes à la baguette magique PSP prend un temps énorme pour le faire proprement. Mais le résultat le vaut. D'ailleur, cette solution aurait pu être faite sur nice j'imagine pour le sortir des eaux

Question subsidiare : peut on changer la couleur de l'eau générique dans FlyII que je trouve beaucoup trop claire ? dans le sky.ini ?

Autre astuce : tous mes aéroports étaient toujours un peu décalés par rapport à la texture jusqu'au moment ou je me suis aperçu qu'à un moment unique sur le moteur NIMA, on a accès aux coordonnées lower left et upper right avec 6 décimales. A ce moment ma vie a changée
J'ai calculé la scène de Paris et chaque aéroport tombe parfaitement sur les traces de l'image

Il ne faut donc pas oublier de noter ces coordonnées à 6 décimales (sur la page de confirmation de download).

Grace à toi donc (à cause de toi dirait ma moitié), je me suis décider à créer, créer des textures afin que l'ATR et le P51 soient au mieux de leur forme au moment de leur arrivée

Rest un problème apparemment quand on calcule une scène débordant sur une tile déjà custom, ça plante. Une idée ?

[Didier_LFRS]

Bonjour Roland

Autre astuce : tous mes aéroports étaient toujours un peu décalés par rapport à la texture jusqu'au moment ou je me suis aperçu qu'à un moment unique sur le moteur NIMA, on a accès aux coordonnées lower left et upper right avec 6 décimales. A ce moment ma vie a changée

As tu vérifié la position des taxiways une fois ces valeurs changés ? Je pense qu'effectivement au départ de la création de la base de données de Fly 1 àu 2 il y a eu un pb d'arrondi ou de conversion des valeurs de la NIMA ce quifait qu'entre les 2 versions il y a eu des différences et aussi avec la réalité.

Didier

[roland_lfor]

Pour l'instant je n'ai vérifié que les pistes et tout colle parfaitement, je n'ai pas vérifié les taxways mais c'est un peu plus difficile à isoler sur les images satellite.

Je vais voir ça...

[Yv]

Et aura-t-on droit à quelques previews, histoire de nous faire rêver un peu ? :D

Yves

[BOB_J]

Les fichiers NIMA sont géoréférencés, les infos sont incorporées, d'ou l'appellation GeoTIFF...
Les prgm graphiques classiques ne récupèrent que l'image, mais c'est là quand même.
Il en existe 2 sortes : celle avec un petit fichier lié, celle où le code est sournoisement incorporé, invisible pour le non initié moyen comme nous avant que la lumière ne le frappe.

Action subtile, puisque les (certains) programmes spécialisés dans le traitement de ces images savent lire et utiliser ces infos. J'ai utilisé un archétype du genre : IDRISI32, pour cela et surtout pour d'autres fonctions de traitement spécifiques, hélas, le produit est très loin d'être gratuit, aussi me suis-je tourné vers SPRING, produit en freeware (si!) de l'agence spatiale brésilienne.

Avec ce type de produit, on peut travailler les images, mosaïquer, mélanger, superposer, surcoucher avec des produits vectoriels, comme ceux utilisés par terrascene par exemple, sans se coucier des échelles tant que tout est géotruqué.

Sympa pour faire coïncider les routes, les contours... Interfacé avec terrascene, ce sera mignon comme joujou!

Les décalages...

Achtung! ne cherchez pas l'erreur, c'est normal! l'orthocorrection des images ne veut pas dire que tout sera parfaitement à sa place sur tout le territoire, bien au contraire! mais le positionnement est tout de même garanti à plus ou moins 25m près... Seule solution : shooter carrément l'image décalée de l'aéroport, en remplacant la couleur des pixels rendus blanchâtres à cause de la réflexion par un beau vert herbeux, par exemple sur le tga. C'est là qu'il faut donner libre cours à son sens artistique.

[roland_lfor]

Décidément je ne réussi pas à faire cohabiter plusieurs scènes qui se recouvrent légèrement :

J'ai essayer en laissant tout dans le répertoire data => pas bon
J'ai essayé en créant des POD avec un fichier SCF dont les coordonnées sont précises => il me manque tout un morceau !

Donc, je pose la question suivante : Bob, coment fait-on pour créer des pod successifs permettant d'agrandir petit à petit la zone couverte : faut-il qu'ils se juxtaposent au pixel près, ou bien faut-il que chaque calcul de scène couvre précisément une tuile ?

J'ai vu tes scènes du sud de la France et j'imagine que tu as eu le même problème à résoudre.

Bref quel est le mode opératoire du découpage des images NIMA en fonction des POD à créer pour que tous les POD s'affichent ?

[BOB_J]

Que je vais devoir résoudre...

Etonnant, je confirme : le fonctionnement est possible lorsque tout est dans le répertoire data, mais les temps de chargement sont naturellement longs et les pauses "café" sont fréquentes. On peut facilement imaginer que le prgm soit dans l'obligation de gamberger fort pour nous improviser un affichage correct, ne sachant pas à l'avance ce qu'il doit montrer en l'absence de fichier de description.

En fait, toute la subtilité réside dans le fichier .scf, le reste du pudding-podding étant chargé de redistribuer les data dans les sous rép, soit de la poudre de perlinpinpin étant donné qu'on ne peut plus s'échanger actuellement les fichier sous cette forme (à 70Mo, c'était sympa, à 250, bonjour!) et qu'il vaut mieux s'échanger les bitmaps.

La cause est entendue : il faut en principe que les scènes soient générées par tuiles globales ENTIERES à cause des textures distantes, on peut bien sûr modifier les textures sans réecrire la bouillie du fond, mais il faut la créer au moins une fois cette bouillie. Une chose logique qui parait en découler : il faut que la photo recouvre totalement les tuilus globus concernées pour que celles-ci soient reproduites convenablement.

Je n'ai pas eu l'occasion de tester toutes les finesses du podocollage moderne à la fly!II, mon soucis actuel étant déjà de savoir comment persuader l'éditeur intégré de fonctionner correctement dans tous les cas pour que les adeptes du MAC ne se retrouvent pas avec un chouette bitmap grand format tout juste bon à montrer en poster. Question posée et restée sans réponse, soit dit en passant, sur Avsim, soit je dis une c...... soit personne ne pige et je parle le british aussi bien que le Mandarin, soit c'est le sujet supposé vachard qu'il ne faut pas poser en période de crise.

Je retourne à flyslice pour lui faire comprendre la chose, au fait, à l'autopsie, cela donnera...

#
# fly2slice import file generated by TerraScene
#
-
-
specificGlobeTile.enabled=false (deviendra true)
specificGlobeTile.x=0 (c'est celle là que je veux, mon pote!)
specificGlobeTile.z=0 (idem)

[roland_lfor]

En fin de compte j'ai regardé comment travaille Terrascene :
La plus petite zone de couverture correspond exactement à un quart de tuile (première subdivision dans Fly!).

Ce n'est évidemment pas un hazard. Je vais donc charger sur NIMA les 4 images avec les coordonnées exactes données par Terrascène , puis je vais créer 4 POD avec tout ça et si ça cohabite proprement, le mode opératoire sera clairement établi.

Si ça ne marche pas, Hou là là, il faudra créer une seule image avec les 4 et ça va commencer à ramer pour le traitement

A propos, je repose la question : comment fait on pour changer la couleur de l'eau générique dans Fly2

[FRED38]

Un petit conseil:
déborde un peut de chaque cotés pour etre sur, de pas grand chose, moins d'un super tiles, fly ne le traitera pas mais ca evitera qu'il te rogne un super tile si tu est trop juste!
pour l'eau, moi je l'inclus dans la zone traiter, la photo sat inclu les cotes, et de ce fait, on a l'impression des courants et des profondeurs!

[roland_lfor]

Bon, bon ça ne fonctionne pas même avec des .SCF aux petits oignons

Mais je suis tétu et je vais essayer avec Fly2Slice ...

A propos quels avantages est-il susceptible d'apporter par rapport à l'éditeur interne

Y a t il d'autres ligne de commande possible que celles utilisées par Terrascene Une doc existerait ...

[roland_lfor]

Je vois que chacun a des recettes différentes :

Peux tu détailler un peu ta gestion des tuiles, est ce que tu laisses tout en brut dans "Data", créé tu des POD si oui de quelle manière, à quelle moment utilise tu 'terrain fixer' ?

Je sais je suis curieux mais j'aimerai bien avoir une recette fiable à 100% (recette que je n'ai pas encore trouvée)