Ru-Board.club
← Вернуться в раздел «Программы»

» Scan Tailor: Часть 2

Автор: amaid
Дата сообщения: 15.01.2013 07:50
в таком случае там не хватает половины стандартных (хотя считать "стандартом" для djvu разрешения меньше 300 довольно глупо)
djvu 600 dpi малость подтормаживает даже на мощных компах, а 400 dpi выглядит плоховато, особенно если шрифт мелкий.
Автор: alpopo
Дата сообщения: 15.01.2013 09:56
amaid
Цитата:
400 dpi выглядит плоховато, особенно если шрифт мелкий
Если на входе 150 дпи, то на выходе и 600 не поможет. А если на входе 600, то незачем его очень быстро переводить на 500. Зачем делать на выходе больше чем на входе?. Это по моим наблюдениям качества существенно не прибавляет, только сбивает с толку тех, кто этими книжками потом пользуется
Автор: gsn13n
Дата сообщения: 15.01.2013 10:30
monday2000
В Вашей сборке прекрасно работает ручной режим исправления строк, но при установке полезной области и полей возможность растягивать-уменьшать эти области осталась только за угловые точки, что не очень удобно.
Нельзя ли это подправить?
Автор: amaid
Дата сообщения: 15.01.2013 15:22
alpopo, вы ошибаетесь, оверсэмплинг текста в ST или кромсаторе ОЧЕНЬ существенно улучшает качество - как восприятие на глаз, так и OCR
Автор: monday2000
Дата сообщения: 15.01.2013 20:54
gsn13n

Цитата:
Нельзя ли это подправить?

Подправил:

http://rghost.ru/43062070 (4,5 МБ)

Подробности тут: http://www.djvu-scan.ru/forum/index.php?topic=1137.msg5382#msg5382

Добавлено:

Цитата:
приняты как стандартные: 100, 150, 200, 300, 400, 600.

Да, именно так. amaid, посмотрите окно драйвера сканирования любого сканера - там как раз именно эти разрешения и указаны - а 500 - вряд ли где-то найдёте. Поэтому я Вам и сказал, что 500 нужно только Вам одному. А Вы себе соберите свою личную сборку СТ - и там укажите 500.
Автор: kuharsanek
Дата сообщения: 15.01.2013 21:44
amaid

Чем что-то критиковать предложите своё что-то действительно дельное. Или напишите сами.
С Уважением Александр.
Автор: denver 22
Дата сообщения: 16.01.2013 06:26
Нашел тему форума по сборке Scan Tailor Еnhanced. Но с регистрацией на форуме проблемы (письмо с подтверждением не приходит уже сутки). Хотел написать Петру, чтобы он посмотрел новшества от monday2000. Может кому-то удастся там зарегистрироваться. Писать придется на английском.
Может в шапку эту ссылку сохранить, чтобы при необходимости общаться с автором сборки напрямую.
Автор: amaid
Дата сообщения: 16.01.2013 07:12
kuharsanek, разве я что-то критиковал? вам померещилось
программировать не умею, а книжек в ST сделал много и всё меня в этой проге устраивает, разве что пару мелких удобств можно добавить (если не хотят умельцы - ну, ничего страшного, проживу как-нибудь)
monday2000
да понял я, что товарищ имел в виду стандарты драйверов (плохого) сканера, а не djvu, которые он, видимо, делать не умеет; а вам прикидываться деревом не стоит, вы человек умный и наверняка знаете, что в кромсаторе вывод в 500 dpi имеется, никому там не мешает и в ST тоже не помешал бы
Автор: monday2000
Дата сообщения: 16.01.2013 21:30
denver 22

Цитата:
Нашел тему форума по сборке Scan Tailor Еnhanced.

Кстати, я на том форуме давно забанен. ИМХО хозяин того форума - совершенно с пулей в голове.

Цитата:
Хотел написать Петру, чтобы он посмотрел новшества от monday2000.

Имейте в виду, что они пока не оптимальны. Так, разделение субсканов делается просто как ещё одна дополнительная операция - а это неправильно, разделение должно делаться "на лету" - прямо в процессе генерации готового скана. Так что моя реализация замедляет работу СТ - на то время, которое требуется, чтобы в цикле пробежать все пиксели изображения (не так уж и мало, хотя и не очень много). Пока и так сойдёт, но лучше бы это дело прооптимизировать.

Добавлено:
amaid
Ещё раз повторюсь - не надо бояться программировать самому Scan Tailor. Сделайте себе это сами - хотя бы из интереса. Неужели не интересно?
Автор: amaid
Дата сообщения: 16.01.2013 22:12
честно скажу, есть вещи и поинтереснее для меня
доводилось ковыряться в VBA, удовольствия не получал и толку вышло не густо
вот книжки djvu мне делать нравится, перед Иосифом снимаю шляпу
Автор: zhe_zho
Дата сообщения: 17.01.2013 02:59

Цитата:
которые он, видимо, делать не умеет

Дорогой, можно узнать как вы пришли к такому выводу?

Цитата:
а не djvu

А ведь до этого писали

Цитата:
хотя считать "стандартом" для djvu разрешения меньше 300 довольно глупо

Где я сказал что это именно для djvu, а не просто список стандартных разрешений? Да и сам Scan Tailor в djvu не выводит. Где я говорил какие я разрешения использую?

Цитата:
драйверов (плохого) сканера

А вы где-то видели чтобы в списке разрешений сканера не было 100 и 150?
Автор: amaid
Дата сообщения: 17.01.2013 07:34

Цитата:
Дорогой, можно узнать как вы пришли к такому выводу?

перепутал вас с alpopo, виноват, дорогой
хотя для умельца странно путать стандарты драйверов сканера и разрешение вывода в djvu
и ознакомиться с кромсатором вам не вредно, дорогой
http://s7.postimage.org/lxtwjmq3f/0059.png

Цитата:
А вы где-то видели чтобы в списке разрешений сканера не было 100

видел, на своем Epson Perfection v33
http://s7.postimage.org/69ex7m6cb/0058.png
драйверам приличных сканеров убогие стандарты прошлого века не указ

Добавлено:
как видите, расширение списка разрешений никому не мешает (кроме пары блюстителей стандартов с руборда )
Автор: zhe_zho
Дата сообщения: 17.01.2013 16:53

Цитата:
хотя для умельца странно путать стандарты драйверов сканера и разрешение вывода в djvu

Это уже было, от alpopo

Цитата:
Если на входе 150 дпи, то на выходе и 600 не поможет. А если на входе 600, то незачем его очень быстро переводить на 500.

Для сканирования и вывода в djvu достаточно: 300, 400, 600. Желательно без лишних движений, в каком отсканировали в таком и вывели. Повышать глупо, понижать - тратить лишнее время. Для разовых документов можно и 200, но это уже обычно в tif.

Цитата:
ознакомиться с кромсатором

Спасибо, меня эта программа не интересует.

Цитата:
видел, на своем Epson Perfection v33

Зато есть 150. А 50, 72, 96 не делает его убогим? Да и 500 там нет.

Цитата:
кроме пары блюстителей стандартов с руборда

Делайте что хотите. Почему бы вам не воспользоваться кромсатором, раз он выводит в нужное вам расширение.
Я нигде ранее нигде не видел 500, поэтому и написал какие видел в сканерах, так как выбор там больше чем используется для djvu, но даже в этом большем списке нет 500.

Цитата:
это нестандартное разрешение, приняты как стандартные: 100, 150, 200, 300, 400, 600.
Автор: monday2000
Дата сообщения: 17.01.2013 21:46
Я сделал в своей копии СТ прямоугольные зоны иллюстраций. Нажимаете и удерживаете Ctrl, и создаёте прямоугольные зоны, без Ctrl - как обычно.

Ещё, конечно, остаются недоработки - например, уже созданную прямоугольную зону хочется двигать тоже прямоугольно - но это надо отдельно делать.

Вот собранный с этой фичей СТ:

http://rghost.ru/43112547 (4.5 МБ)

Естественно, он включает в себя все мои предыдущие правки.

Коды исправления здесь: http://www.djvu-scan.ru/forum/index.php?topic=1137.msg5385#msg5385
Автор: monday2000
Дата сообщения: 18.01.2013 21:09
Я сделал прямоугольное сдвигание углов зоны иллюстраций. Работает также через зажатый Ctrl. Задумано для прямоугольных зон. Теперь можно будет не слишком точно ставить прямоугольные зоны, а потом на большем масштабе уже их подгонять точно под размер.

Вот собранный СТ:

http://rghost.ru/43134964 (4.5 МБ)

Коды исправления здесь: http://www.djvu-scan.ru/forum/index.php?topic=1137.msg5389#msg5389

Автор: LazyKent
Дата сообщения: 18.01.2013 22:21
monday2000, а выложите, пожалуйста, ваши изменения в виде патча. Для пользователей Linux это будет полезно.
Автор: monday2000
Дата сообщения: 19.01.2013 12:54
LazyKent
Вот: http://rghost.ru/43148395
Автор: LazyKent
Дата сообщения: 19.01.2013 17:15
monday2000, спасибо.

Если не затруднит, попрошу сделать в другом формате. Раз у вас есть diff, то это просто. Команда такая:

Код: diff -Nur original_directory modified_directory > scantailor-monday2000.patch
Автор: F777
Дата сообщения: 20.01.2013 01:06
DikBSD

Цитата:
Пишу запоздало...
Я перестал участвовать в разработке ветки plus по причине того, что полу-ослеп. Глаза уже не те. увы. За компьютер редко сажусь.
Все последние коды - в ветке plus, если найдутся желающие "подхватить" разработку этой ветки и вливать в нее код (Tulon может дать доступ) - будет прекрасно!
Сожалею, если не оправдал чьи-нибудь надежды...

Огромное спасибо Вам за все. Благодаря Вам мир стал чуточку лучше. Держитесь!

monday2000

Цитата:
Я сделал в своей копии СТ прямоугольные зоны иллюстраций. Нажимаете и удерживаете Ctrl, и создаёте прямоугольные зоны, без Ctrl - как обычно.

Спасибо!

Цитата:
Я сделал прямоугольное сдвигание углов зоны иллюстраций. Работает также через зажатый Ctrl. Задумано для прямоугольных зон. Теперь можно будет не слишком точно ставить прямоугольные зоны, а потом на большем масштабе уже их подгонять точно под размер.

Еще раз спасибо. Правда, у меня это корректно работает только в случае использования левого нижнего угла зоны или правого верхнего. В двух других случаях получается полная хрень, напрочь уничтожающая и уродующая исходную зону. Это так задумано или баг? Можно исправить?

И самый главный вопрос. А не могли бы Вы влить все Ваши новшества в Scan Tailor Plus и вообще работать в дальнейшем именно с ним, а не с классическим вариантом?
Автор: monday2000
Дата сообщения: 20.01.2013 11:30
Ответы Tulon на некоторые вопросы

Вопрос 1: Почему бы не сделать выходную нумерацию в виде 0001.tif, 0002.tif, ... 0010.tif, ... - а не так, как сейчас?

Цитата:
Если делать, чтобы без всяких косяков (типа непоявление знаков вопросов на стадии вывода после удаления/вставки/изменения типа разреза), получается очень сложно. Настолько сложно, что у меня даже нет идей, как к этому подступиться. Если с косяками, то можно сделать, как было раньше, а именно: Task::process() и CacheDrivenTask::process() принимают дополнительный аргумент - номер страницы в выходной последовательности. Правда получить этот номер будет не так просто: если раньше порядок обработки страниц всегда был один и тот же - как страницы идут в ProjectPages, то сейчас он соответствует текущему режиму сортировки.

Как все работает сейчас:

Есть класс OutputFileNameGenerator, и в нем функции getFileNameFor(PageId) и getFilePathFor(PageId). То есть имя файла на выводе есть функция от имени (точнее от полного пути) входного файла и типа страницы (полная страница / левая половина / правая половина). Почему от полного пути а не просто от имени файла? Потому что никто не запрещает поместить в проект два файла с одинаковым именем но из разных директорией. Уже десять раз пожалел, что разрешил иметь в проекте файлы из разных директорий, так как пришлось придумывать способ, чтобы разрешать коллизии имен. Способ получился такой: есть класс FileNameDisambiguator к которому имеет доступ
OutputFileNameGenerator, и который имеет функцию "int getLabel(QString const& file_path) const". Если возвращает ноль - значит в проекте нет двух файлов с таким именем. Если больше нуля, то это число в итоге окажется в имени выходного файла, примерно так: 0005(1).tiff, 0005(2).tiff

Естественно при такой схеме, нужно обновлять информацию в FileNameDisambiguator каждый раз, когда в проект добавляется новый файл.

При удалении я кстати ничего не обновляю, то есть может оказаться, что на выводе есть файл 0005(2).tiff, но нету 0005(1).tiff, потому как соответствующий исходный файл был удален из проекта. Кстати, внутреннее состояние FileNameDisambiguator сохраняется в проект.

Так вот, в принципе можно убрать функцию FileNameDisambiguator::getLabel() и сделать вместо нее getOutputPageNumber(), но в этом случае вы запаритесь обновлять его внутреннее состояние, потому что это придется делать не только при добавлении файла в проект, но и при удалении, а также при изменении типа разреза. Еще при любом из этих событий надо бы переименовывать все имеющиеся выходные файлы к своим новым именам.

Гемморой в общем.

Могу впрочем предложить другой подход: создать пункт в меню Инструменты ->Экспортировать вывод. Там указываете директорию для экспорта, а также пару галок: "последовательная нумерация" и "копировать вместо перемещения".

Такой подход реализовать совсем несложно.


Вопрос 2: Вышел Qt 5. Может, стоит его использовать?


Цитата:
Без изменений скриптов сборки он практически гарантированно не соберется. Я слышал там несколько новых зависимостей да и вообще я пессимист

Сейчас мои скрипты сборки делают всякие хитрые манипуляции, чтобы Qt собралась в нужной мне конфигурации, вплоть до того, что патчат .pro/.pri файлы в исходниках Qt. Так что если хотите попробовать собрать Qt5 -
готовтесь засучить рукава и основательно поковырять файл packaging/windows/build_deps/CMakeLists.txt. Как можно заметить, секция Qt там весьма не маленькая.


Добавлено:
LazyKent

Цитата:

Если не затруднит, попрошу сделать в другом формате

http://rghost.ru/43173214


Добавлено:
F777

Цитата:
Можно исправить?

Конечно, баг. Конечно, исправлю.

Цитата:
И самый главный вопрос. А не могли бы Вы влить все Ваши новшества в Scan Tailor Plus и вообще работать в дальнейшем именно с ним, а не с классическим вариантом?

Если будет время. Но это может сделать теперь и любой другой человек - мои правки кода я же выложил. Но я буду теперь переделывать полностью вывод разделённых сканов - чтобы получать сквозную нумерацию 0001.tif, 0002.tif, ... 0010.tif.

Мне не нравится ни Plus, ни тем более Enhanced. Ну что это такое в Plus:

Цитата:
1) удаляем файл автосохранения UnnamedAutoSave.Scantailor для неизвестного проекта, если он есть 2) автосохранение делается в файл Project.Scantailor.as 3) файл проекта Project.Scantailor переименовываем в Project.Scantailor.bak 4) файл автосохранения Project.Scantailor.as переименовываем в файл проекта Project.Scantailor 5) бэкап файла проекта Project.Scantailor.bak не удаляем

Да кто это будет делать - "удаляем", "переименовываем"? Если уж и делать авто-сохранение - то хотя бы так, как в СканКромсаторе: неизвестный проект - не сохранять автоматом (т.е. если юзер забыл сохранить изначально свой проект - сам виноват), а авто-сохранение проекта делать в момент перелистывания на следующую страницу. Это надёжно защитит юзера от случайного падения программы. Да и в Настройках Plus понаворочено тоже уже подозрительно много всего.

А Enhanced уже начал напоминать внешне СканКромсатор.

Так что, если уж и делать - то только свой клон, куда собрать всё разумное из других клонов + своё. Да и потом - неэтично забирать под себя чужие клоны. А вдруг автор клона захочет снова там что-то сделать.

Добавлено:

Цитата:
или баг? Можно исправить?

Исправил:

http://rghost.ru/43175226
Автор: LonerDergunov
Дата сообщения: 20.01.2013 13:02
monday2000
Спасибо большое за прямоугольное выделение.
А можете ещё добавить такую возможность: имеется прямоугольная зона картинок, зажимаем Ctrl и тянем любой угол - при этом будет тянуться не только этот угол, а вся прямоугольная рамочка.
Автор: monday2000
Дата сообщения: 20.01.2013 14:21
LonerDergunov

Цитата:
при этом будет тянуться не только этот угол, а вся прямоугольная рамочка.

Не понял - это как? В смысле двигать всю зону целиком?

Добавлено:
А зачем это?
Автор: LonerDergunov
Дата сообщения: 20.01.2013 15:11
monday2000
В Фотошопе нарисовать прямоугольник, затем вызвать FreeTransform (Ctrl+T) - и можно потянуть за один из углов. Фигура останется прямоугольником, но её можно сделать шире-уже, выше-ниже.
Или проще - в Pain можно нарисовать прямоугольник, и сразу потянуть за один из углов.

Для чего нужно - если с первого раза прямогульная зона выделения получилась неправильная, выделилось слишком много или слишком мало. Если на выходе хочется получить именно прямоугольную зону - приходится эту удалять, а ставить новую. А так можно будет просто потянуть за уголок и уменьшить-увеличить размер прямоугольника.
Автор: F777
Дата сообщения: 20.01.2013 15:18
LonerDergunov
А Вы внимательно читали все то, что было написано выше?

Цитата:
прямоугольное сдвигание углов зоны иллюстраций

monday2000
Спасибо, теперь нормально.
Автор: LonerDergunov
Дата сообщения: 21.01.2013 01:21

Цитата:
А Вы внимательно читали все то, что было написано выше?

Наверное, нет Я не понял о чём речь.
Сейчас проверил - да, прямоугольное сдвигание работает.
А не работало оно у меня, наверное, по следующей причине - потянул за "неправильный угол", удалил выделение, выделил снова, и после этого правильных углов уже не существовало.

Этот же нюанс остался и в нынешней версии. Баг, но мелкий (если и встретится, то редко).
Как повторить.
Выделяем прямоугольник, кликаем мышкой на угол БЕЗ Ctrl, сдвигаем, получаем "неправильный" четырёхугольник, удаляем это выделение, выделяем снова изображение с зажатым Ctrl - выделится прямоугольник. Теперь зажимаем Ctrl и пытаемся выполнить прямоугольное сдвигание снова. А уже не получается ни за какой из углов, выделение искривляется.

Добавлено:
Ещё такое пожелание (наверное мифическое) - опционально сделать автоматическое исправление наклона по тому же алгоритму, как в Акробате (в Адобе наверняка работают разумные люди и их алгоритм, скорее всего, довольно "корректный").
Цель: Обработал скан, Скантейлор исправил наклон. Загрузил сканы в Adobe Acrobat, создал pdf, выполнил ClearScan - наклон исправился заново. Получается не очень красиво - если страница занята картинкой, то по краям появляются белые поля. Если бы изначально Скантейлор выполнил наклон так как это делает Акробат - результат был бы лучше.
Автор: DikBSD
Дата сообщения: 21.01.2013 07:23

Цитата:
Да и потом - неэтично забирать под себя чужие клоны. А вдруг автор клона захочет снова там что-то сделать.

Я буду только благодарен вам, если вы будете развивать ветку plus. Я вряд ли смогу снова включиться в разработку. Если кто-нибудь не станет развивать ветку plus - то она "умрёт".
Если в Настройках есть что-то лишнее, то вы можете в коде это удалить. Главное в Настройках - возможность задания диапазона порога бинаризации (часто жестко заданного в программе просто не хватает на книгах с плохим качеством печати).
Автор: monday2000
Дата сообщения: 21.01.2013 18:15
LonerDergunov

Цитата:
А уже не получается ни за какой из углов, выделение искривляется.

Что-то не смог повторить. Вы точно взяли самое последнее, что я выкладывал? Но, конечно, прямоугольное сдвигание прямоугольных зон задумано "в рамках разумного" - если начать их выворачивать шиворот-навыворот (меняя местами верх с низом или левую грань с правой) - то они станут "схлопываться" и деформироваться.
DikBSD

Цитата:
Я буду только благодарен вам, если вы будете развивать ветку plus.

Нет, я сделаю свой клон (если решу всерьёз заморочиться со всем этим) - по разным соображениям. А взять Ваши наработки можно хотя бы тем же diff'ом.


Добавлено:

Цитата:
Ещё такое пожелание (наверное мифическое)

Для моего уровня - пожалуй.
Автор: DikBSD
Дата сообщения: 22.01.2013 06:29
monday2000

Цитата:
Нет, я сделаю свой клон (если решу всерьёз заморочиться со всем этим) - по разным соображениям. А взять Ваши наработки можно хотя бы тем же diff'ом.


Как вам будет угодно. Главное - чтобы ваш код постоянно где-то выкладывался (ветка вашего клона на сайте Tulonа, или код вашего клона на любом другом сервере, или просто архивы кода где-то, или что-то еще - хотя первые варианты удобнее). Тогда пользователи смогут сами скачать ваш код и собрать у себя на любой системе, при желании что-то изменив "под себя".
Автор: monday2000
Дата сообщения: 27.01.2013 11:01
Я сделал новую сборку - с экспортом разделённых сканов - в сплошной нумерации вида 0001.tif, 0002.tif, ...., 0010.tif, ....

Я сделал в главном меню новый пункт - Export..., по нажатию на который открывается окно, где можно указать папку вывода, разделять смешанные сканы на субсканы или нет, и ещё есть опция вывода в папку по умолчанию.

Папка по умолчанию - это автоматически создаваемая папка "export" внутри папки "out". Если пользователь указывает свою папку вывода - то всё равно в ней автоматически создается папка "export" - а уже в неё делается вывод.

Так что в любом случае создаётся папка "export", куда делается вывод.

Если стоит галка "Split mixed output" - то в папке "export" автоматически создаются подпапки с именами "1" и "2" - соответственно для передних и задних субсканов. Если попадается не-"смешанный" скан, то он попадает в папку "1" - если чёрно-белый, или в папку "2" - если серый/цветной. Имена файлов, естественно, присваиваются в сплошной нумерации, и у каждой созданной пары субсканов - одинаковые имена (а папки разные - "1" и "2").

Если галка "Split mixed output" не стоит - то в папку "export" просто выводятся все сканы - но уже в сплошной нумерации.

При экспорте осуществляются все нужные проверки:

- Загружен ли проект
- Не находится ли в процессе пакетная обработка
- Нет ли знаков вопроса на какой-либо из миниатюр стадии вывода
- Нет ли отсутствующих файлов в папке out
- Если папка вывода - не "по умолчанию", выбрал ли юзер свою папку, есть ли она, не надо ли создать и т.п.

Процесс вывода отображается постранично прогресс-баром. Ещё хотел текстом показывать номер текущей страницы - но пока не получилось, потом буду делать.

Вот сборка: http://rghost.ru/43343073 (4,5 МБ)

Технические подробности и коды исправления здесь: http://www.djvu-scan.ru/forum/index.php?topic=1137.msg5409#msg5409
Автор: tlotr
Дата сообщения: 27.01.2013 13:26
Приветствую!

И в версии 0.9.11.1 от Tulon и билде monday2000 от 20-го января всё ещё есть баг с созданием выходного файла tiff размером 8 байт (нашёл упоминание тут, но у меня воспроизводится и без перекосов). Известны ли причины некорректного сохранения?
Материалы (проект и файл для воспроизведения) тут.
Автоматически в смешанном режиме определяются не все области картинок. При ручном доопределении ещё нескольких областей файл в папке pic создаётся размером в 8 байт.
Стоит удалить ручные области (или хотя бы самую геометрически сложную), как файл создаётся нормально.

Это не единственный файл, точно так же создаётся 8-байтовый файл для
а) некоторых похожих по сложности картинках в "смешанном" режиме;
б) некоторых изображений в "цветном" режиме (соответственно, без всяких областей);
Если требуется, то могу выложить и их.

Система - W2003SP2, оперативной памяти и дискового пространства достаточно.

Буду благодарен за помощь советом или делом.

Страницы: 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061

Предыдущая тема: CmCkA v4


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.