Оставлю здесь такое наблюдение. Может кому-то пригодиться, кто нагуглит по коду ошибки.
После экспорта результатов из STU, по методу разделяемых сканов попытался обработать изображения в DjVu Imager 2.9 и получил ошибку: "Ошибка на файле 1.tiff. Поддерживаются только цветные 24-битные и серые 8-битные изображения".
Я уж было решил, что это та же ошибка, что недавно обсуждалась в соседней ветке, но это не она.
Насколько я понял, DjVu Imager идет с кодеком fi_c44.exe (Image compression utility using IW44 wavelets), который описан
здесь. Там же автор сообщает, что:
Цитата:fi_c44 принимает на входе только цветные 24-битные или серые 8-битные изображения (именно такие и подразумевает DjVuPhoto - остальные бессмысленно пытаться закодировать).
Взглянул на 1.tiff - он действительно оказался 32-х битным. Утилита tiffinfo выдала мне
Цитата:Resolution: 600, 600 pixels/inch
Bits/Sample: 8
Photometric Interpretation: RGB color
Samples/Pixel: 4
При том, что все остальные tiff файлы имели "Samples/Pixel: 3" и были, соответственно, 8*3 = 24-х битными.
Я их получал из сканов, сохраненных в png. Проверил png при помощи утилиты mediainfo, и тот, что отвечал за 1.tiff действительно оказался:
Цитата:Bit depth : 32 bits
А остальные - 24-бит.
Естественно, 1.png - оказался обложкой
. Обложку я сканировал дважды, т.к. у меня не умещался корешок: обложку с частью корешка и корешок с частью обложки. И оба скана были 24-х битными. После чего из 2-х сканов я собирал полный скан обложки с корешком. Делал это в редакторе GIMP, и в этот момент, каким-то образом, он мне включил "прозрачность", т.е. добавил к RGB еще один 4-й альфа-канал, что и дало 8 бит к 24-м уже имевшимся. Прозрачности там, конечно, никакой не было, а канал для нее - был. Я снова открыл png файл в GIMP,
отключил прозрачность в слоях, сохранил его, перегенерировал соответствующий ему tiff - он стал 24-х битным, и DJVU Imager его без проблем обработал.
И вот я думаю, надо ли тут что-либо исправлять...
С одной стороны ST бережно сохранил информацию об альфа-канале исходного png, и протащил ее не только в output, но и через export to.. В целом, это правильно: может я не djvu, а pdf какой-нибудь из этих результатов делать собираюсь. Отрубать его принудительно, будет не комильфо. Может подумать об опциональной настройке для output или только export to..
С другой стороны, пользователь должен бы сам знать, чего он тащит в программу и сколько в этом бит. Но сам же я и обжегся на этом. У всех давно hdd по терабайту и никто не следит за настройками сохранения. Возможно, стоит добавить warning при export to.. для пользователя, что через него проходит 32, а не 24 или 8 бит. Но warning без объяснения, как решить проблему - только выбесит.
К тому же, я пользовался только DJVU Imager (он лет 8 не обновляется), возможно другие кодеки/инструменты давно умеют работать с 32-х битными tiff (скорее всего, просто игнорируют информацию из альфа-канала на лету с warning'ом и всего делов), тогда мои warning'и будут не в тему, а проблема становится проблемой только DJVU Imager'а. Тот же DJVU Small c documenttodjvum.exe на борту на 32-х битные tiff'ы не ругается.
В общем, пока я не определился, нужно ли вообще тут что-то менять.
Главная
Страниц: 
Модификация ScanTailor (Прочитано 300353 раз)