lecture en niveaux de gris 16 bits TIFF

Question

J'essaie de lire un fichier TIFF en niveaux de gris 16 bits (BitsPerSample = 16) en utilisant un petit programme C pour convertir en un tableau de nombres à virgule flottante pour une analyse plus approfondie. Les données de pixel sont, selon les informations d'en-tête, dans une bande unique de 2048x2048 pixels. L'encodage est little-endian.
Avec ces informations d'en-tête, je m'attendais à être capable de lire un seul bloc de 2048x2048x2 octets et de l'interpréter comme des entiers de 2 octets de 2048x2048. Ce que je reçois en fait est une image de 1024x1024 pixels chacun, dont les deux inférieurs ne contiennent que des zéros. Si je lis le same file into Gimp ou Imagemagick, les deux me disent qu'ils doivent réduire à 8 bits (ce qui ne m'aide pas - j'ai besoin de la gamme complète), mais les pixels apparaissent dans les bons endroits: alt text http://users.aber.ac.uk/ruw/unlinked/15_inRT_0p457_gimp.png Cela suggère que mon idée sur la façon dont les données sont rangées dans une seule bande est fausse. D'un autre côté, le fichier doit être correctement formaté en termes d'informations d'en-tête, sinon Gimp ne le comprendrait pas correctement. Où vais-je mal?

sortie de tiffdump:
15_inRT_0p457.tiff:
Magic: 0x4949 Version: 0x2a
Directory 0: offset 8 (0x8) suivante 0 (0)
ImageWidth (256) LONG (4) 1 < 2048 >
imagelength (257) LONG (4) 1 < 2048>
BitsPerSample (258) SHORT (3) 1 < 16>
de compression (259) SHORT (3) 1 < 1>
photométrique (262) SHORT (3) 1 < 1>
stripoffsets (273) LONG (4) 1 < 4096>
orientation (274) SHORT (3) 1 < 1>
rowsperstrip (278) LONG (4) 1 < 2048>
StripByteCounts (279) LONG (4) 1 < 8388608>
XResolution (282) RATIONAL (5) 1 < 126,582>
YResolution (283) RATIONAL (5) 1 < 126,582>
ResolutionUnit (296) SHORT (3) 1 < 3 >
34710 (0x8796) LONG (4) 1 < 0>
(L'étiquette 34710 est l'information de la caméra; pour m'assurer que cela ne fait pas de différence, j'ai mis à zéro toute la gamme de la fin du répertoire du fichier image au début des données à 0x1000, et cela ne fait en fait aucune différence.)

Answer 1

J'ai trouvé le problème - c'était dans mon programme C ...

j'avais alloué la mémoire pour un tableau de positions longues et utilisé fread() pour lire les données:

#define PPR 2048; 
#define BPP 2; 
long *pix; 
pix=malloc(PPR*PPR*sizeof(long)); 
fread(pix,BPP,PPR*PPR,in); 

Mais étant donné que les données sont en morceaux de 2 octets (BPP = 2), mais sizeof (longue) = 4, fread() place les données de manière dense dans la mémoire allouée plutôt que de les empaqueter dans des paquets de grande taille. Ainsi, je me retrouve avec deux rangées réunies en une et la seconde moitié de l'image vide.

Je l'ai changé en boucle sur le nombre de pixels et lu deux octets à chaque fois et de les stocker dans la mémoire allouée à la place:

for (m=0;m<PPR*PPR;m++) { 
    b1=fgetc(in); 
    b2=fgetc(in); 
    *(pix+m)=256*b1+b2; 
} 

Answer 2

Vous comprenez que si StripOffsets est un tableau, c'est un décalage à un tableau de décalages, non? Vous ne faites peut-être pas ce déréférencement correctement.

Quelle est votre plateforme? Qu'essayez-vous de faire? Si vous êtes prêt à travailler dans .NET sur Windows, my company sells an image processing toolkit qui comprend un codec TIFF qui fonctionne sur tout ce que vous pouvez jeter à ce sujet et retournera 16 images bpp. Nous avons également de nombreux outils fonctionnant nativement sur des images 16bpp.