bolega
Silver Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Arcand
Цитата:| Такой возможности, насколько я знаю, нет ни в DEE ни в Editor. Также |
Понятно.
Тогда непонятно, зачем в BR заниматься вырезанием из сканов иллюстраций и сохранять их отдельно, если все-равно потом нужно подавать на вход DEE комбинированную страницу. Тогда проще не картинки вырезать, а переводить текст в псевдо-b/w. (я называю "псевдо", т.к. реально скан остается цветным, но области с текстом переводятся в два противоположных цвета - 0,0,0 и 255,255,255).
Спасибо за Ваши исследования!
Добавлено:
А вообще-то жалко, что DEE не поддерживает такой фичи.
Можно делать как Вы написали, но здесь есть одна неприятность - чтобы хранить цветные 600dpi файлы, нужно иметь уйму места на винте. Было бы намного экономичнее разделять "слои" сразу же.
sergel
Пока не знаю. Скажу только, что одна страница 600dpi grey или color занимает в несжатом ввиде (а именно так windows работает с битмапами) от 50 до 100 Мб. Кстати именно из-за этого кромсатор долго отображает такие сканы при включенном фильтре, ведь фильтр на каждую точку анализирует 9 соседних, т.е. умножьте объем еще на 10.
Нагрузка на кэш процессора колоссальная.
Метод Convert->HighDark, в отличие от остальных, не является пороговым. Он адаптивный, порог высчитывает автоматически исходя из энтропии изображения. Поэтому он жрет еще кое-какую память. Если как Вы говорите, память не высвобождается, значит буду разбираться.
|
, а он, нехороший, всегда сохраняет файлы tif в разрешении 120 дпи без сжатия. 
