lecture de TIFF en niveaux de gris 16 bits

Question

J'essaie de lire un fichier TIFF en niveaux de gris 16 bits (BitsPerSample = 16) à l'aide d'un petit programme en C pour le convertir en tableau de nombres à virgule flottante aux fins d'analyse. Les données de pixels sont, selon les informations d'en-tête, dans une seule bande de 2048x2048 pixels. L'encodage est little-endian.
Avec ces informations d'en-tête, je m'attendais à pouvoir lire un seul bloc de 2048x2048x2 octets et à l'interpréter en tant qu'entiers de 2 048 octets 2048x2048. Ce que j’obtiens, c’est une image divisée en quatre quadrants sur 1024x1024 pixels chacun, dont les deux inférieurs ne contiennent que des zéros. Chacun des deux quadrants supérieurs ressemble à ce que je pensais être la suivante: alt text http://users.aber.ac.uk/ruw/unlinked/15_inRT_0p457.png
Si je lis le même fichier dans Gimp ou Imagemagick, dites-le-moi qu'ils doivent réduire à 8 bits (ce qui ne m'aide pas - j'ai besoin de toute la plage), mais les pixels apparaissent aux bons endroits: texte alt http://users.aber.ac.uk/ruw/unlinked/15_inRT_0p457_gimp.png Cela suggérerait que mon idée sur la façon dont les données sont organisées dans une bande est fausse. D'autre part, le fichier doit être correctement formaté avec les informations d'en-tête, sinon Gimp ne l'obtiendrait pas correctement. Où vais-je mal?

Sortie de tiffdump:
15_inRT_0p457.tiff:
Magic: 0x4949 Version: 0x2a
Répertoire 0: décalage 8 (0x8) suivant 0 (0)
ImageWidth (256) LONG (4) 1 & Lt; 2048 & Gt;
ImageLength (257) LONG (4) 1 & Lt; 2048 & Gt;
BitsPerSample (258) SHORT (3) 1 & Lt; 16 & Gt;
Compression (259) SHORT (3) 1 & Lt; 1 & Gt;
Photométrique (262) SHORT (3) 1 & Lt; 1 & Gt;
StripOffsets (273) LONGS (4) 1 & Lt; 4096 & Gt;
Orientation (274) COURT (3) 1 & Lt; 1 & Gt;
RowsPerStrip (278) LONG (4) 1 & Lt; 2048 & Gt;
StripByteCounts (279) LONG (4) 1 & Lt; 8388608 & Gt;
XResolution (282) RATIONAL (5) 1 & Lt; 126,582 & Gt;
YResolution (283) RATIONAL (5) 1 & Lt; 126,582 & Gt;
ResolutionUnit (296) SHORT (3) 1 & Lt; 3 & Gt;
34710 (0x8796) LONGUE (4) 1 & Lt; 0 & Gt;
(La balise 34710 est une information d’appareil photo; pour que cela ne change rien, j’ai mis à zéro toute la plage allant de la fin du répertoire du fichier image au début des données à 0x1000, et cela ne fait en fait pas toute différence.)

Answer 1

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

J'avais alloué de la mémoire à un tableau de long 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 comme les données sont présentées sous forme de morceaux de 2 octets (BPP = 2) mais que sizeof (long) = 4, fread () les regroupe de manière dense dans la mémoire allouée plutôt que de les compresser en paquets de grande taille. Je me retrouve donc avec deux rangées dans une et la seconde moitié de l'image vide.

Je l'ai modifié pour qu'il parcourt le nombre de pixels, lit deux octets à chaque fois et les stocke dans la mémoire allouée:

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, il s'agit d'un décalage par rapport à un tableau de décalages, n'est-ce pas? Vous ne faites peut-être pas cette déréférence correctement.

Quelle est votre plate-forme? Qu'essayez-vous de faire? Si vous souhaitez travailler sous .NET sous Windows, ma société vend un kit de traitement d'images. qui inclut un codec TIFF qui fonctionne sur pratiquement tout ce que vous pouvez lui lancer et renverra des images 16 bpp. Nous disposons également de nombreux outils fonctionnant en mode natif sur des images 16 bits par seconde.