чтение 16-битного оттенка серого TIFF - PullRequest
0 голосов
/ 09 января 2009

Я пытаюсь прочитать 16-битный файл TIFF в оттенках серого (BitsPerSample = 16), используя небольшую программу на C для преобразования в массив чисел с плавающей запятой для дальнейшего анализа. Данные пикселей находятся в соответствии с информацией заголовка в одной полосе размером 2048х2048 пикселей. Кодировка с прямым порядком байтов.
С этой информацией заголовка я ожидал, что смогу прочитать один блок размером 2048x2048x2 байта и интерпретировать его как 2-байтовые целые числа 2048x2048. Что я на самом деле получаю, так это изображение , разделенное на четыре квадранта размером 1024x1024 пикселей каждый, нижние два из которых содержат только нули. Каждый из двух верхних секторов выглядит так, как я ожидал, чтобы выглядела вся картинка: alt text http://users.aber.ac.uk/ruw/unlinked/15_inRT_0p457.png
Если я прочитал один и тот же файл в Gimp или Imagemagick, оба скажут, что их нужно уменьшить до 8 бит (что мне не помогает - мне нужен полный диапазон), но пиксели увеличиваются правильные места: альтернативный текст http://users.aber.ac.uk/ruw/unlinked/15_inRT_0p457_gimp.png Это предполагает, что мое представление о том, как данные расположены в одной полосе, неверно. С другой стороны, файл должен быть правильно отформатирован с точки зрения информации заголовка, так как в противном случае Gimp не сделает это правильно. Куда я иду не так?

Выход из Tiffdump:
15_inRT_0p457.tiff:
Магия: 0x4949 Версия: 0x2a
Директория 0: смещение 8 (0x8) далее 0 (0)
Ширина изображения (256) ДЛИНА (4) 1 <2048>
Длина изображения (257) ДЛИНА (4) 1 <2048>
BitsPerSample (258) SHORT (3) 1 <16>
Сжатие (259) КРАТКОЕ (3) 1 <1>
Фотометрический (262) КОРОТКИЙ (3) 1 <1>
StripOffsets (273) LONG (4) 1 <4096>
Ориентация (274) КРАТКИЕ СВЕДЕНИЯ (3) 1 <1>
RowsPerStrip (278) ДОЛГО (4) 1 <2048>
StripByteCounts (279) ДОЛГО (4) 1 <8388608>
XResolution (282) РАЦИОНАЛЬНОЕ (5) 1 <126.582>
Резолюция (283) Рациональная (5) 1 <126.582>
ResolutionUnit (296) SHORT (3) 1 <3>
34710 (0x8796) ДОЛГО (4) 1 <0>
(Тег 34710 - это информация о камере; чтобы убедиться, что это не имеет никакого значения, я обнулел весь диапазон от конца каталога файлов изображений до начала данных в 0x1000, и это на самом деле не дает любая разница.)

Ответы [ 2 ]

1 голос
/ 09 января 2009

Я нашел проблему - это было в моей программе на C ...

Я выделил память для массива long и использовал fread () для чтения данных:

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

Но поскольку данные поступают в виде 2-байтовых блоков (BPP = 2), а sizeof (long) = 4, fread () плотно упаковывает данные в выделенную память, а не упаковывает их в пакеты большого размера. Таким образом, я получаю два ряда, упакованных в одну, а вторая половина картинки пуста.

Я изменил его, чтобы зациклить количество пикселей, каждый раз читать два байта и вместо этого сохранять их в выделенной памяти:

for (m=0;m<PPR*PPR;m++) {
  b1=fgetc(in);
  b2=fgetc(in);
  *(pix+m)=256*b1+b2;
}
0 голосов
/ 09 января 2009

Вы понимаете, что если StripOffsets является массивом, это смещение к массиву смещений, верно? Возможно, вы неправильно выполняете разыменование.

Какая у тебя платформа? Что ты пытаешься сделать? Если вы готовы работать в .NET под Windows, моя компания продает набор инструментов для обработки изображений , который включает в себя кодек TIFF, который работает практически со всем, что вы можете на него бросить, и возвращает 16 изображений в секунду. У нас также есть много инструментов, которые изначально работают с изображениями 16bpp.

...