Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » Scan Tailor

Модерирует : gyra, Maz

Widok (17-02-2010 12:17): Лимит страниц. Продолжаем здесь.  Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107

   

Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Scan Tailor

 
Скриншот:

В разработке находится новая альтернатива СканКромсатору. Разработчик - ваш покорный слуга.
Задача программы - пост-обработка сырых сканов с целью их последующей сборки в PDF или DJVU.
 
Уже есть на что посмотреть, и возможно присоединиться к проекту. Проект с открытыми исходниками и кросс-платформенный (Windows + Linux).
 
По сравнению со СканКромсатором планируется большее удобство использования, большая интерактивность, но при этом не меньшая автоматизация процесса.
 
Сайт проекта: http://scantailor.sf.net     Скриншоты
 
Топик программы на форуме Натахаус       Англоязычный топик по ScanTailor

Документация
 
Документация (Wiki)              Зоны картинок в ScanTailor
 
Статья: Scan Tailor. Программа для обработки отсканированных книг
 
Видеоурок: Создание DjVu с помощью Scan Tailor (зеркало)
 
Методика использования STA совместно с Djvu Imager

Дистрибутивы
 
Версия СТ с функцией выпрямления искривленных строк (dewarp от Rob)
 
Патч от anagnost96 Вариант ScanTailor с этим патчем (STA)  Зеркало
 
ScanTailor для Mac
 
Последние изменения в дереве исходников - для сильно любопытных и владеющих английским.
Там же можно подписаться на rss/atom - для нетерпеливых.
 

Дополнительно
 
ST GreyText v1.0 Программа для генерации вывода как бы "Только текст (в режиме серого)" - для Scan Tailor от anagnost96.
 
LayerTailor Программа для разделения сканов (после "Смешанный режим) на foreground и background слои с целью последующего раздельного кодирования в djvu. Принцип работы: Все черные пиксели (яркость==0) переносятся в foreground, остальное - в background. Функция layer принимает на входе 3 параметра: исходное имя файла TIFF, имя файла для foreground и имя файла background. Автор: U235.
 
Предложения к anagnost96 по поводу улучшения его модификации СТ
Сравнение выпрямления искривленных строк в СТ и в BR

Статья О возможности альтернативы СканКромсатору     Полезные ссылки по теме топика
ArtScan - ещё одна программа для сканобработки.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 21:37 15-06-2008 | Исправлено: ndch, 22:37 12-02-2010
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Хорошо, с этой функцией все ясно - ей передаются неправильные параметры.
Если конкретнее, то sr (область исходной картинки для рисования) на один пиксель вылазит за пределы этой самой картинки (img.size()).  Значит причина где-то выше в цепочке вызовов.  Будем искать.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 09:58 19-07-2009
dma200899

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Надо дальше присылать ? Это пока все тот же проект:
 
 
pt: (902.587, 50)
img.bits(): 0x56f49d8
img.size(): 23x17
clip: (747, 52), 250x96
sr: (0, 2), 23x16
alpha: 256
x: 903, y = 52
iw: 23, ih = 14
srcBits: 0x56f4b48
srcBytesPerPixel: 4
srcBPL: 92
rasterBuffer->buffer(): 0x3330000
rasterBuffer adjusted: 0x3364e1c
rasterBuffer->size(): 1024x719
dstBytesPerPixel: 4
dstBPL: 4096
 
Добавлено:
pt: (902.587, 50)
img.bits(): 0x5f0d9e0
img.size(): 23x17
clip: (747, 52), 250x96
sr: (0, 2), 23x16
alpha: 256
x: 903, y = 52
iw: 23, ih = 14
srcBits: 0x5f0db50
srcBytesPerPixel: 4
srcBPL: 92
rasterBuffer->buffer(): 0x3330000
rasterBuffer adjusted: 0x3364e1c
rasterBuffer->size(): 1024x719
dstBytesPerPixel: 4
dstBPL: 4096

Всего записей: 126 | Зарегистр. 29-06-2008 | Отправлено: 11:59 19-07-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Больше не надо присылать - уже все ясно.  Напишу сегодня баг репорт Qt'шникам, а в своей сборке сам исправлю, чтобы их не ждать.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 12:22 19-07-2009
dma200899

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Я вынашиваю мысль совсем от них (от ID) отказаться.

Нет, не стоит.
Например, я делаю проект из двух папок ч/б и цветные сканы. В каждой папке своя нумерация и вид имен файлов. Сейчас всё ясно. ID имя 1, ID имя 2.
Если вы ID уберете, я запутаюсь.
 
Я вообще-то про другое писал. Чтобы имя, которое пишется в ленте предпросмотра, соответствовало имени, которое имеет выходной файл.  
Сейчас у вас картинки в ленте именуются как "имя 1", а файлы "ID имя 1". Пусть у картинок в ленте имя будет тоже "ID имя 1".
Только ID недостаточно, но только "имя 1" точно также недостаточно.
 
Если вы опасаетесь проблемы смены имен при перегенерации выходных файлов, то если такая ситуация есть, то, если выходной файл уже сгененрирован, то менять имя на новое (с учетом переразрезки страниц и сдвига ID) стоит в момент генерации нового выходного файла. Или автоматически переименовывать уже сгенерированные файлы.
 
Временно иметь два одинаковых ID не страшно, если они по имени начального файла различаются. Если же сдвиг на единичку идет, то можно в имя файла дописывать _L и _R. Но отказываться от ID совсем - нельзя.
 
Добавлено:
Кроме того, дальше разные файлы Ч/б, серые , цветные я кодирую с разными джву-настройками. И при наличии ID очень удобно.
В одной папке кодируешь постранично первую группу, в другой - другую. Затем делаешь ч/б в один джву-файл (выигрываешь объединенный словарь). А затем вставляешь в него отдельные серые и цветные страницы.
При отсуствии ID все надо поименовать изначально "правильно", т.е. представлять разрезку и очередность сборки. Это не всегда возможно.
Ну или требует несколько раз переименовать все в процессе.
 
Кстати, про проблему сортировки, Вы так ничего и не ответили.
Когда сначала СТ делает сортировку файлов
1
10
11
100
111
 
а при перезагрузке проекта сносит ее нафик
1
10
100
11
111
 
в итоге я теперь такие сканы в СТ больше не пихаю, все привожу к виду
001
010
011
100
 
но первый раз когда я с этим столкнулся было неприятным сюрпризом.
Готовый перепутанный проект сложнее переименовывать, чем начальный неразрезанный.
 
 
Добавлено:
PPS
и про прокрутку мышкой при нажатом контроле вы не ответили

Всего записей: 126 | Зарегистр. 29-06-2008 | Отправлено: 15:18 19-07-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Добавить ID в ленту предпросмотра не сложно, но все равно это не решает проблемы сдвига ID при удалении / добавлении файлов и даже при смене типа разреза.
Да, если просто отказаться от ID, то возникает проблема с одинаковыми именами файлов из разных директорий.  Я уже жалею, что вообще разрешил добавлять в проект файлы из разных директоий.  Это добавляет сложности и туда и сюда, а пользы - практически ноль.
Решение может быть таким: кроме _L и _R добавлять всякие там (1), (2) если такое необходимо.
То, что вы предлагаете, сделать очень и очень непросто.  Нужно помнить, какие исходные файлы были записаны в какие выходные; тоже самое нужно помнить для кэша миниатюр (выходные изображения там тоже кэшируются).  Причем помнить это нужно не просто в памяти, а записывать в проект.  Сплошной гемморой в общем.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 16:00 19-07-2009
dma200899

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
у меня проблемы сдвига ID в общем-то и не было
 
Добавлено:

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

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

Всего записей: 126 | Зарегистр. 29-06-2008 | Отправлено: 16:41 19-07-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Кстати, про проблему сортировки, Вы так ничего и не ответили.

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

Цитата:
у меня проблемы сдвига ID в общем-то и не было  

А у меня не разу не упало, но это ведь не значит, что проблемы нет

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 17:22 19-07-2009
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Tulon
Кромсал я сегодня одну книжку и опять у меня возникли некоторые соображения по СТ.
 
Всё-таки, ИМХО один из принципиальнейших пороков СТ - это жёсткая заданность всего процесса сканобработки.
 
Как я уже говорил ранее - наиболее "идеологически верным" решением этой концептуальной проблемы было бы разделение СТ на несколько независимых программ. Я даже думаю, что подобное разделение следовало бы сделать чуть ли не для каждой из нынешних стадий СТ.
 
А именно, наиболее разумно было бы сделать:
 
- Для "Исправление ориентации" - отдельная, независимая программа.
- Для "Разрезка страниц" - отдельная, независимая программа.
- Для "Компенсация наклона" - отдельная, независимая программа.
 
Вы оба с bolega не понимаете - всё это до такой степени разнородные по смыслу задачи, что их абсолютно нелогично втискивать в одну и ту же программу. Ну не делает же Билл Гейтс гибрид MS Office и MS Excel? Почему-то взамен он делает MS Office, состоящий из набора таких офисных программ.
 
"Исправление ориентации" - это вообще очень редко нужная функциональность. Необходима только для неопытных юзеров - которые часть страниц сканируют "сверху вниз", а часть - "снизу вверх" (и нужно потом индивидуально-вручную поворачивать). Лично я всегда проделываю "Исправление ориентации" в Irfan View - быстро и просто.
 
"Компенсация наклона" - ИМХО также должна быть отделена (в отдельную программу) от "Разрезка страниц" - потому что deskew вообще склонна к ошибкам по своей природе - например, в СК deskew постоянно глючит. Мне попадались случаи, когда даже Файнридер неправильно делал deskew.
 
А главное - раздельность по программам "Компенсация наклона" и "Разрезка страниц" позволит юзеру максимально чисто психологически сконцентрироваться на правильном выполнении текущей (из этих 2-х) операций - не отвлекаясь мысленно на 2-ю из них. Это и есть "принцип конвейера" - "каждый единовременно делает одну простую операцию".
 
Этим мы и достигнем столь вожделенную простоту - которой так не хватает сейчас ни СК, ни СТ.
 
Что касается "Полезная область" и "Макет страницы" - тут вообще разговор отдельный. "Макет страницы" - наиболее вероятно, что тоже надо выделить в отдельную программу. "Полезная область" - быть может, заменить на "Примерная полезная область" (и почти наверняка тоже выделить в отдельную программу). Впрочем, в отношении "Полезная область" и "Макет страницы" ещё нужно много отдельно думать.
 
Почему я так настаиваю именно на наборе простейших программ вместо одной большой гибридной, как сейчас?
 
Тут можно привести такую аналогию: китайский язык. Китайцы вынуждены иметь тысячи иероглифов - потому что у них нет алфавита. И всё равно это косная и убогая языковая система - иероглифов ведь нужны были бы миллионы (но разве их все запомнишь тогда) - чтобы отобразить все краски и тончайшие оттенки смысла.
 
Так и здесь: комбинаций видов сканов и юзеров - великое множество - и всё это никак не втиснешь в некую одну жёсткую схему. Здесь Вы поступаете ещё даже хуже, чем bolega - в СК-то хоть можно сделать "вывод" в любой момент.
 
Если Вы не хотите дробить СТ на отдельные программы (теряя тем самым столь замечательный шанс "обставить" СК) - то хотя бы сделайте возможность "Вывод" после любой из стадий.
 
И, конечно, же - отсутствие скроллбаров в сканобрабатывающей программе - ну это просто дикость какая-то. Казалось бы - разве нужно доказывать целесообразность такой очевидной вещи? Можно, конечно, кушать без ложки и без вилки - и спрашивать при этом - "а зачем они нужны"? Скроллбары нужны просто непременно.
 
И ещё в СТ я не увидел никакой возможности "широкоформатного" просмотра сканов. Панель управления слева и лента эскизов справа сильно скрадывают полезную площадь экрана - на котором можно было бы отображать в бОльшем масштабе текущий скан. Может, сделать их отключаемыми? А панель управления слева как-то уменьшить ещё?
 
Направления зуммирования при вращении колёсика хорошо бы поменять местами - чтобы получилось так, как это принято во всех программах.
 
Невозможность ручного выбора порога бинаризации - выглядит крайне подозрительно. Уж очень сложно поверить, что автоматический алгоритм всегда выберет нужный порог.
 
Одним словом - "я выбираю СканКромсатор". (и это я, который критикую СК больше всех).

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 23:23 19-07-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
monday2000
Для подхода "все в одном" есть пара очень серьезных технических причин.  Самое обидное, что я их уже называл, по моему на этом же форуме, и по моему как раз вам и отвечал - только найти не могу.  Придется еще раз написать.
 
Итак, первая причина: потеря качества.
СТ делает всего одно геометрическое преобразование от исходника к выводу.  Если я сделаю вывод где-нибудь между компенсацией наклона и повышением DPI - будет уже два геометрических преобразования.  Результат - потеря качества.
 
Вторая причина еще более серьезная: потеря важной информации между стадиями.  Пример такой информации - границы исходного изображения после компенсации наклона.  После компенсации наклона либо появляются дополнительные поля (какого интересно цвета они должны по вашему быть?), либо наоборот бока картинки обрезаются.  Обрезать опасно - можно отрезать часть текста.  Значит добавляем поля.  Эти самые поля будут сбивать с толку некоторые алгоритмы СТ.  Что будет если я сделаю вывод на произвольном этапе?  Люди начнут делать там вывод, который потом загрузят обратно в СТ, создавая проблемы для его алгоритмов.  Ну не любит СТ поля искуственного происхождения и все тут.  Я когда вижу скан с такими полями, думаю: ну какого фига такое сделали?  И качество убили (любой поворот - потеря качества), и еще и внесли туда элементы, которых там не было, и которые осложняют обработку.  А вы мне предлагаете, чтобы СТ сам генерил такие сканы на промежуточных этапах.
 
Добавлено:
Но даже если бы не было технических причин, подход СТ все равно более правильный, ИМХО.  Поскольку ошибку на любом этапе можно поправить когда угодно, вам не нужно контролировать результат всех этапов.  Например этапы разрезания страниц и компенсации наклона можно смело пропускать.  Если там были ошибки - заметите их позже и исправите пакой кликов.
 
Добавлено:
Я кстати сегодня убил весь день на написание test-case для этого бага в Qt.  Без test-case Qt'шники его вообще вряд-ли признают багом.  Очень тяжело воспроизвести этот баг - офигетельно тяжело.  У меня он так не разу и не привел к падению, но по крайней мере я добился того, что Valgrind замечает чтение за пределами буффера.  Отправил им баг репорт вместе с test case'ом - будем надеяться исправят.  Кстати исправить его несравнимо проще, чем найти или воспроизвести.  Я и сам могу исправить, только тогда придется это делать для каждого нового релиза Qt.  Кстати Linux'овую версию этот баг вроде не затрагивает.
 
Добавлено:
Шибко умные заметят - если Linux'овая версия не подвержена багу, как же Valgrind (который только под Linux) его замечает?
Замечает, если явно указать Qt'шный програмный растеризатор вместо родного Linux'ового.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 00:15 20-07-2009
estimated



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
monday2000

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

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

Так ведь оно и так как принято: прокрутка вверх -- увеличение, вниз -- уменьшение. Как стандартное поведение, я бы воспринимал увеличение/уменьшение колесом при нажатой клавише Ctrl, как в броузерах.

Цитата:
Невозможность ручного выбора порога бинаризации

Это есть: ползунок Thinner - Thicker на этапе Output. Но лейбл "Порог бинаризации", наверное, не помешал бы. Кстати, заметил, что приходится этот ползунок всегда ставить в крайнее левое положение (Thinner), иначе буквы заметно утолщаются.
 
btw, не помешала бы регулировка Despeckle (например, макс. размер "мусора" в пикселах по отношению к выходному пиксельному размеру скана). Пока приходится ее совсем отключать.
 

Всего записей: 1088 | Зарегистр. 15-02-2002 | Отправлено: 01:21 20-07-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

Сам я считаю это не особо нужным, так что не стоит ждать, что я это реализую.  Я бы на месте monday2000 уже сам бы реализовал эту фичу.  Исходники есть - в чем вопрос?  Qt не знаете?  Ну и что, я тоже до ST его не знал.
 

Цитата:
Так ведь оно и так как принято: прокрутка вверх -- увеличение, вниз -- уменьшение. Как стандартное поведение, я бы воспринимал увеличение/уменьшение колесом при нажатой клавише Ctrl, как в броузерах.  

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

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

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

Цитата:
btw, не помешала бы регулировка Despeckle (например, макс. размер "мусора" в пикселах по отношению к выходному пиксельному размеру скана). Пока приходится ее совсем отключать.  

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

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 02:00 20-07-2009
anagnost96

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Tulon
 

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

 
Ну, например, в GIMP тоже колесико служит для прокрутки, а Ctrl+колесико -- для зуммирования. А GIMP к "нашему делу" уж поближе будет, чем игры.
 

Цитата:
Кроме того, пока не совсем очевидно, что именно надо регулировать.  У алгоритма три параметра - не делать же три ползунка.  

 
А может, можно сделать некий абстрактный параметр специально для GUI, а в зависимости от его значения уже подстраивать все три остальных?

Всего записей: 132 | Зарегистр. 01-05-2009 | Отправлено: 12:26 20-07-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
anagnost96

Цитата:
А может, можно сделать некий абстрактный параметр специально для GUI, а в зависимости от его значения уже подстраивать все три остальных?  

Можно естественно, только кто мне скажет, как именно единый параметр будет влиять на эти три.  Тут нужно экспериментировать, на что у меня пока нет времени.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 00:08 21-07-2009
monday2000

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Tulon

Цитата:
будет уже два геометрических преобразования.

Не увидел я "2-х преобразований". Но даже если они и есть - ИМХО этим можно пренебречь. Не такой уж у нас тут прецезионный процесс.

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

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

Цитата:
Я бы на месте monday2000 уже сам бы реализовал эту фичу.

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

Всего записей: 2841 | Зарегистр. 13-01-2005 | Отправлено: 11:06 22-07-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
dma200899
Проблему с сортировкой я исправил в SVN.  В ближайшие дни исправлю проблемы на стадии Макет Страницы после удаления файлов из проекта.  Случайные падения тоже вроде как исправлены (пришлось патчить Qt).  Может на выходных выпущу новый релиз.
 
Добавлено:
monday2000
Я никакого разделения на мелкие утилиты делать не собираюсь.  Ухудшение качества, умньшение удобства, ухудшение работы автоматических алгоритмов - да еще и куча усилий, которые нужно приложить, чтобы добится всего этого.  Нет уж спасибо.  Хочется отдельных утилит - возьмите и сделайте.  Исходники открыты - тут вам и алгоритмы, и графический движок - бери нехочу.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 00:42 23-07-2009
dabudada

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Tulon, гляньте два скриншота, я с таким случаем еще не сталкивался, может быть и Вам будет незнакомо поведение миниатюр: http://www.onlinedisk.ru/file/183672/

Всего записей: 21 | Зарегистр. 12-03-2009 | Отправлено: 10:21 23-07-2009
Rsbr

Newbie
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

Цитата:
Ухудшение качества, умньшение удобства, ухудшение работы автоматических алгоритмов - да еще и куча усилий, которые нужно приложить, чтобы добится всего этого.  Нет уж спасибо.  Хочется отдельных утилит - возьмите и сделайте.  

 
Абсолютно согласен.Вообще отдельные утилиты некоторые и так есть,раньше,до появления СТ пользовался bash/perl/lisp + imagemagik,Gimp,unpaper и т.д и т.п. Неудобно было отслеживать процесс и исправлять неверно обработанные страницы.
Плюс промежуточные результаты,нумерация и т.д. Нумеровал страницы при резке скриптом автоматически типа 4-л и 4-пр.
Отдельные утилиты это всё равно что конвеер по разным предприятиям расташить...Пользоваться этим станет гораздо труднее,тот кому это нужно (и кто знает зачем это нужно) будет пользоваться.А остальные будут ругаться и искать программу "всё в одном"
Если Вместо СТ сделать несколько утилит-одна крайность.Если прикрутить объединение на выходе,сканирование,распознование -другая.
 

Всего записей: 10 | Зарегистр. 17-04-2009 | Отправлено: 11:00 23-07-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
dabudada
Похоже на баг.  Выкладывайте файл, миниатюра которого не отображается.
Не отображается она на всех этапах или только на некоторых?
 
Добавлено:
dma200899
Исправил падение после удаления последнего скана в проекте.
Сейчас займусь залипаним параметров на стадии Макет Страницы.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 23:19 23-07-2009
Tulon

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Ну вот - залипание тоже исправил.

Всего записей: 718 | Зарегистр. 07-05-2008 | Отправлено: 01:54 24-07-2009
dma200899

Junior Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
А как насчет черных полос между текстом и полями при поворотах ?
(все остальное, простоЮ можно обойти, а это требует долгой и нудной чистки).
 
Кстати, а что с прокручиванием ленты при зажатом контроле ?
 
Может в новой сборке и отражение ID в ленте сделаете (идентичность имени файла - названия миниатюры в ленте) ?

Всего записей: 126 | Зарегистр. 29-06-2008 | Отправлено: 07:46 24-07-2009 | Исправлено: dma200899, 07:51 24-07-2009
   

Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107

Компьютерный форум Ru.Board » Компьютеры » Программы » Scan Tailor
Widok (17-02-2010 12:17): Лимит страниц. Продолжаем здесь.


Реклама на форуме Ru.Board.

Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
Modified by Ru.B0ard
© Ru.B0ard 2000-2024

BitCoin: 1NGG1chHtUvrtEqjeerQCKDMUi6S6CG4iC

Рейтинг.ru