Lesen 16-Bit-Graustufen-TIFF

Question

Ich versuche, eine 16-Bit-Graustufen-TIFF-Datei (BitsPerSample = 16) mit einem kleinen C-Programm zum Lesen in ein Array von Gleitkommazahlen für die weitere Analyse zu konvertieren. Die Pixeldaten sind, gemäß der Header-Information in einem einzelnen Streifen von 2048x2048 Pixeln. Encoding ist Little-Endian.
Mit dieser Header-Informationen, erwartete ich in der Lage sein einen einzelnen Block von 2048x2048x2 Bytes zu lesen und interpretieren es als 2048x2048 2-Byte-Zahlen. Was ich in der Tat get ist ein Bild in vier Quadranten aufgeteilt von 1024x1024 Pixeln, die jeweils enthalten die unteren zwei, von denen nur Nullen. Jede der beiden oberen Quadranten schauen, wie ich das ganze Bild zu erwarten aussehen: alt text http://users.aber.ac.uk/ruw/unlinked/15_inRT_0p457.png
Wenn ich die gleiche Datei in Gimp oder ImageMagick lesen, sagen beide mir dass sie in 8-Bit zu reduzieren (was mir nicht helfen - ich das gesamte Spektrum muß), aber die Pixel drehen an den richtigen Stellen auf: alt text http://users.aber.ac.uk/ruw/unlinked/15_inRT_0p457_gimp.png Dies würde darauf hindeuten, dass meine Vorstellung davon, wie die Daten innerhalb des einen Streifen angeordnet sind, ist falsch. Auf der anderen Seite muss die Datei korrekt in Bezug auf den Header-Informationen formatiert werden, da sonst Gimp wäre es nicht richtig machen. Wo soll ich denn falsch?

Die Ausgabe von tiffdump:
15_inRT_0p457.tiff:
Magic: 0x4949 Version: 0x2a
Verzeichnis 0: Offset-8 (0x8) next 0 (0)
Width (256) Lang (4) 1 <2048>
ImageLength (257) Lang (4) 1 <2048>
BitsPerSample (258) SHORT (3) 1 <16>
Compression (259) SHORT (3) 1 <1>
Photometrische (262) SHORT (3) 1 <1>
Stripoffsets (273) Lang (4) 1 <4096>
Orientierung (274) SHORT (3) 1 <1>
RowsPerStrip (278) Lang (4) 1 <2048>
Stripbytecounts (279) Lang (4) 1 <8388608>
XResolution (282) RATIONAL (5) 1 <126,582>
YResolution (283) RATIONAL (5) 1 <126,582>
Resolution (296) SHORT (3) 1 <3>
34710 (0x8796) Lang (4) 1 <0>
(Tag 34710 Kamerainformationen sind; um sicherzustellen, dass dies irgendwie keinen Unterschied machen, habe ich den ganzen Bereich vom Ende des Bilddateiverzeichnisses zu Beginn der Daten bei 0x1000 auf Null gesetzt, und dass in der Tat nicht machen ein Unterschied.)

Answer 1

Ich habe das Problem gefunden - es ist in meinem C-Programm ist ...

I-Speicher für ein Array von Long-Positionen zugewiesen hatte und verwendet fread () in den Daten zu lesen:

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

Da aber die Daten kommen in 2-Byte-Chunks (BPP = 2), aber sizeof (long) = 4, fread () packt die Daten dicht im Innern des zugewiesenen Speicher, anstatt sich in lange großen Pakete zu packen. So habe ich am Ende mit zwei Reihen zusammengepackt in eine und der zweiten Hälfte des Bildes leer aus.

Ich habe es in einer Schleife über die Anzahl der Pixel geändert und zwei Bytes jedes Mal lesen und speichern sie in den zugewiesenen Speicher statt:

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

Answer 2

Sie verstehen, dass, wenn Stripoffsets ein Array ist, ist es ein zu einem Array von Offsets versetzt ist, nicht wahr? Sie werden vielleicht nicht, dass dereferenzieren richtig tun.

Was ist Ihre Plattform? Was versuchst du zu machen? Wenn Sie bereit sind, auf Windows in .NET zu arbeiten, meine Firma verkauft ein Bildverarbeitungs Toolkit , die eine TIFF-Codec enthält, die so ziemlich alles funktioniert auf Sie an ihm werfen können und werden 16 bpp Bilder zurück. Wir haben auch viele Werkzeuge, die nativ auf 16 bpp Bildern arbeiten.