lettura TIFF in scala di grigi a 16 bit

Question

Sto cercando di leggere un file TIFF in scala di grigi a 16 bit (BitsPerSample = 16) usando un piccolo programma C per convertire in una matrice di numeri in virgola mobile per ulteriori analisi. I dati pixel sono, secondo le informazioni dell'intestazione, in una singola striscia di 2048x2048 pixel. La codifica è little-endian.
Con quelle informazioni di intestazione, mi aspettavo di poter leggere un singolo blocco di 2048x2048x2 byte e interpretarlo come numeri interi a 2 byte 2048x2048. Ciò che effettivamente ottengo è un'immagine divisa in quattro quadranti di 1024x1024 pixel ciascuno, i due inferiori dei quali contengono solo zeri. Ognuno dei primi due quadranti sembra che mi aspettassi che l'intera immagine apparisse: alt text http://users.aber.ac.uk/ruw/unlinked/15_inRT_0p457.png
Se leggessi stesso file in Gimp o Imagemagick, dimmelo entrambi che devono ridurre a 8 bit (il che non mi aiuta - ho bisogno dell'intera gamma), ma i pixel si sollevano nei posti giusti: testo alternativo http://users.aber.ac.uk/ruw/unlinked/15_inRT_0p457_gimp.png Ciò suggerirebbe che la mia idea su come sono disposti i dati all'interno di una striscia è errata. D'altra parte, il file deve essere formattato correttamente in termini di informazioni dell'intestazione, altrimenti Gimp non lo farebbe correttamente. Dove sto sbagliando?

Uscita da tiffdump:
15_inRT_0p457.tiff:
Magia: 0x4949 Versione: 0x2a
Directory 0: offset 8 (0x8) successivo 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;
Compressione (259) SHORT (3) 1 & Lt; 1 & Gt;
Fotometrico (262) CORTO (3) 1 & Lt; 1 & Gt;
StripOffsets (273) LONG (4) 1 & Lt; 4096 & Gt;
Orientamento (274) CORTO (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) LONG (4) 1 & Lt; 0 & Gt;
(Il tag 34710 è informazioni sulla fotocamera; per assicurarsi che ciò non faccia in qualche modo alcuna differenza, ho azzerato l'intero intervallo dalla fine della directory del file di immagini all'inizio dei dati a 0x1000 e che in realtà non fa qualsiasi differenza.)

Answer 1

Ho riscontrato il problema: era nel mio programma C ...

Avevo allocato memoria per un array di long e usato fread () per leggere nei dati:

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

Ma poiché i dati arrivano in blocchi di 2 byte (BPP = 2) ma sizeof (long) = 4, fread () racchiude densamente i dati all'interno della memoria allocata anziché impacchettarli in pacchi di grandi dimensioni. Così finisco con due file raggruppate insieme in una e la seconda metà dell'immagine vuota.

L'ho modificato per scorrere il numero di pixel e leggere due byte ogni volta e archiviarli invece nella memoria allocata:

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

Answer 2

Capisci che se StripOffsets è un array, è un offset rispetto ad un array di offset, giusto? Potresti non fare questa dereferenza correttamente.

Qual è la tua piattaforma? Cosa stai cercando di fare? Se sei disposto a lavorare in .NET su Windows, la mia azienda vende un toolkit di elaborazione delle immagini che include un codec TIFF che funziona praticamente su tutto ciò che puoi lanciare e restituirà 16 immagini bpp. Abbiamo anche molti strumenti che funzionano nativamente su immagini a 16 bpp.