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

» Scan Tailor: Часть 2

Автор: papaVlad
Дата сообщения: 16.06.2016 23:57
hogu77, оставлю эту фразу без изменений """малейшее изменение наклона даёт размытие""", относится к любому редактору, в том числе и СТ и ACDSee, и без проблем могу добавить """что «не так страшен чёрт ...»."""

Цитата:
сразу же после этого засядешь за фотошоп!
Пока нет необходимости.

NME
Цитата:
это произойдет в том случае, если скорость чтения данных с носителя меньше скорости "распаковки" сжатого изображения.. имхо.. всё зависит от железа..

4lex4
Цитата:
Все верно, но не только...
Вообще имеет смысл сжимать...
Вот цитата из вики про UPX:
Самое весомое и неоспоримое преимущество...

Что же Вы так сложно пишете? Ну не все тут с образованием, попадаются и """неофиты""". Пытаюсь понять смысл этих фраз, но моя скорость чтения с мозга ниже скорости распаковки этих слов, потому нафик Вашу теорию, перейдём к практике и помучаем железо, благо днём появилось время.

В этот раз использовался ноутбук с железом 2014 года:
http://i71.fastpic.ru/big/2016/0617/0a/bf4b2d137047b674f536ef32f786840a.png
- скорость SSD http://i65.fastpic.ru/big/2015/0406/cd/3b012c7322047e801c97b2b8d21b79cd.png
- скорость HDD (5400 об/м) http://i65.fastpic.ru/big/2015/0406/91/be5e27b64af6820be17ae476b76ea991.png

В итоге вот такие результаты вывел для себя - ничего из этого """Я лично проверял работу... Вы легко можете это проверить... Это незаметно, если файл маленький... Не забывать, что все зависит от железа...""" в моих тестах не подтвердилось, и хорошо, по-прежнему советую использовать тиф несжатый и сам остаюсь на нём.
Правда пакетную обработку проверял на ACDSee и ещё одну позицию не смог проверить, просто не знаю способа, как открыть 10 файлов разом, какой-то скрытый смысл у этой фразы, возможно тоже из фотошопа, думаю, что я этим не пользуюсь, взамен проверил по другим, неуказанным выше операциям, всегда LZW проиграл.
4lex4, далее Ваше право, можете продолжать сжимать, можете распространять вики-ссылки, я не мешаю, и даже верю, что у Вас всё наоборот, потому и не буду спорить, не имею цели создать в этом топике раздор.

Да, я всё записал на видео, но в этот раз пожадничаю, отвечу всем желающим цитатой """Вы легко можете это проверить""" и желаю, чтоб у всех железо не подвело и Ваша дружная команда победила.

4lex4
Цитата:
papaVlad, вообще ничего не понял. Объясните понятно и подробно.

Вот и я также, через слово вставляю в поисковик или переводчик, чтоб хотя бы как могу поддержать """этот батл djvu vs pdf""".
Когда появится фотошопер-непоймёнышь, то отошлю его сюда, а мне это и не нужно было, мне всё понятно.
Автор: 4lex4
Дата сообщения: 17.06.2016 02:16
papaVlad, если вы записывали на видео, то заняли процессор - результаты уже неправильные.

Я тоже проверил, в обычных условиях LZW действительно проигрывает в по скорости открытия. Скорее всего у LZW медленный алгоритм распаковки.
Но если жесткий диск занят чем-то посторонним, то LZW открывается намного быстрее - вот в чем дело.
Вообщем да, если много места, лучше юзать несжатые тифы.

Добавлено:
hogu77, нет конечно, должно меняться разрешение, и важен алгоритм интерполяции.

Допустим есть скан 300 DPI. Переводим его на 600, используя бикубическую (также можно билинейную) интерполяцию. То есть разрешение по вертикали и горизантали увеличится в два раза.
Автор: suts2012
Дата сообщения: 02.08.2016 22:21

Цитата:
сделаю и кину сам профиль, пойдет?


4lex4, а можно и мне профиль?


Автор: 4lex4
Дата сообщения: 03.08.2016 03:38
hogu77, suts2012 - ваши профили.

Для DjVu small mod: Скачиваем Scanned 600 (HQ).conf и кидаем в profiles\personal
Для LizardTech Document Express Enterprise: Скачиваем инструкцию и делаем как написано.

Сразу напоминаю, что необходимо как минимум интерполировать (ресемплить) изображение до 600 DPI (лучше использовать бикубическую интерполяцию), чтоб буквы были гладкие, а лучше использовать полноценную предобработку со сложными фильтрами и сглаживанием, но об этом позже, в новости по разработке ST Advanced, я дам ссылки и покажу примеры. Сам исходник может быть и 300, и 200 DPI, сканить в 600 излишне естественно за исключением некоторых случаев.

Вот сразу пример работы из жизни:

На рутрекере есть раздача одной книженции со сложной версткой:
http://rutracker.org/forum/viewtopic.php?t=4668001

Ребята из групп, специализирующихся на книгах не запариваясь вывапливают тот шлак, который вываливают, даже не настроив кодер. Там в коментах собственно кто-то отписал жалобы по сути - потери деталей.
Собственно такого говно-djvu и навалом, когда дело касается книг со сложной версткой, но виноваты в этом люди.
(Примечание: к ч/б DjVu или ч/б + подклееные картинки после ST/SK это не относится, ибо DjVu кодер не меняет ч/б изображение значительно, потому они получаются такие как есть после обработки, независимо от профиля - но бинаризовывать в ч/б можно только книги с простой версткой без сложных элементов, для сложных, как в примере, все опирается на профиль)

Я в коментах к раздаче месяц назад выложил свой вариант, предварительно обработав (подробнее об этом я напишу позже, в новости по поводу разработки ST advanced), естественно юзая выложенный сдесь профиль:
http://rutracker.org/forum/viewtopic.php?p=70959327#70959327

Вот наш общий исходник в PDF, а по сути исходные исходные сканы 300 DPI, сжатые JPEG:
http://rutracker.org/forum/viewtopic.php?t=4261149


*Здесь должна быть новость по разработке ST Advanced, но примеры еще не готовы, так что потом.
Автор: denver 22
Дата сообщения: 03.08.2016 08:30
4lex4
"OCR от последней версии FR" - давно не занимался сборкой книг. Как-то решился вопрос со сложностями использования последних версий FR при добавлении OCR в книги через DjvuOCR? Или применяется другой способ? Если можно, хотя бы коротко опишите ваш метод. Остальное найду сам...
Автор: 4lex4
Дата сообщения: 03.08.2016 16:40
denver 22,

Цитата:
Как-то решился вопрос со сложностями использования последних версий FR при добавлении OCR в книги через DjvuOCR?

как бы уже давно, если они вообще были.

NME сделал несколько простеньких и полезных утилиток, вам нужен FR11 DjVu Text Layer Crutch, курим описание.

Буду краток:
Вот вы сделали свой DjVu.
В FR выбираем режим распознования Ч/Б, чтоб не тратить время, ибо нам нужен только текст; в настройках сохранения DjVu в FR обязательно ставим Source resolution (исходное разрешение); сохраняем в DjVu.
Теперь у нас два DjVu, наш и из FR с текстом. В DjVu Text Layer Crutch выбираем последний и щелкаем сохранить исправленный слой в другой файл, выбираем наш DjVu и готово.

Также текст можно редактировать:

Качаем DjVuLibre.
1. Вынимаем текстовый слой: djvused myfile.djvu -u -e 'output-all' > myfile.dsed;
2. Редактируем myfile.dsed;
3. Внедряем обратно: djvused myfile.djvu -f myfile.dsed -s;
4. Т. к. DjVuLibre сохраняет концы параграфов с помощью US (Unit Separator), который не всегда корректно обрабатывается ридерами, рекомендую заменить все US символами перевода строки:
FR11 DjVu Text Layer Crutch: под "не ФР11+" ставим Параграф = 0x0A, Строка = Ничего, Страница = Ничего; нажимаем сохранить исправленный слой в редактируемом файле.

*Вместо djvused можно юзать djvuxml, результат такой же, но с XML работать удобнее.

DjVuOCR можете смело форматировать, устаревшая и более ненужная программа, плюс она не поддерживает деления на параграфы. Простейший случай: если текст в двух столбцах на одной странице - с DjVuOCR вы получаете кашу. Старые версии FR тоже форматируйте.
Не думал, что есть люди, юзающие такой старый хлам.
Автор: LazyKent
Дата сообщения: 03.08.2016 20:56
Уважаемые джентльмены.

Вы сообщаете относительно интересную информацию, но, как мне кажется, к "Scan Tailor" она не имеет отношения.
Возможно, технические подробности кодирования стоит обсуждать в более подходящей теме.
Автор: hogu77
Дата сообщения: 15.08.2016 15:43
4lex4
Итак, сердечно благодарю за профиль и наглядный пример, буду пробовать на сложных случаях.
Просьба. Что бы не было испорченного телефона, напишите пожалуйста в эту например тему сообщение о профилях, хоть пару предложений. Необходимость такого поступка думаю не требует излишних слов.
Памятуя про гладкость букв и будущие ссылки и примеры хотел и я сказать пару слов про методы интерполяции но после сообщения LazyKent'а, рука не поднимается. Да и пожалуй подожду ваши примеры, может чего и не знал.
Автор: henderson
Дата сообщения: 25.08.2016 11:56
Возможно это обсуждалось. Столкнулся с тем, что программа не выводит изображения в папку out. Прошел все шаги, запускаю вывод изображений, программа показывает, что работа идет, а в папке out - пусто. При повторном запуске появилось только одно изображение и то не с начала книги. Может быть дело в длинном пути до папки out? Как тогда его сменить? Переносил папку с файлами ближе к корню диска, настройки ковырял, но программа потом жалуется, что не находит обрабатываемые файлы. Система Windows 8.1 64-bit.
Автор: henderson
Дата сообщения: 25.08.2016 19:50
Проблема вроде решилась кликом в путях проекта на путь первого редактируемого изображения. По крайней мере после этого в папке out стали появляться файлы.
Автор: Fafy
Дата сообщения: 30.08.2016 16:59
Только недавно обрел сие чудо.
Программа ОЧЕНЬ нужная, и сделан правильный подход к реализации. Но есть один момент, который может перечеркнуть все преимущества данной программы - частое неправильное распознавание полезной области, на поправление которой может уйти столько времени, сколько требуется на ручную обработку в графических редакторах, например, инструментом кадрирования в ACDSee Pro.

Программа много ошибается даже на практически идеальных страницах. Это касается в первую очередь нумерации страниц, и в меньшей степени - ширины колонок.
Бывает даже так, малю-ю-ю-ю-ю-ю-сенькую точечку программа увидит, а нумерацию страниц из несколько цифр выделенных широким тире (например: — 450 —) не хочет видеть. Из почти 500 страниц нумерацию страниц внесло в блок полезной области только 40 страниц. Сканы качественнные и на чистой белой бумаге. Текстовый блок захватывает, а нумерацию очень редко.

В FineReader 12 распознавание полезной области работает достаточно качественно, чего, конечно, не скажешь о выравнивании там страниц. Хотя бы дотянуть до уровня распознавания полезной области FineReader.
Пускай автомат будет немного дольше распознавать полезную область, зато меньше ручной правки, чем быстрая работа распознавания и долгая работа ручной правки.

Качество оригиналов бывают совсем разные, от практически идеальных страниц, до просто ужасного качества сканов или фоток. И применять к таким разным сканам один алгоритм, без каких-либо настроек этой функции было бы не совсем правильно. Ведь есть же критерии, по которым определяется полезная область, значит, и можно, и желательно управлять самим процессом распознавания.

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

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

Конечно, говорить это не делать. Но если не повысить качество распознавания полезной области, то теряется главное преимущество этой программы - автоматизация. Функция распознавания полезной области здесь самая важная, и от нее напрямую зависит сколько ты затратишь время на обработку сканированных книг.
Автор: amaid
Дата сообщения: 31.08.2016 08:25
Fafy, чудак, файнридер шлифует толпа программеров на зарплате, а ST - бесплатно сделал одинокий болезненный гений. Полезная область распознается вполне приемлемо, на других книгах увидишь. Добавь поля снизу, где номера страниц, если многие не распознаются.
Автор: slava_kry
Дата сообщения: 31.08.2016 09:45
Fafy
Забавный коммент... Для чего он?
Могу "обосрать" любую прогу OCR.
Например, ни одна из них не понимает выворотку/инверсию... и чО!?
Края изображений распознаются по-серому и потому светлые цветные полутона идут лесом... и чО?!

Полная автоматизация ИМХО невозможна, т.к. количество входных параметров практически бесконечно.

А так, вы перед тем как сувать сканы в СТ сделайте небольшую краевую резкость - и распознавание улучшится.

А конструктив по программе сделайте сами или найдите программиста - и все будут вам благодарны. Тем более, что исходники открыты.
Автор: Fafy
Дата сообщения: 31.08.2016 11:23

Цитата:
Забавный коммент... Для чего он?

slava_kry Наверное, чтобы вы могли сделать это:

Цитата:
Могу "обосрать" любую прогу OCR.

А вы кроме "обосрать" еще что-то умеете?
И да, с этим делом явно не в эту тему!

Цитата:
А так, вы перед тем как сувать сканы в СТ сделайте небольшую краевую резкость - и распознавание улучшится.

Попробую, но что-то есть большие сомнения.

Цитата:
Полная автоматизация ИМХО невозможна, т.к. количество входных параметров практически бесконечно.

А никто и не говорит о полной автоматизации, или о супер-пупер распознавании. Хотя бы немного улучшить этот процесс, ведь, повторюсь, от этой функции напрямую зависит затраченное время на обработку книги. Если же скорость АВТОМАТИЗАЦИИ будет равна РУЧНОЙ обработке, то какой вообще смысл в этой автоматизации?

Цитата:
Fafy, чудак, файнридер шлифует толпа программеров на зарплате

amaid Scan Tailor лучше справляется с выравниванием, но по вашей логике должно быть все наоборот.

Цитата:
Полезная область распознается вполне приемлемо

Все что принимаем, все это приемлемо. Да, тут все логично. Но ни о каком развитии программы не будет речи, если будем останавливаться на "приемлемом" и не стремится к "лучшему". И это не зависит от толпы програмеров.

Цитата:
Добавь поля снизу, где номера страниц, если многие не распознаются.

Когда страницы снизу, то это работает, когда же сверху, то не совсем.
Автор: slava_kry
Дата сообщения: 31.08.2016 13:05
Fafy
Тогда вам наверное следовало бы сначала изучить, как создавалась программа, благо это просто. Узнать что делал её один человек и сейчас его здесь нет... по некоторым причинам. Кстати, такие как вы тоже были причиной. Некоторые товарищи только и делали что писали, что им хочется, но при этот никто из них ничего не сделал для воплощения своих хотелок в жизнь.
Последняя моя строчка успешно проигнорирована?...

Посмотрите историю СК. Там дела несколько лучше только потому, что автор программы сам занимается обработкой книг до сих пор.


Цитата:
Попробую, но что-то есть большие сомнения.

Ну и чем вы лучше моих слов?
Для начала могли бы выложить пару страниц для экспериментов, аднака...

Автор: Fafy
Дата сообщения: 31.08.2016 14:03

Цитата:
Цитата:
Попробую, но что-то есть большие сомнения.
Ну и чем вы лучше моих слов?

Попробовал, результат еще хужий, и что?

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

Сначала было желание, но такие как вы сразу отбивают всякую охоту. Может причину, что автора в этой ветке нет лучше поискать в себе, а не в других? Нет?
Я ничего ни от кого не требую, просто описал проблему и пожелание. Принял бы кто во внимание, хорошо, нет, так нет.
Был бы програмистом, не переживайте помог бы и программным кодом, можете не сомневаться.

Цитата:
Некоторые товарищи только и делали что писали, что им хочется

Вы что-то путаете. Неужели в моих пожеланиях есть то, чего категорически не хотят другие? Пора бы ответить себе на этот вопрос. Думаю, тогда бы глупостей не писали.


Автор: slava_kry
Дата сообщения: 01.09.2016 08:19
Селяви

Страницы: 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061

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


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