Le portail francophone de la géomatique

Voilà qui est très intéressant. J'ai moi aussi eu ce cas. Ma solution ? Un peu bancale, vu que je n'ai jamais réussi à trouver la cause et du coup une solution efficace, c'est de faire deux catalogue raster distinct l'un avec les dalles qui allaient bien, et l'autre avec les dalles qui me posait souci. Je suis équipé Arcview 8.3.

Robin.

Dernière modification par Robin (Mon 30 July 2007 09:19)

Merci pour vos réponses !

En effet, j'avais constaté ces problèmes aussi avec ArcSDE 8.2. L'ordonnancement des couleurs de la palette n'est pas identique d'une dalle à l'autre. Le problème est considérable si l'on veut, comme moi, charger le scan 25 France entière !

Je ne me vois pas lancer un script sur un logiciel d'image pour uniformiser l'ordre des couleurs et ainsi avoir une palette identique pour toutes les dalles. Tout d'abord le scan 25 c'est 90 Go , il faut donc avoir la volumétrie nécessaire mais surtout les dalles en seraient très certainement dégradées.

De plus, la supression des fichiers .aux, .rdd ou le fait de relancer le pyramidage ne corrige pas le problème dans mon cas.

Comme je l'ai évoqué ce problème est constaté uniquement sur arcmap, arccatalog ne me pose pas se genre de problème.

Est-ce à dire que la version 9.2 d'arcGis corrige ces problèmes dans le module cartographique ?

Bref, vers qui se tourner ? Du côté de l'IGN pour tenter d'avoir une palette uniforme ou vers Esri ?

Ce problème avec les dalles de 2006 a, je pense, bloqué plus d'un utilisateur d'arcGis ces dernier temps.

Mikaël

Je ne vois pas en quoi des palettes différentes influeraient sur l'affichage des différentes couleurs à moins que vous ayez une carte graphique limitée à 256 ou 65536 couleurs, ce qui est quand même rare de nos jours même dans les trés hautes résolutions... Je pencherais plutot pour un bug qui sont nombreux dans les logiciels de traitement des images.
Les images sont forcément affichées avec 24 bits voire 32 bits de résolution pixel...

Oui, mais un logiciel chargé d'afficher une image, la moindre des choses qu'il puisse faire c'est lire la palette de l'image de manière à convertir les données dans des couleurs que comprenne la carte graphique. le fait que deux images A et B avec des palettes différentes puissent s'afficher l'un en tenant compte de la palette de l'image A et l'autre en tenant toujours compte de la palette A me laisse coi !  non ? ou alors il y a quelque chose que je n'ai pas compris ?

Bonsoir,
j'ai moi aussi constaté ce genre de problèmes, mais il y a longtemps. Autant que je me souvienne, les fichiers du scan25 n'étaient pas codés sur les mêmes valeurs pour des thématiques identiques, par exemple le bleu de l'eau est 20 sur un scan et 32 sur un autre. Aucun logiciel de traitement d'images n'est capable de savoir que 20 chez l'un veut dire 32 chez l'autre si on ne lui pas dit avant...

Pour ce qui est des fichiers .aux et .rrd, pas étonnant que ça ne résolve rien! Ca n'a rien à voir avec les codes employés pour chaque thématique. Le seul moyen est de recoder les valeurs pour qu'une thématique soit toujours identifiée par la même valeur.

J'ai juste un petit doute: les fichiers du scan25 sont codés en RGB ou en thématique (une seule couche indexée)?

Bonne soirée,
JB

De quel logiciel de traitement d'image parles tu? On a évoqué Paint Shop Pro qui mettait en évidence les disparités de palette, mais le coeur du souci semble être ArcGIS et honnêtement, en termes de traitement d'images, on connait mieux non?

La palette s'appelle éventuellement une LUT (Look Up Table) qui fait la correspondance entre le codage du fichier sur 8, 16 ou 32 bits, signés ou pas, flottants ou pas etc...  et ce que peut afficher un écran en RGB. Si on parle de couche indexée ou thématique, une valeur d'index est associée à un code couleur. Apparemment, ArcGIS définit une LUT sur le premier fichier et l'applique à tous les autres. De ce que je peux me souvenir, ça avait parfois des résultats surprenants et il me semble que c'est bien de cela qu'on parle.

Ca m'étonnerait vraiment que le scan25 soit une image sur 16 millions de couleurs! Et ça ne répond pas à mon interrogation, à savoir si le scan25 est une image indexée ou pas. Si oui, je précise ma pensée: je parlais bien de recoder une même thématique avec le même code. Je fais bien la distinction entre une image indexée et une image RGB continue.

Cela étant dit, si ce propos si aggressif a juste pour but de nous démontrer que tous les logiciels sont mauvais, que les éditeurs n'ont jamais rien compris et que tu n'as jamais eu d'outil de traitement d'images digne de ce nom, je rends les armes. J'ai mieux à faire.

Bonne soirée,
JB

Dernière modification par JB (Wed 01 August 2007 21:11)

Hello à vous,

N'oubliez pas que le propos n'est pas de démontrer telle ou telle chose, mais bien de résoudre le problème posé plus haut, qui de mon point de vue, ne semble pas résolu...

JB, je ne pense pas que christian ait été agressif dans ses propos, mais je comprend bien que le sujet du traitement d'image te tienne à coeur Une p'tite solution de la part de nos spécialistes du pixels ?

Geomatiquement,
Robin.

RE, (Robin a été plus rapide)

La solution envisageable a été appliquée par Robin: Création de catalogue distincts

En effet un traitement statistique sur l'ensemble des tables de couleurs de l'ensemble des scan25 permettrait sans doute de dégager un certain nombre de table de couleurs génériques permettant une dégradation a minima des scan25 appartenant à la classe définie par une table donnée.

Une autre solution et le découpage des scan25 en entité plus petites , puis conversion de ces "mini"-dalles en 24 bits.

Mais vu le travail à accomplir, il serait peut-être judicieux que les concepteurs de la fonction "catalogue" modifient leur code, et enregistre chaque image dans la BD avec sa table de couleur spécifique. Ou qu'ils précisent que l'intégration dans le catalogue n'est garantie que pour les images en 24 ou 32 bits.

A+

Christophe

Dernière modification par DIANA2D.dev (Sat 11 August 2007 19:35)