J'aimerais utiliser Libtiff pour accéder à de très grands fichiers TIFF. J'ai besoin de fonctions comme plusieurs pages et tuiles, et donc libtiff semble être la bonne façon d'aller. Quelqu'un peut-il m'aider sur la façon d'utiliser libtiff de C #? J'ai trouvé des liens (comme blog.bee-ee qui contenait du code partiel. Mais je ne vais pas aller au-delà d'avoir une version. J'ai regardé FreeImage mais trouvé qu'il ne convient pas (les images sont env. 800 MPIXEL 8 ou 16 bits Niveaux de gris -> 800-1600 mbyte) Taille et je ne peux pas le charger en mémoire dans un 32- environnement de bits)
Je suis très expérimenté en C / C ++, mais pas encore en C #. Quelqu'un peut-il m'aider à un wrapper ou à des indices?
Remarque: j'ai besoin de pages pour accéder aux plans pyramidiques (multi-résolution) dans un tiff et des carreaux de 256x256 pour avoir un accès rapide à différentes parties de l'image sans le charger à la fois.
[modifier] le La solution libtisf.net semblait la plus pratique pour moi. Je l'intégrais maintenant dans un développement de produits et je vais me sauver beaucoup de maux de tête d'aller dans / sortant de la mémoire gérée. Je n'ai pas encore essayé la fonctionnalité de «rappel», qui semble être résolue bien dans une manière .Net. Merci pour l'aide sur Stackoverflow [/ EDIT]
3 Réponses :
WIC fournit une prise en charge des très grands fichiers d'image. Il y a une belle enveloppe pour elle dans le .NET Framework: TiffbitmapDecoder.
Pouvez-vous ajouter des liens? De ce que j'ai vu, TiffbitmapDecoder essaie de charger une image en mémoire à la fois. Je ne peux pas faire ça. Photos> 1 Gbyte échouera toujours sur une machine 32 bits en raison de la fragmentation. Vous référez-vous aux spécificités Windows7 ( MSDN.MicRosoft. COM / EN-US / Bibliothèque / EE720061% 28V.85% 29.aspx )?
Non, TBD ne stocke pas une image. Commencez ici: msdn.microsoft.com/en-us/library/ms748873.aspx
Merci de votre aide. Malheureusement, mon expérience est différente. Les étapes décrites dans msdn.microsoft.com/en-us/library/ms748873. ASPX Essayez d'allouer un seul bloc de mémoire avec la taille de la trame 1 du bitmap.i Vous avez besoin d'un accès à chaque pixel dans le bitmap (donc aucune option d'enregistrement de mémoire à l'écran), tout simplement pas nécessairement dans un seul morceau de mémoire. Lorsque j'essaie d'exécuter le décodeur TIFF comme indiqué dans l'exemple, cela échoue généralement sur des bitmaps> 10k * 10k. Et ce ne sont que mes «petits fichiers de test». Ma cible est 800mpixel x 16 bits. C'est pourquoi je cherche des fichiers TIFF carrelés.
Hmya, vous ne pouvez pas obtenir une image de 400 Mo chargée sur un système d'exploitation 32 bits. Basculez vers un système d'exploitation 64 bits ou lisez l'image dans des portions.
Oui. C'est pourquoi je cherchais dans des tuiles. Le passage à un système d'exploitation 64 bits résoudrait une partie des problèmes, mais obtiendrait toujours de grandes latences pour lire l'ensemble du fichier avant de faire un traitement. Les disque dur sont plus lents que ceux de la CPU de nos jours. De plus, j'aime les possibilités de fichiers TIFF pyramid (c'est-à-dire avoir des images à faible résolution prête dans le même fichier pour les aperçus, etc.)
Est-il possible de lire une grosse image TIFF autour de 3 Mo, qui est une image TIFF en carrelage à l'aide de TIFFBITBBITMAPDecoder et de convertir en PDF? sans une bibliothèque tierce? Je suis autorisé à utiliser itextShaRP pour créer un PDF, mais aucune autre bibliothèque tierce, comme Lib2tiff, etc.
Ma solution initiale consistait à utiliser un wrapper C # .NET pour la DLL libtiff. Je l'ai trouvé sur libtiff ftp . Il semble contenir toutes les méthodes importantes de la bibliothèque de Libtiff. Il garde la mémoire dans la mémoire libtiff non gérée; Cela signifie que le code C # doit être conscient de cela et de copier des données lorsqu'il doit être traité dans un code sécurisé.
mon "code de lecture de tuiles" pour le tester comme p>
if (LibTIFF.IsTiled(tiff))
{
if (LibTIFF.GetField(tiff, (int)TIFFTags.TIFFTAG_TILEWIDTH, out tileWidth) &&
LibTIFF.GetField(tiff, (int)TIFFTags.TIFFTAG_TILELENGTH, out tileLength))
{
uint tiles = 0;
IntPtr pTile = LibTIFF._malloc((int)(tileLength*tileWidth*bitsPerSample/2));
for (uint y = 0; y < imageLength; y += tileLength)
{
for (uint x = 0; x < imageWidth; x += tileWidth)
{
LibTIFF.ReadTile(tiff, pTile, x, y, 0, 0);
tiles++;
}
}
LibTIFF._free(pTile);
}
}
Est libtiff est le seul moyen de traiter TIFF carrelé? Ou pouvons-nous faire la même chose avec la classe TIffbitmapDecoder dans le cadre .NET?
D'après ce que je peux voir, le TiffbitmapDecoder ne fournit pas de fonctionnalité pour charger sélectivement des parties du fichier (uniquement pour le rendu des cadres complets). MSDN.MicRosoft .com / fr-nous / bibliothèque / ...
Vous pouvez essayer notre libtiff.net. C'est une version gratuite et open source de Libtiff écrit à l'aide de C # gérée. API de notre mise en œuvre a été très similaire à celle d'origine.
https://bitmiracle.com/libtiff/
Nous venons de la publier, alors il peut y avoir des bugs. Mais le code source complet est livré avec un certain nombre de tests, de sorte que la plupart des bugs évidents doivent être corrigés.
Merci. Mes premiers tests sont beaux. Bien que j'ai trouvé une classe d'emballage, il n'a pas eu d'auteur connu et que je ferais tôt que des problèmes avec l'accès aux ressources de mémoire gérées / non gérées. Les repères ont montré des performances équivalentes sur la lecture de fichiers non compressés et une performance de 50% sur les tiffs carrelés pyramidaux compressés par Adobe. Ceci est acceptable pour moi. Je peux décider de ne pas utiliser la compression et je ferai mieux de faire mon logiciel multi-noyau convivial que de résoudre des problèmes de mémoire.
Merci, Adriaan Notre mise en œuvre est définitivement plus lente que le langage original dû du choix :-)
Cela ne me dérange pas. Pour mes performances de projet, signifie fonctionnalité / euro. Et les heures de développement sont de 95% du coût. Je peux facilement jeter dans un quadcore pour compenser cela. En outre, lorsque je reste à l'écart de la compression, la différence est petite. Et mes fichiers ne compressent que 10% environ 10%, ce n'est donc qu'un module de 100 mbyle par fichier ;-)