Le portail francophone de la géomatique

Bonjour Maurice,

Pour la taille minimale, je pense que c un plus que ça puisque des images de 1.9 Go sont affichables sur imagine sans aucun problème.

Cela dit, pour diviser l'image, les outils disponibles sur imagine, requierent l'affichage de l'image à priori pour définir une aoi ou bien connaitre ses coords. Toutefois, je vais essyaer de le faire en définissant les coords et je vais voir ce que ça donne.

Merci.

Geo Hello Pat !!

Euhhhhhhhhhh oui, y'a t-il un moyen comme même parceque ce matin en essayant de couper l'image, notament avec l'outil subset image de data preparation, il m'inonde de message d'erreurs tjrs avec le pb de la taille du fichier.

Voilà voilou.

Geo merci.

Dernière modification par Rasha (Sat 19 May 2007 17:04)

Bonjour,

Pour info, le projet bigtiff dépasse largement la barrière de 2 go, allant même jusqu'au double!

plus d'infos Sur http://technology.slashgeo.org/technolo … 0244.shtml

Cordialement,
n314

Il y a deux choses :
1) la façon dont Windows (en 32 bits) gère les fichiers, les programmes et l'allocation de mémoire.
2) la spécification du Tiff

Dans ce sujet on a parlé du point 1). Pour le point 2), le standard est assez clair. Disons simplement que comme le format est un conteneur avec de nombreuses possibilités d'extensions, on peut facilement créer des images dont le type n'est pas dans ces fameuses spécifications.

Le bigtiff est loin d'être un standard, c'est bien indiqué dans le site. Il n'y a aucune raison qu'il soit intégré dans les logiciels SIG commerciaux ou non, libre ou propriétaire. Si gdal connait le bigtiff, c'est pour essayer de mettre en avant ce format. On peut remarquer que la version 4.0 en développement de la libtiff intègre le bigtiff. Mais pour l'instant, c'est toujours une version de développement, donc qui n'est utilisable qu'à nos risques et périls.

Bonjour Argus,

En proposant un codage sur 64 bits (TIFF-64) permettant de s'affranchir de la limite des 4 Go (jusqu'à 18000 petaoctets), le format BigTIFF initié par Aware Systems/Apério et approuvé par les gestionnaire des spécifications TIFF (Adobe) est développé en open-source avec le soutien de 4 sponsors majeurs (WeoGeo, Safe, Leica et ESRI).
Côté MapInfo 9.5, je ne sais pas si ce dernier l'a déjà intégré, à la différence des Erdas Imagine 9.3, Global Mapper 10, TNTmips...
L'objectif de l'intégration du BigTIFF dans la librairie LibTIFF 4.0 est de rester très proche de la norme TIFF v.6 pour permettre de faire migrer les applications qui utilisent cette librairie de manière transparente avec du BigTIFF.
Comme LibTIFF est utilisée par la plupart des applications commerciales et libres, il y a de bonnes chances que le format soit rapidement adopté. Le format est naturellement intégré dans GDAL/OGR : quand GDAL créée un fichier geoTIFF sans compression il calcule à l'avance la taille du fichier résultant et choisit automatiquement le format BigTIFF si le fichier dépasse 4 Go.

D'autre part, il est effectivement admis que les images N&B sont plus efficaces en compression sans perte N&B type PNG qu'en JPEG2000.
Mais si dans votre cas, le but final est de créer une image résultant de l'assemblage de 300 dalles N&B de 40 gigapixels chacune soit -sauf erreur 'krasuckienne'- près de 1.5 To non compressée, la question se pose d'avantage en termes de nécessaire compression et de taille de fichier final.
Car même compressé en JPEG2000, ECW ou MrSID formats lus par MapInfo, je doute que ce dernier vu la taille du document veuille bien l'ouvrir...

A voir aussi le format JBIG2, standard non géoréférencé de compression d'images binaires (N&B)

Bien cordialement.

--
Peio Elissalde
Magic Instinct Software

Dernière modification par Peio (Tue 14 April 2009 13:03)

Bonjour Agnés et Argus,

Il và falloir que je change de lunettes : j'avais lu 200000 pixels x200000 pixels et pas 20000x20000... soit environ 14,6 Go en image binaire non compressée (et non 100 fois plus).

Bien cordialement

--
Peio Elissalde
Magic Instinct Software