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

» Scan Tailor

Автор: Dashout
Дата сообщения: 02.02.2010 11:58
Уважаемый Tulon
Если текст покажется Вам полезен – буду рад. Нет – не проблема. Для меня главное это как-то поучавствовать в том большом и нужном деле, которое Вы реализуете. Вспомните японский "кружок качества" – только 5% предложений дают эффект, но не было бы предложений, не было бы и этих значимых 5%.

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

Идея конвейера СТ позволяет максимально быстро и качественно сформировать маршрут C-F-A-(GH)-K. Основная сердцевина этого маршрута (C-F-A) уже реализована. Этот маршрут закрывает потребности большого числа пользователей – такая рыночная ниша в настоящее время реально существует.
Следуя идее конвейера СТ логично было бы предположить, что 85% изображений (сырья) на входе в блок С имеют отличное качество. 15% - проблемные изображения, но ведь СТ не позиционирует себя как средство для устранения брака сканирования! На мой взгляд, потенциал этого комплекса значительно выше!
Лозунг к конвейеру СТ – "Что положил, то и получил"!
Для исправления изображений, вводится блок дополнительной обработки (В). Одновременно, из блока С исключаются все алгоритмы корректировки текста.
Качественное развитие блока В в идеале приведет к внедрению векторных символов – а это уже шаг до ОСR. Но уверяю вас, сегмент рынка (потребители) блока L останутся и при OCR – это отдельный сегмент рынка.
Правильное позиционирование позволит стабильно наращивать объем потребителей (полезность программы). С точки зрения маршрутов, реализовать маршрут (D,E,M,O)-C-F-A-(GH)-K, последовательно наращивая возможности блока В.
Обращаю внимание на предусловие (блок Х). Оно может при данном позиционировании звучать так: "читабельная страница А4". Изображения текста на станицах всей книги имеют строго постоянный и фиксированный масштаб отображения!".
Напрашивается некая дополнительная зона - информационная площадь страницы (ИП), более сложный вариант ее реализации отработан у Вас в алгоритме выделения полезной области.
Ориентация на ИП позволит в т.ч. устранить эффект динамически меняющегося фокуса при фотосканировании (блок О), а следовательно увеличит полезность комплекса.
Можно предположить, что ИП – это некая маска строго прямоугольной формы. Внутри ИП содержатся упорядоченные (с равными межблоковыми расстояниями) маски блоков информационной области текстовой строки (ИПТС).
Размер ИП устанавливается не по одной странице, а при анализе всей совокупности страниц.
Принятая ширина ИП – аксиома!
Наложение ИП на растр осуществляется по любому углу текстового блока с последующим масштабированием внутренних блоков ИПТС. Далее можно идти методом исключений: разрыв блоков ИПТС против принятой ширины (а также по высоте) формирует некую площадь, которая является либо картинкой, либо пустым местом.
Блок картинки и текста имеют различный инструментарий корректировки. Следовательно, нужно обеспечить вывод файла целиком и, отдельно, файлов картинок (по желанию пользователя). Зная код ИП, индекс файла картинки и его координаты на ИП кодировщик в PDF, DJVU (G,H) должен легко собрать в один файл – готовую продукцию.

В любом случае реализации - удачи Вам и спасибо за труд!
Автор: amz01
Дата сообщения: 02.02.2010 14:31
monday2000
Поддерживаю просьбу о разделении картинок и серых сканов. После пересъёмки книг цифровым фотиком часто приходится выравнивать строки, а слегка кривую картинку можно оставить и не тратить времени на неё.

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

Хорошо было бы при разделении текcта и картинок сделать возможность прохода обработчика только по отмеченным иконкам страниц, а не по всем подряд. Тем более, что возможность выбора страниц есть, но она не используется.

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


Автор: woodyfon
Дата сообщения: 02.02.2010 16:49
Придумали целую науку о сканировании книг, сами же и запутались. Книгу можно сделать либо идеально, либо очень хорошо (читабельно). Я понял, чтобы найти недостатки, надо сначала определить достоинства. Которых, не побоюсь, программа уже имеет предостаточно и обрабатывает большинство сканов именно в пакетном режиме, что ранее было только мечтой человека, который решил оцифровать книгу. А сейчас пару конструктивных предложений и замечаний.
1. Не очень корректно берутся значения самой широкой и самой высокой страницы, если потом некоторые страницы удалить (страницы книги или половина скана)
2. Не хватает функции выравнивания общего освещения яркости изображения в режиме смешанный (текст бинаризировать, а иллюстрации подправить по яркости). На данный момент лучше всего использовта MSR (Multi-Scale Retinex). Сейчас кстати работаю над алгоритмом (изучаю мат аппарат). В дальнейшем он может пригодится для осуществления алгоритма dewrap.
3. Чтобы на каждый разрез скана отводился свой номер, т. е. первый скан делится на две страницы - нумерация будет такой: левая страница = 1, а вторая = 2, далее, например, в восьмом скане убрали левую страницу (решили ее обрабатывать отдельно), тогда нумерация будет такой: правая 16 (левая, которая должна быть 15 просто пропускаем). Как цель - не запутаться, какие страницы еще пришлось обрабатывать. А лучше всего сделать на этапе вывода шаблон нумерации.
У меня схема оцифровки книги маленькая.
Бумажаная книга-Процесс сканирования (пакетный режим)-Обработка в SR + ручное редактирование иногда до 5% от общего количества страниц + Виртуальная печать в PDF или DjVu. Качество книги = очень хорошее. Можно, конечно, и OCR-слой наложить, и сделать оглавление, гиперссылки. Но в большинстве случаем этого не требуется. Потому что книги либо смотрятся непосредственно с экрана монитора, или распечатываются
Автор: amz01
Дата сообщения: 02.02.2010 18:42
woodyfon

Цитата:
...общего освещения яркости изображения...

"Наука о сканировании книг" отдыхает...
Автор: woodyfon
Дата сообщения: 03.02.2010 18:40
amz01, На трольство не реагирую. Сорри.
Топиками ранее отписывался о том, что обратился за помощью по алгоритму dewarp к специалисту Рамизу Зейналову. Буквально вчера получил ответ. Он согласен предоставить исходники на условии и требованию цитирую:

Цитата:
Я готов вам предоставить свои исходники при условии сохранения авторства
и указания ссылки на мою лабораторию (Лаборатория Компьютерной Графики и Мультимедиа при ВМиК МГУ, Graphics & Media Lab, graphics.cs.msu.su, Группа Компьютерного Зрения).

Tulon, сможете сделать ссылку на лабораторию и указать авторские права на алгоритм? По идее лицензия GNU GPL должна это гарантировать. А то не очень хорошо получится если возьмем алгоритм, а человека работающего над ним не отметим.
Чтобы не быть голословным, в течении нескольких дней предоставлю результаты обработки искаженных изображений, чтобы каждый смог удостоверится, что этот алгоритм есть наилучшим из доступных. Поэтому просьба ко всем: пожалуйста, предоставьте, исходные изображения для проверки. Желательно с наличием планарных, перспективных искажений, сфотканных, где есть блики и сильно затемненные/осветленные области. Могу и сам, но это будет необъективно.
Автор: amz01
Дата сообщения: 03.02.2010 19:41
woodyfon
Как раз болезненная страсть к сочинению наукообразного и безграмотного порожняка - удел троллей.

Вот здесь статья этого Рамиза о выравнивании строк:
www.graphicon.ru/2008/proceedings/Russian/SR4/Paper_4.pdf

И ещё несколько статей на эту тему:
www.graphicon.ru/2007/proceedings/Papers/Paper_37.pdf
www.graphicon.ru/proceedings/2009/conference/se9/121/121_Paper.pdf
smu.cs.msu.su/conferences/diploma2009/diploma-2009.pdf

Автор: Tulon
Дата сообщения: 03.02.2010 20:41

Цитата:
Tulon, сможете сделать ссылку на лабораторию и указать авторские права на алгоритм? По идее лицензия GNU GPL должна это гарантировать.

Можно сделать примерно так:

Код:
/*
Scan Tailor - Interactive post-processing tool for scanned pages.
Copyright (C) 2005-2009 Graphics & Media Lab, Computer Vision Group,
Moscow State University, http://graphics.cs.msu.su

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
*/
Автор: woodyfon
Дата сообщения: 03.02.2010 22:39
amz01, три первые статьи были выложены мной ранее. Тролль должен каго-то зацепить. Кипешь подняли как малое дите. Лучше б изображения дали.
Tulon, это указывается в исходниках. Я думаю, автор хочет, чтобы было и в бинарниках. Это можно будет осуществить?
Автор: Tulon
Дата сообщения: 04.02.2010 11:03

Цитата:
Tulon, это указывается в исходниках. Я думаю, автор хочет, чтобы было и в бинарниках. Это можно будет осуществить?

Я конечно могу это сделать, но это будет под честное слово, так как в GPLv3 такого требования нет. Если скажем кто-то захочет взять этот код и вставить в свою собвственную программу, он не обязан упомянать авторов в окне About или где-либо еще, кроме как в исходном коде.
Автор: monday2000
Дата сообщения: 04.02.2010 12:03
Вот пример работы dewarp от Rob в новом СТ:

http://www.djvu-soft.narod.ru/scan/curved_sample.rar (1 МБ)

В этом примере алгоритм Rob вообще никак не меняет исходный искривленный скан.
В этом примере алгоритм Rob выпрямляет исходный искривленный скан, но при этом сильно уродует часть строк скана.

Для сравнения там же прилагается тот же образец, но выпрямленный в Book Restorer 4.2.1 (получилось отлично).
Автор: woodyfon
Дата сообщения: 04.02.2010 13:09
Алгоритм Rob'a заточен под серые сканы и жестким ограничением разрешения. Может поэтому и не обработал. Согласен, алгоритм странно себя ведет - иногда так искривляет изображения (изначально без геометрических искажений для текста), что и нарошно не сделаешь .
monday2000, просьба выложите исходную картинку в bmp или tiff. Желательно серую.
Автор: anagnost96
Дата сообщения: 04.02.2010 13:16
Хм. Я попробовал обработать черно-белую страницу из Djvu (предварительно удалив красный штамп), и вот что у меня получилось:

http://www.thessalonica.org.ru/downloads/curved_sample.tiff

Как видим, результат обработки некорректен и, можно сказать, демонстрирует разом все глюки алгоритма, но тем не менее нельзя сказать, что скан "никак не меняется"
Автор: monday2000
Дата сообщения: 04.02.2010 13:21
woodyfon
Выложил. Линк тот же.

Добавлено:
anagnost96

Цитата:
но тем не менее нельзя сказать, что скан "никак не меняется"

Извиняюсь, я ошибочно не придал значения замечанию Tulon насчёт только чёрно-белого режима. Это Tulon забыл сделать, чтобы флажок Dewarp не показывался при режиме "Смешанный".

Добавлено:
anagnost96
Я подправил свой пример - сделав dewarp в новом СТ в режиме "Чёрно-белый". Ссылка та же.

Добавлено:
Я, кстати, именно под эту книгу делал ST GreyText - т.к. на сканах этой книги полно скриншотов диалоговых окон, и при этом все сканы этой книги нуждаются в выравнивании освещённости и выпрямлении искривленных строк а-ля BR.

Очевидно, что СТ пока что на это неспособен - но и cделать предложенный мною вывод "только текст (в режиме серого)" пока что никто не торопится (чтобы делать выравнивание освещённости и выпрямление искривленных строк в BR).

А как иначе прикажете делать такие сканы (если с участием СТ)? Так что, именно для таких сканов ST GreyText (или иное похожее решение) - пока что единственный выход.

Добавлено:
Я занёс в шапку 2 ссылки: на последний СТ и на свой пример исправления искривления строк, а также немного "причесал" шапку.
Автор: anagnost96
Дата сообщения: 04.02.2010 18:19
Tulon


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


Более того, добавление подобного требования к лицензии сделает ее заведомо несовместимой с GPL. В этой связи уместно вспомнить историю с XFree86 4.4: там попытка модифицировать лицензию именно в таком духе привела к всеобщему бойкоту проекта.

monday2000


Цитата:
А вывод каждого сорта сканов в свою папку внутри "out" Вы смогли бы сделать?


А смысл? Всё равно файлы после каждого прогона требуют переименования и некоторой постобработки (хотя бы приведения пиксельных размеров к кратным значениям).


Цитата:
все сканы этой книги нуждаются в выравнивании освещённости и выпрямлении искривленных строк а-ля BR


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

Кстати, я обнаружил интересный момент: оказывается, результат работы dewarping'а зависит от настроек порога бинаризации. В данном случае его уменьшение на несколько единиц существенно улучшает картину.
Автор: monday2000
Дата сообщения: 04.02.2010 19:41
anagnost96

Цитата:
Всё равно файлы после каждого прогона требуют переименования и некоторой постобработки (хотя бы приведения пиксельных размеров к кратным значениям).

Это я не понял. Что такое "файлы после каждого прогона"? Имеется в виду "каждый сорт выводных сканов (типа "только текст, только изображения")"? Зачем переименование? Зачем приведение пиксельных размеров к кратным значениям? Я бы ничего этого не делал.

Цитата:
А смысл?

Ну как же - а зачем же Вы делали свой патч для СТ? В смысле, для чего Вы делали возможность вывести "только текст", "только изображения"? Я-то подразумеваю, что Вы это сделали для одной-единственной цели: чтобы получить пары субсканов для метода разделённых сканов. Никакой другой цели ведь просто и быть не может (по крайней мере, на сегодняшнем уровне развития технологий DjVu-книгосканирования).

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

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

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

Да, не очень видно. Если попадётся под руку - я выложу более очевидный пример. Я имел в виду, что примерно половина сканов той книги одновременно и содержат полутоновую иллюстрацию, и нуждаются в выравнивании кривых строк-коррекции освещённости в BR. А в BR-то загоняются все сканы книги без разбора - те, которые нуждаются в обработке, и те, что нет (поэтому на этом скане и не видно, что ему нужно освещённость выравнивать).

Добавлено:
Кстати - действительно можно вместо раскладывания по папкам задавать в именах сканов из каждого сорта вывода свой некий суффикс - так, как это делается в СК. Например, в имена сканов "только изображения" добавлять сзади суффикс ".sep" (как в СК).

Сделайте хоть так (хотя раскладывание по папкам куда предпочтительнее).

Добавлено:
anagnost96
Как бы Вы ни сделали - то ли раскладывание по папкам, то ли добавление суффикса - я потом просто модифицирую и DjVu Small, и DjVu Imager так, чтобы они смогли напрямую "понимать" этот отличительный признак (разных сортов вывода).
Автор: anagnost96
Дата сообщения: 04.02.2010 20:43
monday2000

Цитата:
Имеется в виду "каждый сорт выводных сканов (типа "только текст, только изображения")"?


Ну да.


Цитата:
Зачем переименование?


В первую очередь именно ради того, чтобы имена задних субсканов отличались специфическим суффиксом (я использую 'bg', но можно и 'sep').


Цитата:
Зачем приведение пиксельных размеров к кратным значениям?


Затем, что по спецификации djvu размеры маски должны быть строго кратными размерам фона. Без этого склеивание слоев посредством djvumake просто не работает. По уму, конечно, СТ сам должен следить, чтобы пиксельные размеры соответствовали данному требованию, но я не очень представляю, как это сделать.


Цитата:
Кстати - действительно можно вместо раскладывания по папкам задавать в именах сканов из каждого сорта вывода свой некий суффикс - так, как это делается в СК.


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

И еще: вот, допустим, некоторые страницы выводятся в черно-белом режиме, а другие -- в смешанном с установкой "только текст". Куда их класть: в ту же папку, или в разные?
Автор: StanFreeWare
Дата сообщения: 04.02.2010 21:23
monday2000
А как продвигается поддержка пользовательских зон в ST Pic 1.0? Вы же разобрались, они в xml прописаны?
Ведь, доведи Вы ее до конца, особой необходимости в патче (по крайней мере в текущей редакции) не было бы.. Прошел в смешанном режиме в один проход, чуть поправил зоны, разложил через ST Pic на составляющие, и в путь!
И поддержка новых версий ST была бы автоматической...
Автор: monday2000
Дата сообщения: 05.02.2010 08:49
anagnost96

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

Что-то я не понимаю: зачем что-то делать в этом отношении? Когда я создаю "только текст" (передний субскан), а затем "только изображения" (задний субскан) в Вашем клоне СТ (СТА), то пиксельные размеры обоих получаемых субсканов одинаковы. Всё, больше ничего не требуется - кратное изменение размеров следует делать уже в программе, кодирующей задние субсканы по методу разделённых сканов (у передних субсканов менять пиксельный размер не требуется). Например, DjVu Imager делает такое кратное изменение размеров - при использовании параметра ДЗФ. Я бы даже сказал, что делать такое кратное изменение размеров в СТ ни в коем случае не следует.

Кстати, раскладывание по папкам достаточно сделать только для режимов "только текст" и "только изображения", а "текст и изображения" пусть себе выводятся в out (как сейчас).

Добавлено:
StanFreeWare

Цитата:
А как продвигается поддержка пользовательских зон в ST Pic 1.0? Вы же разобрались, они в xml прописаны?

Я забросил эту программу. Когда я её делал, я ещё не вполне понимал, что такое СТА, и что он делает. Оказалось, что СТА ликвидирует нужду в такой функциональности ST Pic 1.0, как генерация субсканов из чёрных трафареток обычного СТ + файл задания СТ. Это был бы такой страшенный геморрой для меня, что без крайней нужды делать это мне не захотелось.

Добавлено:
StanFreeWare

Цитата:
И поддержка новых версий ST была бы автоматической...

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

Я даже не знаю - и почему это Tulon пока не сделал СТА основной версией СТ? Сделать это совершенно необходимо - т.к. СТ в чистом виде никуда не годится, а только лишь СТА более-менее приемлем как средство сканобработки (разумеется, только вкупе с ST GreyText).
Автор: anagnost96
Дата сообщения: 05.02.2010 09:11
monday2000

Цитата:
Что-то я не понимаю: зачем что-то делать в этом отношении? Когда я создаю "только текст" (передний субскан), а затем "только изображения" (задний субскан) в Вашем клоне СТ (СТА), то пиксельные размеры обоих получаемых субсканов одинаковы.


Патч делался не в последнюю очередь для того, чтобы избежать потребности в выводе картинок в увеличенном разрешении. Т. е. я вывожу текст на 600 dpi, а картинки -- чаще всего в родном разрешении (например, 300). При таком использовании пиксельные размеры никак не могут быть одинаковыми.


Цитата:
кратное изменение размеров следует делать уже в программе, кодирующей задние субсканы по методу разделённых сканов (у передних субсканов менять пиксельный размер не требуется).


А придется менять: ведь вполне может получиться, что длина или ширина переднего субскана элементарно не делится на нужное число (например, 2). Между прочим, спецификация djvu рекомендует, чтобы пиксельные размеры были кратными двенадцати, чего СТ, конечно, не соблюдает.


Цитата:
Я бы даже сказал, что делать такое кратное изменение размеров в СТ ни в коем случае не следует.


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


Автор: monday2000
Дата сообщения: 05.02.2010 09:12
anagnost96

Цитата:
И еще: вот, допустим, некоторые страницы выводятся в черно-белом режиме, а другие -- в смешанном с установкой "только текст". Куда их класть: в ту же папку, или в разные?

В разные. Всегда в разные. Это пусть потом DjVu Imager разбирается, где в какой папке что лежит - не так уж и трудно. Я буду указывать DjVu Imager СТ-шную папку out и некий признак "сканы из СТ" - и он сам будет рыскать по папкам внутри out и разбираться, где там что лежит.
Автор: anagnost96
Дата сообщения: 05.02.2010 09:17
monday2000

Цитата:
В разные. Всегда в разные. Это пусть потом DjVu Imager разбирается, где в какой папке что лежит


Не все работают с DjVu Imager. Лично для меня такое количество папок только затруднит работу. Я бы сортировал сканы просто по принципу цветности, независимо от того, из какого режима они получены. Ну, смешанные ("Текст и изображения"), конечно, отдельно.
Автор: monday2000
Дата сообщения: 05.02.2010 09:32
anagnost96

Цитата:
Т. е. я вывожу текст на 600 dpi, а картинки -- чаще всего в родном разрешении (например, 300).

Не понимаю. Я только что попробовал сделать вывод и "только текст", и "только изображения" в СТА - получил 2 субскана, оба по 600 dpi, и оба одинаковых пиксельных размеров. В таком виде нормально, больше ничего не нужно.

А, так Вы при выводе "только изображения" переключаете выводное DPI на 300 dpi? А зачем? Не надо этого делать - пусть остаётся на 600 dpi - так же, как и "только текст".

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

Да нет же, не прийдётся. Ну и что, что не делится на 2? Это не проблема, вот формула: http://www.djvu-soft.narod.ru/soft/fi_c44.htm :

Цитата:
dib = FreeImage_Rescale(dib_tmp, (int)((width+(flag_bsf-1))/flag_bsf),(int)((height+(flag_bsf-1))/flag_bsf), FILTER_BICUBIC);

flag_bsf - коэффициент масштабирования, 2...12.
Формула рассчитана на любое значение пиксельных размеров. Формула официальная, взята из csepdjvu, и не раз была проверена в деле.

Цитата:
Смысл как раз в том, чтобы по возможности не менять размеры картинок (ни в СТ. ни где-либо еще), а вместо этого всё время работать с родным размерением.

В смысле, не поднимать выводное разрешение "только изображения" с 300 dpi до 600 dpi? ИМХО ничего страшного - можно и поднимать. Зато как удобно - получаем на выходе из СТА оба субскана одинакового DPI и разрешения - и не морочим себе голову. Качество изображения, если и упадёт от ресэмплирования с 300 dpi до 600 dpi, то незначительно. Всё равно ведь потом, уже в DjVu Imager, эти самые изображения приходится, как правило, уменьшать до ДЗФ значений 4-5 (ради качества) - а это куда как бОльшая потеря качества.

Добавлено:
anagnost96

Цитата:
Не все работают с DjVu Imager. Лично для меня такое количество папок только затруднит работу.

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

А Вы в Линуксе ведь тоже можете себе скрипт сделать - эквивалентный DjVu Imager.

Добавлено:

Цитата:
Я бы сортировал сканы просто по принципу цветности, независимо от того, из какого режима они получены.

Можно и так - но это хуже, т.к. дольше. Чтобы узнать цветность, надо открыть файл, и загрузить хотя бы его заголовок. А по пути к файлу понять, что он такое, куда быстрей.
Автор: StanFreeWare
Дата сообщения: 05.02.2010 09:40
monday2000

Цитата:
Я даже не знаю - и почему это Tulon пока не сделал СТА основной версией СТ? Сделать это совершенно необходимо - т.к. СТ в чистом виде никуда не годится

СТ в чистом виде не годится для нас с вами. Большинство "обычных" книгосканировщиков прогонят папку OUT через Djvu Small и вполне удовлетворятся результатом, который им даст автосегментация documenttodjvu.

А CTA, еще раз повторюсь, нельзя включать в существующем виде из-за необходимости многих проходов (отнюдь даже не двух) для получения результата.
Т.е. решение должно быть однопроходным, но позволяющим вывод в разных разрешениях (в том числе и из соображений быстродействия - уменьшение разрешения в 2, 3 раза относительно 600dpi увеличат скорость вывода на величину, кратную 4 и 9). А это уже серьезные изменения и в концепции программы и в структуре UI.

Попробуйте загнать изображения с некратными чб части размерами в Djvu Imager. У меня не получалось, приходилось обрезать до кратности.
Удивительное дело, пришел к правилу кратности 12 пикселам сегодня утром - а оно уже в стандарте )
Автор: monday2000
Дата сообщения: 05.02.2010 10:01
StanFreeWare

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

Да, но такую DjVu-книгу следует отправить прямиком в мусорную корзину.

Цитата:
А CTA, еще раз повторюсь, нельзя включать в существующем виде из-за необходимости многих проходов (отнюдь даже не двух) для получения результата.

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

Цитата:
но позволяющим вывод в разных разрешениях

Зачем вывод в разных разрешениях? Я же только что объяснял: наоборот, только в том же разрешении, что и "только текст".

Цитата:
(в том числе и из соображений быстродействия

Это бессмысленно. Допустим, так. Тогда уже DjVu Imager должен будет приводить размеры входных задних субсканов после СТ к размерам входных в DjVu Imager задежавюченных передних субсканов. Та же потеря скорости - но только плюс дополнительные проблемы по определению величины перемасштабирования (чреватые ошибкой).

В общем, чего мы изобретаем велосипед насчёт размеров-DPI - посмотрите на ScanKromsator: там выводятся пары субсканов, имеющих одинаковые DPI и пиксельные размеры. И я считаю, что это наиболее правильное решение. Это даёт простой стандарт - для любой последующей программы разделённых сканов (DjVu Imager, ....).

Добавлено:
anagnost96

Цитата:
Не все работают с DjVu Imager. Лично для меня такое количество папок только затруднит работу.

Зато это дало бы нам простой и чёткий стандарт: чтобы ни происходило, мы всегда твёрдо знаем, что все передние субсканы - всегда в такой-то папке, все задние - в такой-то. Просто, удобно, понятно. Стандарт.
Автор: anagnost96
Дата сообщения: 05.02.2010 10:27
monday2000

Цитата:
А, так Вы при выводе "только изображения" переключаете выводное DPI на 300 dpi? А зачем? Не надо этого делать - пусть остаётся на 600 dpi - так же, как и "только текст".


Что ж, каждому свое. Лично я не могу делать так, как Вы предлагаете: это мало того, что чревато потерей качества, так еще и ведет к забиванию мусором места на жестком диске. А этого места никогда не бывает много, если уж человек активно занимается сканобработкой.


Цитата:
Да нет же, не прийдётся. Ну и что, что не делится на 2? Это не проблема, вот формула


Ну да, масштабирование к приближенному значению. Это не поможет. Вот, StanFreeWare только что подтвердил: если размеры маски не делятся без остатка на соответствующие размеры фона, ничего работать не будет.


Цитата:
Зато как удобно - получаем на выходе из СТА оба субскана одинакового DPI и разрешения - и не морочим себе голову.


Абсолютно неудобно: десятки гигабайт на диске забиваются впустую.


Цитата:
Всё равно ведь потом, уже в DjVu Imager, эти самые изображения приходится, как правило, уменьшать до ДЗФ значений 4-5 (ради качества)


У меня картинки всё больше такие, что требуют минимального ужатия и максимального качества.


Цитата:
А Вы в Линуксе ведь тоже можете себе скрипт сделать - эквивалентный DjVu Imager.


Естественно. Но чтобы получить пары субсканов, готовые для обработки, всё равно требуется несколько предварительных этапов, и именно поэтому мне неудобно работать с папкой out непосредственно. Отсюда и отсутствие заинтересованности в автоматической раскладке по папкам.


Цитата:
В общем, чего мы изобретаем велосипед насчёт размеров-DPI - посмотрите на ScanKromsator: там выводятся пары субсканов, имеющих одинаковые DPI и пиксельные размеры.


ЕМНИП, там можно отдельно настроить разрешение вывода для каждой зоны. И это правильно.


Цитата:
Чтобы узнать цветность, надо открыть файл, и загрузить хотя бы его заголовок.


Зачем? Я же рассматривал вариант, при котором сканы изначально сортируются по цветности. Т. е. мы знаем, что в определенной папке лежат, допустим, только черно-белые страницы в формате TIFF G4. А как уж они получены (в черно-белом режиме или смешанном) -- не важно.



Автор: monday2000
Дата сообщения: 05.02.2010 12:59
anagnost96

Цитата:
Абсолютно неудобно: десятки гигабайт на диске забиваются впустую.

Но это же только на время сканобработки.

Цитата:
Вот, StanFreeWare только что подтвердил: если размеры маски не делятся без остатка на соответствующие размеры фона, ничего работать не будет.

Что-то я не понимаю. Если выводить оба субскана в СТА с одинаковым DPI и пиксельными размерами - то никаких таких проблем не возникнет (потом с DjVu Imager).

Почему они возникают у Вас - мне тоже непонятно. Допустим, Вы выводите в СТА передние субсканы с 600 dpi - а задние с 300 dpi. В таком случае, пиксельные размеры переднего субскана (как я понимаю) должны быть кратны пиксельным размерам заднего субскана - т.к. оба субскана производятся из одного и того же скана.

Цитата:
Отсюда и отсутствие заинтересованности в автоматической раскладке по папкам.

Значит, Вы вручную забираете сейчас из out по-очереди те или иные субсканы. Вручную - это не очень удобно.

Цитата:
А как уж они получены (в черно-белом режиме или смешанном) -- не важно.

А как тогда различать "только изображения" и "цветное/серое" только по цветности?

Добавлено:
StanFreeWare

Цитата:
Попробуйте загнать изображения с некратными чб части размерами в Djvu Imager.

А он вообще рассчитан исключительно на равные DPI и пиксельные размеры. То, что у Вас получилось ещё и с кратными размерами - чистая случайность.
Автор: Dashout
Дата сообщения: 05.02.2010 13:23
monday2000
Вы доминируете в этой теме
Эта тема по СТ - ее просматривают много людей, в том числе и уже поблагодаривших автора за сделанную работу.

Цитата:
СТ в чистом виде никуда не годится

Это не корректное заявление
Вы же ставите множество людей с форума в неловкое положение.
Спорить и препираться с Вами, либо промолчать.
Промолчал - вроде как бы согласился. Но ведь это не так!
Предложили 1 раз автору - он промолчал - значит, не считает нужным.
Никто никому ничего не должен.
Прошу Вас подоброжелательней... Не надо агрессии.
Автор: StanFreeWare
Дата сообщения: 05.02.2010 13:26

Цитата:
должны быть кратны пиксельным размерам заднего субскана

Возможно, из-за использования, например, на 5м этапе непиксельной системы координат при выводе с разным разрешением пикселы округляются в разные стороны.
Автор: LazyKent
Дата сообщения: 05.02.2010 13:40
Присоединяюсь к мнению Dashout.
Автор: monday2000
Дата сообщения: 05.02.2010 14:11
Dashout

Цитата:
Это не корректное заявление

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

Цитата:
Вы доминируете в этой теме

Ну доминируйте и Вы - кто Вам-то не даёт? (Правда, с таким стилем речивот это ещё хлеще) - мягко говоря, вызывающим сильнейшие отрицательные эмоции (правила форума не позволяют мне прямо сказать, что я об этом думаю), ИМХО вряд ли получится ).

Цитата:
Предложили 1 раз автору - он промолчал - значит, не считает нужным.

Я же уже говорил: цель моей критики порой - не побудить Tulon исправить критикуемое, а просто выявить наличие такого-то недостатка в СТ. Хочет Tulon - пусть исправляет, не хочет - найдётся в будущем какой-нибудь Tulon-2 - который учтёт ошибки Tulon и сделает некий "СТ-2".

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

Интересы DjVu-книгосканирования превыше всего - в частности, чьих-то ущемлённых амбиций и самолюбий.

Добавлено:
StanFreeWare

Цитата:
при выводе с разным разрешением пикселы округляются в разные стороны.

Ну вот, ещё один довод в пользу вывода субсканов с одинаковым DPI и пискельными размерами.

Да, я согласен - такой подход приводит к завышенному потреблению дискового пространства - зато это даёт наибольшую простоту на входе в DjVu Imager. Равенство DPI-пиксельных размеров обоих субсканов можно проверить хоть даже "вручную" (посмотреть на вкладке файла "Свойства" по правой кнопке мыши). К тому же, так будет гораздо легче объяснить массовому пользователю, что же такое "разделённые сканы", каким критериям они должны удовлетворять. Ведь найдётся кто-то, кто будет делать разделённые сканы и ни в СТ, и ни в СК - а в каком-нибудь Gimp'е.

Добавлено:
Помню, когда я предлагал bolega "разбить" СК на ряд простейших программ, он мне ответил, что обычному пользователю будет весьма сложно объяснить, что у него должно будет получаться в конце каждого промежуточного этапа, каким однозначно-чётким критериям должна будет отвечать продукция каждого этапа. Здесь как раз именно такой случай.

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172

Предыдущая тема: Невозможно установить Acronis True Image Home v10.0.4940


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