Le portail francophone de la géomatique

Bonjour à tous

A priori c'est simple car Mapinfo géoréférence les images via un point TAB ou la taille du pixel n'est pas directement enregistrée. Malheureusement jusqu'en version 8.0 inclus il affiche un pixel comme un carré quelque soit sa taille "terrain" donc dans votre cas l'image aura toujours la forme d'un rectangle. Il faut voir avec la version 8.5 et son nouveau mode de gestion des rasters.

Donc à moins de rééchentilloner votre raster vous êtes marron ou de tester avec la V8.5.

JP LARTIGAU

Merci mais...
- pas question de rééchantilloner (c'est à MI de faire du boulot correct, tous les autres y arrivent)
- j'ai testé avec MI85: c'est pareil sauf si on demande, dans les préférences->traitement images, la reprojection sur le vecteur (c'est LA nouveauté de MI85)....mais quand on n'a pas de vecteur du coin ??? on est marron ...ou vert (de rage) comme c'est plutôt mon cas en attendant que MI donne enfin le droit aux pixels d'être rectangulaires

Le carré n'est qu'un cas particulier de rectangle et il peut exister des pixels rectangulaires (images satellite par exemple, mais pas seulement)
La forme de l'image, dans l'espace cartographique, n'est pas seulement donnée par le nombre de lignes et de colonnes mais aussi par la "taille terrain" de ces pixels qui peut donc être inégale en X et Y
C'est dans "l'espace image" que cette forme ne dépend que des lignes et colonnes

Salut Maurice,

rééchantillone l'image avec imagemagick (c'est du libre et ça existe
sous Windows)... et passe la ensuite en ecw si tu veux qu'elle tienne
moins de place.

C'est à mon avis la solution la simple, quoiqu'un tantinet (ou parce que
?) "force brute" :-)

--
Michel Wurtz
MAP/SG/SM/SDSI/CERIT/DIG
B.P. 12668 - 31326 Castanet-Tolosan Cedex

Je suis toujours intrigué par ce raster aux pixels rectangulaires (j'assure des formation sur l'image).
Maurice pourriez-vous m'envoyer un extrait de votre image pour voir de plus près le pixel.
pour DIANA2D merci pour votre lien mais avez-vous une version française ?

Bonjour,

Pour la version française je crois que c'est pas possible, pour VB6 MD Sutton est le spécialiste (il ne parle pas français), pour la KB Microsoft tout ce qui concerne les images (DIB: Device Independent BItmap: Bitmap independant du périphérique) est en Anglais, pour ma part (DIB en VB6) je n'ai pas trouvé d'homologue francophone.

Comme le dit Maurice c'est la dimension "terrain" des pixels qui est rectangulaire, par contre ce n'est pas  par ce qu'ils sont "carrés" dans l'image. Un pixel est sans dimension et indivisible, c'est la plus petite partie non fractionnable d'une image.

Une image  sous windows:

Il faut différencier le fichier (Tif, JPG, ECW , BMP etc ...)  de l'image en mémoire vive:

Le fichier contient les infos de façon compressée, avant toute utilisation dans un logiciel ces infos sont lues et décompressées pour obtenir un DIB. ce DIB se structure comme suit :

une structure BITMAPINFO:
(copie de la SDK Windows)

typedef struct tagBITMAPINFO { // bmi
    BITMAPINFOHEADER bmiHeader;
    RGBQUAD          bmiColors[1];
} BITMAPINFO;

typedef struct tagBITMAPINFOHEADER{ // bmih
    DWORD  biSize;
    LONG   biWidth;
    LONG   biHeight;
    WORD   biPlanes;
    WORD   biBitCount
    DWORD  biCompression;
    DWORD  biSizeImage;
    LONG   biXPelsPerMeter;
    LONG   biYPelsPerMeter;
    DWORD  biClrUsed;
    DWORD  biClrImportant;
} BITMAPINFOHEADER;

typedef struct tagRGBQUAD { // rgbq
    BYTE    rgbBlue;
    BYTE    rgbGreen;
    BYTE    rgbRed;
    BYTE    rgbReserved;
} RGBQUAD;


Comme vous pouvez le constater , dans la structure BITMAPINFOHEADER les champs:
LONG   biXPelsPerMeter;
LONG   biYPelsPerMeter;

Définissent la géométrie du pixel, s'ils sont de valeur différentes le pixel sera représenté selon un rectangle.
Ceci est assez rare du fait que la provenance des images est le scanner, qui scan de manière uniforme selon l'axe des X et des Y (donc géomètrie du pixel carrée) mais des origines différentes (satellites) peuvent donner des pixel rectangulaire.

Pour le coté "Pixel carré dans l'image" (sic Maurice) pour une ligne de balayage de l'image (Y= Cte) chaque pixel est représenté sur 1bit, 4 bits, 1 octet, 3 octets ou 4 octets (ceci n'a rien de "carré"), ce en fonction de la valeur du champ:
WORD   biBitCount, il s'agit de la "profondeur de couleur" (BitDepth en Anglais, j'ai pas de meilleur traduction) qui traduit la forme et la valeur du codage de la couleur du pixel
bibitcount = 1 Image bichrome un pixel = 1 bit (0 noir , 1 blanc par exemple)
bibitcount = 4 : image 16 couleur chaque pixel est codé sur 4 bits
bibitcount = 8 : image 256 couleur chaque pixel st codé sur 1 octet (0 à 255) la valeur fournit l'entrée du tableau RGBQuad.
bibitcount = 24 : Image true color chaque pixel est codé sur 3 octet chaque octet contenant la valeur du Bleu, du Vert et du Rouge (attention inversion par rapport au RGB classique)
bibitcount = 32 : inderm précédent avec un Alpha channel (octet1) qui défini la valeur de la couleur qui sera transparente.

Tout ceci bien sur pour un biplanes (nombre de plan de couleur) qui vaut 1, après on passe à des situations qui sont difficilement descriptibles dans un simple post

A+

Christophe

Je ne sais pas comment travail MI , mais étant en cours de choix d'un noyau SIG pour l'interco où je suis élu, ce genre de conversation ne m'encourage pas à le privilégier.

Concernant la grille virtuelle, je ne pense pas que cela vient de là , le pb vient amha du parti pris des developpeurs qui ont considéré qu'un pixel était toujours carré. Ce genre de chose est malheureusement courante, l'appli PCI-Image developpée par APIC pour la DGI considère elle aussi que les pixels sont carrés de nature et qui plus est que la valeur est toujours 300 dpi.
Ce qui est absurde. Au regard des explications données dans mon précédent post, on constatera qu'il ne faut jamais exprimer la densité d'une image en dpi (pixel par pouce) mais bien en pixel par mètre, ce qui permet une plus grande précision.

300 dpi = 11 811 pixel par mètre
Si votre scanner est mal étalonné (ou autre) il sera difficile d'exprimer en dpi, 11 809 pixel par mètre! (les valeurs utilisées étant toujours entières, un pixel est non divisible).

Ceci a son importance quand on tente de géoreférencer une image qui fait 11000 * 9000 pixels!

A+

Christophe

Bien vu, c'est effectivement une astuce pour forcer une "reprojection" (que MI85 réalise ma fois fort bien) et utiliser le raster....par exemple pour numériser de l'information

Bonjour,

La notion de "dpi" ou même de pixel par mètre, est à mon avis totalement
étrangère à tout géoréférencement -- ou du moins devrait l'être.  Elle
est utile pour indiquer la résolution d'un scanner ou d'une table à
numériser (encore que dans ce dernier cas, on préfère la donner en
fraction de mm).  Les outils de CAO l'aiment bien, car l'usage en est
naturel pour l'impression.

Par contre, ce qui compte pour le géoréférencement, c'est la relation
entre coordonnées terrain et coordonnées images, ce qui revient à donner
une taille en m terrain à chaque pixel.  Bien évidement, les meilleurs
résultats sont obtenus lorsque les pixels sont carrés et l'image
orientée dans le sens des axes de la projection utilisée.

Maintenant si j'ai, comme par exemple dans le cas du srtm, des pixels
basés sur des coordonnées géographiques (taille en minutes ou secondes
d'arc), non seulement la taille en X et en Y ne sera pas la même en cas
de projection, mais mes pixels ne seront même pas rectangulaires...

Dans ces cas, le mieux est quand même de recalculer l'image (Grass le
fait très bien par exemple), ou si, on reprojete à la volée, d'avoir une
machine bien puissante, puisque cela revient à recalculer l'image
affichée à chaque rafraîchissement d'écran...

Quant à se priver de MapInfo pour cela... je ne pense pas que ce soit un
critère discriminant.  La simplicité de certains des algorithmes
utilisés par MI a aussi quelques avantages, dont la vitesse de
traitement sur de gros volumes de données, si on le compare avec des
logiciels SIG similaires.

--
Michel Wurtz
MAP/SG/SM/SDSI/CERIT/DIG
B.P. 12668 - 31326 Castanet-Tolosan Cedex

Bonjour,

Je suis tout à fait en accord avec vous et c'est un abus de langage (ou la fatigue de fin d'année) qui m'a fait parler de géoref.
Ce que je voulais signifier c'est qu'au niveau de l'appli PCI-Image la correspondance entre pixel et espace métrique est erronée du fait de considérer une valeur fixe des dpi pour établir la géomètrie de l'image, et de ne pas utiliser les valeur Xpixel et Ypixel contenue dans le Header du fichier tif.
j'ajouterai que le géoref est justement la technique qui consiste à donner la dimension du pixel (et l'ancrage de l'image).

Pour ce qui est du recalcul de l'image en fonction de la projection, je ne peux être qu'en accord, mon propre produit le réalisant (pas à la volée car effectivement il faut une sacré puissance de calcul pour effectuer une rotation ou autre opération sur les pixels sur du noir et blanc particulièrement), il vaut mieux créer le fichier une fois et ensuite l'utiliser à la volée.

Merci Maurice.
J'avais pas compris que c'était Table au sens base de données. En fait pour moi ce sont des objets, la table, étant le conteneur physique (la base de donnée) . Effectivement un raster est forcement un objet et s'il est utilisé dans un SIG, c'est obligatoirement un objet géolocalisé, donc une Table en langage MapInfo si j'ai bien compris ? (dans ce cas je suis d'accord avec GRIGBAB)

Bonnes fête à tous

Pace E Salute

Christophe

Bonjour,

heu ... dans ce cas c'est de la PAO pas du SIG ... rendez vous au bar pour la nouvelle année!

Christophe

slut des géographes de Fès, et bonnes fêtes