Pregunta

Estoy tratando de leer un archivo TIFF en escala de grises de 16 bits (BitsPerSample = 16) usando un pequeño programa en C para convertirlo en una matriz de números de coma flotante para un análisis posterior. Los datos de píxeles están, de acuerdo con la información del encabezado, en una sola tira de 2048x2048 píxeles. La codificación es little-endian.
Con esa información de encabezado, esperaba poder leer un solo bloque de 2048x2048x2 bytes e interpretarlo como números enteros de 20 bytes 2048x2048. Lo que de hecho obtengo es una imagen dividido en cuatro cuadrantes de 1024x1024 píxeles cada uno, los dos inferiores contienen solo ceros. Cada uno de los dos cuadrantes superiores se parece a lo que esperaba que se viera la imagen completa: texto alternativo http://users.aber.ac.uk/ruw/unlinked/15_inRT_0p457.png
Si leo el mismo archivo en Gimp o Imagemagick, ambos me avisan que tienen que reducir a 8 bits (lo que no me ayuda, necesito el rango completo), pero los píxeles aparecen en los lugares correctos: texto alternativo http://users.aber.ac.uk/ruw/unlinked/15_inRT_0p457_gimp.png Esto sugeriría que mi idea sobre cómo se organizan los datos dentro de una tira es incorrecta. Por otro lado, el archivo debe estar formateado correctamente en términos de la información del encabezado, ya que de lo contrario Gimp no lo entendería correctamente. ¿Dónde me estoy equivocando?

Salida de tiffdump:
15_inRT_0p457.tiff:
Magia: 0x4949 Versión: 0x2a
Directorio 0: desplazamiento 8 (0x8) siguiente 0 (0)
Ancho de imagen (256) LARGO (4) 1 & Lt; 2048 & Gt;
Longitud de imagen (257) LARGO (4) 1 & Lt; 2048 & Gt;
BitsPerSample (258) CORTO (3) 1 & Lt; 16 & Gt;
Compresión (259) CORTA (3) 1 & Lt; 1 & Gt;
Fotométrico (262) CORTO (3) 1 & Lt; 1 & Gt;
StripOffsets (273) LARGO (4) 1 & Lt; 4096 & Gt;
Orientación (274) CORTA (3) 1 & Lt; 1 & Gt;
RowsPerStrip (278) LARGO (4) 1 & Lt; 2048 & Gt;
StripByteCounts (279) LARGO (4) 1 & Lt; 8388608 & Gt;
XResolution (282) RATIONAL (5) 1 & Lt; 126.582 & Gt;
YResolución (283) RACIONAL (5) 1 & Lt; 126.582 & Gt;
Resolución Unidad (296) CORTO (3) 1 & Lt; 3 & Gt;
34710 (0x8796) LARGO (4) 1 & Lt; 0 & Gt;
(La etiqueta 34710 es información de la cámara; para asegurarme de que esto no haga alguna diferencia, he puesto a cero todo el rango desde el final del directorio del archivo de imagen hasta el inicio de los datos en 0x1000, y eso de hecho no hace cualquier diferencia.)

¿Fue útil?

Solución

He encontrado el problema: estaba en mi programa C ...

Había asignado memoria para un conjunto de longs y usé fread () para leer los datos:

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

Pero dado que los datos vienen en fragmentos de 2 bytes (BPP = 2) pero sizeof (long) = 4, fread () empaqueta los datos densamente dentro de la memoria asignada en lugar de empaquetarlos en paquetes de gran tamaño. Por lo tanto, termino con dos filas juntas en una y la segunda mitad de la imagen vacía.

Lo cambié para recorrer la cantidad de píxeles y leer dos bytes cada vez y almacenarlos en la memoria asignada:

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

Otros consejos

Entiende que si StripOffsets es una matriz, es un desplazamiento de una matriz de compensaciones, ¿verdad? Es posible que no esté haciendo esa desreferencia correctamente.

¿Cuál es tu plataforma? ¿Que estás tratando de hacer? Si está dispuesto a trabajar en .NET en Windows, mi empresa vende un kit de herramientas de procesamiento de imágenes que incluye un códec TIFF que funciona en casi cualquier cosa que pueda arrojarle y devolverá 16 imágenes bpp. También tenemos muchas herramientas que funcionan de forma nativa en imágenes de 16 bpp.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top