» Scan Tailor

Мда, похоже я мало чего понял. Как-нить позднее изучу подробнее.
1. Очередной нюанс. Судя по комментариям даже в этой теме о Tif, проблема возможно даже не в ST, но...
после вывода в "Смешанном" (надо сказать другого я ещё не использовал), полученные тифы FineReader отказался принимать. Пришлось прогонять их в Irfan. После этого FR их принял, ну и обработал.
2. Есть ещё 1 глюк. 4 файла из проекта ST вывел как пустой лист. К сожалению пока не могу дать образец (он на работе) такого файла, т.к. я умудрился после работы сломать флешку. Образец скину в понедельник.

Цитата:

1. Очередной нюанс. Судя по комментариям даже в этой теме о Tif, проблема возможно даже не в ST, но...
после вывода в "Смешанном" (надо сказать другого я ещё не использовал), полученные тифы FineReader отказался принимать. Пришлось прогонять их в Irfan. После этого FR их принял, ну и обработал.

А чего он сказал-то хоть? Если ничего вразумительного, тогда шлите то что выдал СТ и то что выдал Irfan.


Цитата:

2. Есть ещё 1 глюк. 4 файла из проекта ST вывел как пустой лист. К сожалению пока не могу дать образец (он на работе) такого файла, т.к. я умудрился после работы сломать флешку. Образец скину в понедельник.

OK, в понедельник так в понедельник.

Пока что не прочитал всю тему.

Немного попробовал пока как пользователь, результат отписал вот здесь:
http://forum.ru-board.com/topic.cgi?forum=93&topic=1624&start=1600#2

Добавлено:
Ещё мысли по сегодняшнему практическому использованию разработки: как я понимаю многопоточный режим уже реализован так как при выполнении алгоритмов интерфейс не подвисает. Хотелось бы запускать несколько потокков обработки по числу ядер процессора, так как операции например бинаризации достаточно долгие (особенно с преобразованием 300->600 dpi)

Цитата:

как я понимаю многопоточный режим уже реализован так как при выполнении алгоритмов интерфейс не подвисает

Многопоточность имеется, но параллельной обработки изображений нет. Сейчас СТ использует 4 потока:
1. Главный поток, на котором крутится интерфейс пользователя.
2. Поток обработки изображений. Тут делаются все тяжелые операции по анализу и обработке изображений.
3. Поток подгрузки миниатюр (thumbnails).
4. Поток высококачественного антиалиазинга. Тут делается высококачественная версия изображения, которая появляется с некоторой задержкой (это все относиться только к бета версиям - в релизе 0.9.1 такого еще не было).

Сделать параллельную обработку изображений в принципе возможно, но не думаю что оно того стоит. Дело в том, что обработка изображений, особенно при 600 DPI требует дофига памяти, и если запустить несколько таких операций параллельно, то начнется свопинг, что убьет производительность.

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

Мне такой подход (про память) не кажется верным.

Достаточно сделать диалог настроек в котором хранить параметры. И дать пользователю свободу выбора. Я смотрел сколько жрало памяти на момент обработки - было что-то около 70 мб. Это при 3 гб из всего 4х свободных-то. Да и на 1 гб ОЗУ проблем быть не должно. То есть дать возможность выбора и всё ок. Получить ускорение в 2 (4) практически раза на большом числе файлов в пакете - весьма неплохо.

То есть в одном потоке скажем будет запущена обработка с 1 по n/2, а в другом с n/2+1 до n , ну и ли чёт/нечет что было бы удобнее (можно сразу начинать листать результат)

Цитата:

Достаточно сделать диалог настроек в котором хранить параметры. И дать пользователю свободу выбора. Я смотрел сколько жрало памяти на момент обработки - было что-то около 70 мб.

А вы попробуйте режим вывода Mixed (Смешанный) и цветной скан на 600 DPI (вывод тоже 600) - будет несколько сотен мегов.

Тут ведь дело не только в том, что мне сомнительна полезность всего этого - реализовать это тоже не так уж и просто.

Даже если и несколько сотен.

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

Банальный пробег по QList в цикле (опять же, не знаю как у вас там всё конкретно организовано).

Я тут недавно "кодил" перцептрон в качестве лабы с примерами, там использовал класс QList в качестве структуры данных для хранения примеров обучения нейросети. В элементах листа хранились указатели на объекты типа Struct производного от QObject, который описывал каждый пример нейросети (картинка, оцифрованые данные, нормализованые данные). ДУмаю что здесь должно быть что-то похожее.

Вообще... хм. Хорошо бы документировать код, в каком файле какой объект за что отвечает, какие методы и так далее. Да-да, я знаю что это самое нелюбимое у программистов Ещё была бы полезна система типа trac, то что я вижу на SF мне не очень нравится. Да и всяко удобнее чем реквестить фичи и давать багфиксы на форумах =)

Tulon

Цитата:

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

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

Цитата:

Бинаризованные области DJVU вряд-ли перепутает c картинками, а вот на картинках он может найти буквы, и соответственно не станет их размазывать.

Тоже вариант. Правда, тут ИМХО небольшой минус в том, что надо суметь грамотно обработать исходный скан - чтобы DjVu-кодировщик всё понял именно так, как мы хотели ему сказать. С sep-файлами проще - явно указал Picture-зоны - и привет.
Мне кажется, что в любом случае нужно в будущем суметь реализовать автоматическое распознавание контура полутоновых картинок на сканах. И вручную подправлять найденный контур - примерно так, как это делается в Файнридере. И тогда уже по-разному обрабатывать текст и картинки - а то, что получилось на выходе, желающие пусть кодируют то ли через documenttodjvu, то ли через csepdjvu - кому что больше нравится.

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

Цитата:

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

Банальный пробег по QList в цикле (опять же, не знаю как у вас там всё конкретно организовано).

Вашими бы устами да мед пить. На самом деле все гораздо сложнее. Если я начну описывать как оно работает и что придется менять, на это у меня уйдет не меньше часа. Но если хотите сами разобраться, копайте в следующих направлениях:
MainWindow::loadImage()
MainWindow::filterResult()
WorkerThread
BackgroundTask и его подклассы

WorkerThread нужно превращать в WorkerPool (чтобы был не один поток, а целый набор таковых). Кстати лучше всего делать пул потоков не на основе WorkerThread, а на основе BackgroundExecutor. По хорошему надо переводить все вспомогательные потоки на BackgroundExecutor, а то сейчас каждый имеет свой собственный велосипед. BackgroundExecutor - один из таких велосипедов, но он сделан максимально не зависящим от задачи.
Потом нужно будет изменить логику пакетной обработки "обработали страницу - начинаем слудующую".
И подумать над механизмом отмены заданий (текущий работает только с одним заданием), и подумать, как будет себя вести лента предпросмотра в условиях нескольких одновременных задач. Не хотим же мы скакать вперед-назад после завершения обработки той или иной страницы тем или иным потоком.
В общем работы там хватает - это вам не лабораторная на 500 строк.


Цитата:

Вообще... хм. Хорошо бы документировать код, в каком файле какой объект за что отвечает, какие методы и так далее. Да-да, я знаю что это самое нелюбимое у программистов Ещё была бы полезна система типа trac, то что я вижу на SF мне не очень нравится. Да и всяко удобнее чем реквестить фичи и давать багфиксы на форумах =)

Документировать все про все у меня не хватает терпения и силы воли. Я стараюсь документировать API кода, который написан с прицелом на повторное использование. А документацию в стиле обзора мне вообще никогда писать не приходилось.
А Trac Sourcforge предоставляет всем желающим проектам, вот только я сомневаюсь, что его кто-либо будет использовать.

Добавлено:
monday2000

Цитата:

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

Ну, пока что я не услышал ни одного сообщения о том, что растровое авто-выделение где-то ошибалось. И пока не услышу - пальцем не пошевелю в направлении Picture Zones или автовыделения контуров.


Цитата:

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

Тогда уж лучше просто реализовать кодирование в DJVU прямо из СТ. Но это дело далекого будущего.

> Но вообще-то вот это маленькое окошечко при старте смотрится исключительно нехорошо. Думаю, так скажут практически все пользователи. Неужели Вы действительно считаете, что найдётся хотя бы один пользователь, который не догадается, что ему нужно нажать на File -> Open File(s) после открытия программы?

Согласен. Интерфейс стартовый требует переработки + добавление/удаление сканов в уже готовый проект.

Например начал я сканить книжку (а так и есть). Прогнал то что уже отсканировано. Хочу добавить ещё файлов а НЕ МОГУ. ПРиходится начинать заново.

Ну и окошко на старте смотрится нехорошо.

Про много кода ясно, я пытаюсь его понять. Многое мне кажется велосипедным, но я отдаю себе отчёт в том что сам бы написал наверное ещё хуже :-D

Цитата:

Ну и окошко на старте смотрится нехорошо.

А кто говорил, что оно смотриться хорошо? По хорошему оно должно быть похожим на splash screen - без оконного заголовка, c большим логотипом, со списком недавних проектов. Типа Nero Smart Start. А существует оно по двум причинам (более подробно это описано на сайте в разделе "Предложенные улучшения"):
1. Оно удобно, причем и для новичков, и для опытных пользователей.
2. Оно позволило так сказать срезать угол в процессе разработки - считать, что список файлов известен заранее.


Цитата:

Например начал я сканить книжку (а так и есть). Прогнал то что уже отсканировано. Хочу добавить ещё файлов а НЕ МОГУ. ПРиходится начинать заново.

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

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

Ну, я почитал в ранних страницах темы про Nero Smart Start... Скажу так: я им никогда не пользовался и не понимал, зачем он вообще нужен :-D

Цитата:

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

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


Цитата:

Ну, я почитал в ранних страницах темы про Nero Smart Start... Скажу так: я им никогда не пользовался и не понимал, зачем он вообще нужен :-D

Пока туда не добавили Smart Start, Nero был весьма неудобной программой. Нужно записать исошку или стереть CD-RW - приходилось искать соответствующие пункты в меню. А со Smart Start - основные действия как на ладони.

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

Как я понимаю, на таких страницах нужно применять алгоритм "смешаный" для получения нормальных "серых" картинок?

Явно чувствуется нехватка отключениея/включения сглаживания масштабирования. Например хочется посмотреть на ровность буковок в масштабе 1:1 (писал по почте), но я не могу эту ровность оценить, потому что то сильно увеличиваю, то сильно уменьшаю, а сглаживание скрывает от меня артефакты бинаризации.
Я конечно понимаю что в папке out только что просмотреная картинка уже лежит, но лезть туда и запускать стороннюю программу чтобы быстро посмотреть на результат - банально неудобно.

Цитата:

Правая страница - выбрана вся страница в качестве полезного блока. Видимо алгоритм сводит с ума сильное затемнение разворота, но сосканить иначе - нереально.

Нормализация освещения уже реализована для вывода, и на этапе Select Content она тоже рано или поздно появится.


Цитата:

Как я понимаю, на таких страницах нужно применять алгоритм "смешаный" для получения нормальных "серых" картинок?

Правильно понимаете.


Цитата:

Явно чувствуется нехватка отключениея/включения сглаживания масштабирования. Например хочется посмотреть на ровность буковок в масштабе 1:1 (писал по почте), но я не могу эту ровность оценить, потому что то сильно увеличиваю, то сильно уменьшаю, а сглаживание скрывает от меня артефакты бинаризации.

А вот сделать отключение сглаживания по хоткею - задача пустяковая. Можете попробовать реализовать это сами. Выбор того, какую версию отображать - оригинальную или сглаженную, контролируется простым if'ом в функции paintEvent() в файле ImageViewBase.cpp. Надо просто добавить в этот класс перехват нажатий клавиш, и при нажатии скажем на Tab выставлять флаг, который запретит антиалиазинг, после чего делать update(). И при отпускании то же самое - только флаг сбрасывается.

Tulon

Цитата:

И пока не услышу - пальцем не пошевелю в направлении Picture Zones или автовыделения контуров.

Да я и не имею в виду, чтобы это реализовывать именно в СТ. Разве что в отдалённом будущем. Это я просто сам с собою рассуждаю - как бы ещё дальше развить МРС.

Добавлено:
Arceny

Цитата:

нас так учили на ТРПО (теория разработки ПО)

Если Вы занимаетесь программированием - то как Вам идея написания алгоритмов сканобработки? Если Вы заметили, то я уже успел несколько сделать - вот они:

http://www.djvu-soft.narod.ru/bookscanlib/project.htm

Не хотите ли заняться аналогичным занятием? Для этого достаточно избрать себе какую-нибудь программную библиотеку для работы с растровой графикой - и писать на её базе консольные программы-алгоритмы. Смысл - создать общую для всех библиотеку скан-алгоритмов.

Цитата:

Если Вы занимаетесь программированием - то как Вам идея написания алгоритмов сканобработки?

Уж лучше пусть прямо над СТ поработает. Если уж разрабатывать алгоритмы обработки изображений, то не абы какие, а именно те, которые в данный момент нужны. Например проблема бинаризации в СТ на данный момент полностью решена. Выравнивание освещения + Otsu дают оптимальный результат. Я даже планирую убрать выбор алгоритма бинаризации, разве что кто-нибудь представит мне примеры, где другой алгоритм дает лучшие результаты.

А вот например сейчас мне не помешал бы алгоритм обнаружения текста. Особая точность там не требуется. Нужен он мне для связки с новым алгоритмом выделения рамки контента. Этот новый алгоритм (его еще нет в SVN) прекрасно справляется с мусором по краям, но так и норовит отрезать заголовок или номер страницы. Советы вроде погуглить на такую-то тему не принимаются - уже погуглил, много чего нашел, кое-что уже реализовал.

Tulon

Цитата:

Если уж разрабатывать алгоритмы обработки изображений, то не абы какие, а именно те, которые в данный момент нужны.

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

Цитата:

Потому что в будущем возможны иные альтернативы СК - помимо СТ.

Каждая новая альтернатива, если конечно ей можно пользоваться, уменьшает вероятность появления дальнейших альтернатив, в особенности если эта альтернатива с открытыми исходниками. Взять например LibTIFF - ужасная гадость, если использовать ее напрямую. И тем не менее альтернатив с открытыми исходниками ей нет. Есль всякие обертки, тот же FreeImage например, которые пытаются привести LibTIFF к нормальному API. Можно многое списать на почтенный возраст этой библиотеки - но факт остается фактом - никто не хочет писать ей альтернативу, потому что проще помучаться некоторое время с LibTIFF, чем написать ей замену. А вот если бы не появилась эта библиотека в свое время, то уже давно кто-нибудь написал бы нормальную ее реализацию.
В общем не ждите альтернатив СК и СТ. Создание такой альтернативы требует огромного вложения усилий и времени, и наличие десятка-другого алгоритмов бинаризации, вращения и масштабирования погоды вовсе не сделают.

Tulon

Цитата:

если конечно ей можно пользоваться

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

Цитата:

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

Извините - не согласен. Как раз наоборот - иной раз и один-единственный, но удачный алгоритм, способен радикально изменить дело. Пример - BookRestorer - программа нам нужна всего лишь ради 3 алгоритмов.

Цитата:

Создание такой альтернативы требует огромного вложения усилий и времени

Это сейчас. Но эту ситуацию можно изменить. Нужно просто делать программные компоненты - документированную библиотеку алгоритмов в виде dll и т.п. И тогда проблема создания альтернативы СК сведётся к задаче написания обычной программы - что под силу многим и многим рядовым программистам. Например, представьте, если бы не было библиотеки FreeImage - то не появилась бы DjVu Sep, и Bookscanlib тоже. Конечно, начни я сам городить с нуля аналог FreeImage (которая развивается усилиями десятков людей уже более 6 лет) - то задача создания DjVu Sep выглядела бы колоссально сложной. А так я без особых напрягов за какой-то месяц-другой её нарисовал.
Точно так же будет и с СК-альтернативами.

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

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

И вообще - библиотека алгоритмов нужна нам не только ради создания альтернативы СК. Наверняка будут ещё и прочие программы, имеющие дело со сканами - и им могут потребоваться какие-то алгоритмы.

Альтернатив СК не было создано до сих пор именно из-за отсутствия вышеупомянутых программных компонентов.

Я потому и предлагаю всем желающим поучаствовать в написании библиотеки алгоритмов - потому что эта деятельность доступна (по уровню сложности) практически каждому умеющему программировать, а смысл и эффект получаются общими.

Добавлено:
Tulon

Цитата:

В общем не ждите альтернатив СК и СТ.

Есть вроде какая-то ещё альтернатива СК - известная только bolega. Он где-то скриншот выложил - какой-то там "ScanMagic", что ли (или "MagicScan").

Цитата:

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

Значит пользоваться нельзя, потому что нет хэлпа и не нравиться окно, которое появляется только при старте? Я бы еще понял, если в качестве аргументов вы бы привели невозможность добавить / удалить файл из проекта или скажем отсутствие возможности вручную выделить зону картинки, но ваши аргументы просто смехотворны. СТ без хелпа освоить проще, чем СК с хелпом.


Цитата:

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

Извините - не согласен. Как раз наоборот - иной раз и один-единственный, но удачный алгоритм, способен радикально изменить дело. Пример - BookRestorer - программа нам нужна всего лишь ради 3 алгоритмов.

Я не о том. Я имел в виду, что альтернатива СТ или СК - это десятки тысяч строк кода, и вращение, масштабирование и бинаризация являются каплей в море. Приведу статистику по СТ. Там имеется директория imageproc, в которой собраны алгоритмы обработки изображений, структуры данных, и все что с этим связанно и пригодно для повторного использования. В других директориях есть еще две-три тысячи строк кода обработки изображений, который жестко привязан к СТ. Погоды они не делают.
Так вот, на данный момент мы имеем:
imageproc: 22 тысячи строк
все остальное: 36 тысяч строк
То есть видите, даже если бы у вас была библиотека алгоритмов, в которой есть все что нужно, все равно пришлось бы написать десятки тысяч строк кода, чтобы создать альтернативу СК или СТ.

Кстати может bolega поделится статистикой по СК?


Цитата:

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

И получилось бы что-то вроде unpaper - есть такая консольная прога как раз для наших целей. Совершенно непригодная к использованию надо скадать - как по функциональности, так и по удобству.


Цитата:

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

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

Цитата:

СканТэйлором с моей точки зрения пользоваться "нельзя" - т.е. достаточно затруднено

Категорически не согласен. Может в моем случае сказался опыт в книгопроизводстве в целом и работы в SK в частности. Не спорю. Но на данный момент СТ реально прост. Думаю, что потом он будет сложнее. Я даже надеюсь на это. В плане гибкости настроек. А вот эргономичность их внесения - это уже будет важной задачей для разработчика. Пока он делает это великолепно.

Цитата:

СТ без хелпа освоить проще, чем СК с хелпом.

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

Цитата:

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

Tulon, лично я обе эти функции жду с нетерпением. Ценность программы возрастет на 2 головы!

Tulon

Цитата:

Значит пользоваться нельзя, потому что нет хэлпа и не нравиться окно, которое появляется только при старте?

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

Цитата:

но ваши аргументы просто смехотворны.

Жизнь покажет. Кстати, не один я так считаю.
Объективная реальность не зависит от наших мнений и желаний. Вопрос лишь в том, насколько полно мы желаем удовлетворить запросы этой реальности (довольно жёсткие, кстати). И те, кто не желает с этим считаться - обречены на неуспех.

Цитата:

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

Не поленюсь повторить уже сказанное: существует понятие "модульность кода". Эти десятки тысяч строк возможно разбить на модули - удобные в повторном использовании.
Да, сложность после этого не исчезнет вовсе - но она уменьшится настолько, что многие программисты-одиночки смогут делать такие программы. Сейчас же они пока ещё не могут - пока нет таких модулей - порог сложности ещё велик. Модули нужны ИМХО такие (к примеру):
1. Bookscanlib - вполне можно сделать в виде dll с простым и удобным для чайника API. Туда должны войти 2 части - сканобработка - и распознавание образов.
2. Графический движок. Можно оформить как готовый MFC-класс - подключаемый в виде dll с простым и удобным для чайника API. Да, сложновато такое сотворить - но можно.
3. FreeImage - уже есть.

Этих 3 компонентов будет достаточно, чтобы довести сложность создания альтернативы до принципиального уровня сложности, скажем, DjVu Sep или DjVu Small. Это всё равно, что собирать нечто из Lego-конструктора (а не самому обжигать кирпичи из глины и т.д.).

Вы читали PDF-инструкцию к FreeImage? Если нет - то многое потеряли. Это ярчайший пример того, как можно (при желании) свести сложное к простому. Мне всё равно, сколько там внутри FreeImage строк кода - тысяча или миллион - я работаю там всего лишь с несколькими дясятками простых, понятных, и удобных функций.

Тем более, что функциональность СК надо разбить на 3-4 независимые программы - а Вы наступаете на те же грабли, что и bolega - всё лепите в одну и ту же программу.

Цитата:

Кстати может bolega поделится статистикой по СК?

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

Кстати - предлагаемая мною модель (модульность) заодно навсегда покончит с опасностью монополизации технологий сканобработки теми или иными лицами (что мы наблюдаем сейчас).

denver 22

Цитата:

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

Tulon, лично я обе эти функции жду с нетерпением. Ценность программы возрастет на 2 головы!

Редактирование списка файлов в проекте - приоритетная задача, уступающая только доведению до ума автовыделения рамки контента. А вот что касается ручного выделения картинок - сначала дайте пример, где автовыделение лажает.

monday2000

Цитата:

Не поленюсь повторить уже сказанное: существует понятие "модульность кода". Эти десятки тысяч строк возможно разбить на модули - удобные в повторном использовании.
Да, сложность после этого не исчезнет вовсе - но она уменьшится настолько, что многие программисты-одиночки смогут делать такие программы. Сейчас же они пока ещё не могут - пока нет таких модулей - порог сложности ещё велик. Модули нужны ИМХО такие (к примеру):
1. Bookscanlib - вполне можно сделать в виде dll с простым и удобным для чайника API. Туда должны войти 2 части - сканобработка - и распознавание образов.

imageproc


Цитата:

2. Графический движок. Можно оформить как готовый MFC-класс - подключаемый в виде dll с простым и удобным для чайника API. Да, сложновато такое сотворить - но можно.

Qt, в частности QPainter.


Цитата:

3. FreeImage - уже есть.

Qt плюс классы TiffReader, TiffWriter, ImageMetadataLoader, TiffMetadataLoader, PngMetadataLoader, JpegMetadataLoader. Эти классы в сумме дают 1480 строк. Они не в imageproc (хотя TiffReader и TiffWriter не привязаны к СТ - могли бы быть в imageproc), так что вычтем эти полторы тысячи строк из тех 36 тысяч. А за остальные 34 с половиной вы никак на отчитались. В общем никакая модульность не понизит сложность разработки ниже нескольких десятков тысяч строк. Кстати, а поддерживает FreeImage многостраничные TIFFы? Нет? Тогда класс TiffReader вам всетаки придется написать. А поддерживает считывание ширины / выстоты и DPI из файла, не загружая его целиком? Тоже нет? Тогда и все *MetadataLoader вам тоже понадобятся. В общем программирование это не сборка конструктора Lego.


Цитата:

Цитата:
Кстати может bolega поделится статистикой по СК?

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

Ну, поделиться статистикой это ему никак не может помешать. Разве что там сильно мало строк, что сомнительно.


Цитата:

Кстати - предлагаемая мною модель (модульность) заодно навсегда покончит с опасностью монополизации технологий сканобработки теми или иными лицами (что мы наблюдаем сейчас).

А почему это "теми или иными" во множественном числе?
Ко мне это не относиться. Исходники открыты, я даже готов объяснить непонятные места, если кто попросит. Кроме того, imageproc нисколько не зависит от СТ - отодрать его от СТ не составляет проблемы. К Qt он правда привязян, но не более чем ваши алгоритмы привязаны к FreeImage.

О приоритетной задаче - это хорошо.
Выделение картинок на моих 2-3 проектах пока не "лажали". Но мало ли... Да и мысль все таки осталась об использовании DjVu Sep. Хотя её я и в проектах SK ещё не тестировал. Хотя эту идею тут уже вроде успели раскритиковать.
Tulon, в личку скинул материал с проблемными местами. Надеюсь найдешь с его помощью баги. А то мне ничего другого не оставалось, как необрабатываемые в СТ сканы доработать в СК.

denver 22
Ответил в личку.
Походу ru-board не умеет оповещать о личных сообщениях, или я чего пропустил?

Tulon
Умеет, поищите в настройках (будет выскакивать окошко, когда вы открываете/обновляете закладки).

Добавлено:
denver 22

Цитата:

Да и мысль все таки осталась об использовании DjVu Sep. Хотя её я и в проектах SK ещё не тестировал. Хотя эту идею тут уже вроде успели раскритиковать.

Метод нормальный, правда я предпочитаю кодировать книги с картинками в DEE - я выкладывал профиль, который у меня нормально работает. А вот для кодирования методом разделенных сканов лучше использовать FSDv1.2. За DjVu Sep не ручаюсь - monday2000 сильно мудрил с методом разделенных сканов.

В IE у меня сообщение выскакивало. В FireFox в верхней шапке появляется анимированное сообщение. Tulon, значит не зря я заранее оповещал о своих сообщениях?
Arcand, я сейчас как раз и использую те профили кодирования, которые ты мне дал для DEE. При этом в СТ для вывода использую смешанный режим. А в СК - "Zone – Picture zone – Merge zones...".
Я лишь хотел посмотреть какие результаты будет давать метод разделенных сканов. FSDv1.2 - это что за программа?

Arcand

Цитата:

За DjVu Sep не ручаюсь - monday2000 сильно мудрил с методом разделенных сканов.

Зато я ручаюсь. Если что не так - давайте конкретные примеры. А голословно обвинять - нехорошо.

Цитата:

А вот для кодирования методом разделенных сканов лучше использовать FSDv1.2.

FSD v1.2 - это принципиально одно и то же, что и DjVu Sep. Разница только в интерфейсе. И FSD v1.2, и DjVu Sep построены на Вашем с manfred исходнике pnmtodjvurle.

Tulon

Цитата:

imageproc

Что это такое? Библиотека алгоритмов?

Цитата:

Qt, в частности QPainter.

Почему же в СканТейлоре нет скроллбаров? Они что, не поддерживаются этим QPainter? А экранное сглаживание в QPainter есть?

Цитата:

Кстати, а поддерживает FreeImage многостраничные TIFFы?

Да. И метаданные тифа тоже.

Цитата:

А поддерживает считывание ширины / выстоты и DPI из файла, не загружая его целиком?

Кажется, нет. Точно не могу сказать - надо узнавать. Даже если и нет - то это можно реализовать (обкорнать существующий там класс я и сам смогу) - и просто ввести в FreeImage дополнительную функцию.

Цитата:

А за остальные 34 с половиной вы никак на отчитались.

А что они делают? Может, и там можно что-то в модули упаковать?

Цитата:

В общем никакая модульность не понизит сложность разработки ниже нескольких десятков тысяч строк.

"Большой размер" это не всегда синоним понятия "сложность". Программа может быть большой - но состоять из относительно простых типовых элементов - и наоборот. Если эти "десятки тысяч строк" состоят из типовых конструкций Qt (или MFC) - то это относительно не так уж страшно. Страшно - это когда нужен, например, компонент-графический движок - а его нет. Даже если он и в пределах тысячи строк.

Цитата:

FSDv1.2 - это что за программа?

GUI для msepdjvu от manfred