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

» Scan Tailor

Автор: dma200899
Дата сообщения: 12.07.2009 02:45
Столкнулся вот еще с чем.

Сканы пронумерованы
Scan1, ..., Scan9, Scan10, ..., Scan 99, Scan100...Scan 333

При загрузке в проект и первой обработке СТ расположил все в правильном порядке.
Сохранил проект. Загрузил по новой и они оказались все расположены в "перепутанном"
Скан1
Скан10
Скан100
Скан2
Скан20
Скан200
Автор: iit512
Дата сообщения: 12.07.2009 06:16
Вообще, последние сборки не берут многие сканы, видимо, по каким-то эзотерическим причинам, связанным с DPI. Откатился на сборку 382, с ней все нормально. Нехорошо получается. Может быть, стОит снять эти ограничения? Или хотя бы добавить какие-нибудь вразумительные сообщения, кода нельзя импортировать сканы в проект?
Автор: dma200899
Дата сообщения: 12.07.2009 06:32
Не согласен. Последняя сборка почти не падает. Мне с ней удобнее.

Но то, что старые сборки могут быть полезны. согласен. Может можно u235
просить серию сборок выложить с описаниями чем различаются.
Пример - сейчас в ч/б всегда идет сглаживание, а мне оно например иногда бывает вредно. Давно точно была сборка без сглаживания.
Автор: ndch
Дата сообщения: 12.07.2009 11:14
dma200899

Цитата:
серию сборок выложить с описаниями чем различаются.


http://scantailor.svn.sourceforge.net/viewvc/scantailor?view=rev&revision=389
Log Message:    Performance improvements for the Savitzky-Golay filter.
и т.д. - курить до умопомрачения

http://scantailor.svn.sourceforge.net/viewvc/scantailor?view=rev&revision=387
Log Message: Change some UI text.

Сильно любопытные могут курить "text changed"


Добавлено:
iit512

Цитата:
по каким-то эзотерическим причинам, связанным с DPI

Причина dpi<150 или разрешение=размеру. Никакой эзотерики.
Предупреждения действительно не помешали бы.

СТ изначался предназначался для обработки сырых сканов книг - отсюда растут причины того что высота букв должна быть более 10 пикселей - а это в среднем означает разрешение сканирования не менее 150 dpi.

автора задолбало наличие shit-сканов (dpi<150 dpi) и сканов у которых разрешение == размеру (есть такие софтины/сканеры) и связаные с этим глюки СТ.
Автор: Tulon
Дата сообщения: 12.07.2009 12:07

Цитата:
Вообще, последние сборки не берут многие сканы, видимо, по каким-то эзотерическим причинам, связанным с DPI. Откатился на сборку 382, с ней все нормально. Нехорошо получается. Может быть, стОит снять эти ограничения? Или хотя бы добавить какие-нибудь вразумительные сообщения, кода нельзя импортировать сканы в проект?

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

Еще раз повторю причины жесткого контроля DPI:
1. Меньше 150 DPI - это скорее всего DPI экрана, а не сканирования. Получается в результате обработки сырых сканов некоторыми программами. Если же DPI действительно меньше 150 - такой исходный материал лучше вообще не обрабатывать, по крайней мере в ST. Автоматические алгоритмы (главным образом Полезная Область) с таким качеством не справляются, геометрические преобразования и сглаживание приводят к потере деталей, которых при таком разрешении и так слишком мало. А потом еще не исключены сообщения сюда, типа "Полезная Область плохо работает - в половине случаев руками править приходится".
2. Если физические размеры, вычисленные из DPI и пиксельных размеров выходят слишком большими. Сейчас это > 40 см, но походу это слишком строго - сделаю 50. Этот случай более редкий, например книга отсканирована в 600 DPI, а в файлах прописано 300. Это чревато падениями от нехватки памяти. Например в этом случае потребление памяти возрастет в 4 раза, по сравнению с тем, что было бы, если бы было указано правильное DPI, то есть 600. А если бы скажем было указано 150, а в реале 600, то потребление памяти вырасло бы уже в 16 раз [квадрат от отношения правильного DPI к неправильному]. Кстати стоит потреблению памяти вырасти до 3 (может двух - не уверен) гигов, никакой файл подкачки уже не поможет - будет исчерпано адресное пространство.
Автор: dma200899
Дата сообщения: 12.07.2009 14:37
В ленте предпросмотра (на стадии выводы) ОЧЕНЬ не хватает порядковых номеров.
Щас контролирую смешанный/чб/цветной вывод через прсомотрщик
а поскольку сканы то двусторонние, то нет нумерация сбивается.
Хотелось бы видеть ID страницы и на ленте предпросмотра и у файла.
Автор: Tulon
Дата сообщения: 12.07.2009 15:38

Цитата:
В ленте предпросмотра (на стадии выводы) ОЧЕНЬ не хватает порядковых номеров.
Щас контролирую смешанный/чб/цветной вывод через прсомотрщик
а поскольку сканы то двусторонние, то нет нумерация сбивается.
Хотелось бы видеть ID страницы и на ленте предпросмотра и у файла.

С этими ID один гемморой. Проблема в том, что они не постоянны. Вставил файл в проект - все последующие ID сбились. Изменил тип разреза - то же самое. Я вынашиваю мысль совсем от них отказаться. Выводить файлы вида orig_name_L.tiff и orig_name_R.tiff соответственно для левой и правой половинки.
Автор: iit512
Дата сообщения: 12.07.2009 21:01

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

Хорошо, что есть сообщения. Прошу прощения, что я их не заметил.

Странно, что Вас не удивляет тот факт, что сборка 382 обрабатывает сканы, и выдает приемлемый результат, а сборка 386 отказывается импортировать те же самые сканы. На мой взгляд, в таком направлении софт развиваться не должен. Получается, что вместо того чтобы помогать пользователям, программа начинает им мешать.

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

Практический вывод я сделал для себя такой -- оставляю сборку 382 (раньше я старые сборки стирал).

Добавлено:

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

Поддерживаю.
Автор: Tulon
Дата сообщения: 12.07.2009 23:40

Цитата:
Странно, что Вас не удивляет тот факт, что сборка 382 обрабатывает сканы, и выдает приемлемый результат, а сборка 386 отказывается импортировать те же самые сканы. На мой взгляд, в таком направлении софт развиваться не должен. Получается, что вместо того чтобы помогать пользователям, программа начинает им мешать.

Ну так исправте DPI, если они неправильные, а если правильные, и >= 150, то пример в студию.


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

Ну не бывает так - должна обрабатывать любые сканы с любыми DPI. Я уже привел пример, к чему ведет указание DPI сильно меньше реального - к нехватке памяти.
Реально низкий DPI тоже ничего хорошего - вы ведь не расчитываете, что FineReader возьмет скан в 150 DPI, да еще и чем-то уже обработанный?
Автор: iit512
Дата сообщения: 13.07.2009 05:24
Автор: dma200899
Дата сообщения: 13.07.2009 07:07
а вот еще наблюдение - не знаю это происки винды или в программе так заложено.

Кручу колесико мышки вниз, листая ленту предпросмотра. Выбираю допустим "левые страницы". Из-за вкладок они расположены хаотично и выбор четных/нечетных не работает.
Если контрол не держать, то 1 проворот колесика мышки=1 страница.
Но тогда нажал-отпустил-нажал-отпустил-нажал-отпустил контрол для выделения.
Это во-первых неудобно. Во-вторых - стоит один раз недонажать контрол и все выделение исчезает. А если там сотня страниц ?
Удобнее контрол зажать и держать. Благо все опции СТ при этом доступны.
Но !
При зажатом контроле один проворот колёсика = 2-3 страницы. И нужные мне страницы просто проскакивают мимо видимой части ленты.
Нельзя ли это чем отрегулировать: число страниц ленты на одно вращение колесика при зажатом контроле (ну или шифте) ?


Автор: anagnost96
Дата сообщения: 13.07.2009 10:55
Tulon

Нужно обработать альбом с большим количеством иллюстраций, ввиду чего хотелось бы хотя бы для себя и временно хакнуть СТ, отломав объединение текста и картинок. Скажем, на 300 dpi выводим только картинки, а на 600 -- только текст. Не подскажете, где копать в исходниках?
Автор: Tulon
Дата сообщения: 13.07.2009 23:37
anagnost96

Цитата:
Нужно обработать альбом с большим количеством иллюстраций, ввиду чего хотелось бы хотя бы для себя и временно хакнуть СТ, отломав объединение текста и картинок. Скажем, на 300 dpi выводим только картинки, а на 600 -- только текст. Не подскажете, где копать в исходниках?

Подскажу.

В файле filters/output/OutputGenerator.cpp, в функции processImpl(), есть такой код:

Код:
        if (maybe_normalized.format() == QImage::Format_Indexed8) {
            combineMixed<uint8_t>(
                maybe_normalized, bw_content, bw_mask
            );
        } else {
            assert(maybe_normalized.format() == QImage::Format_RGB32
                || maybe_normalized.format() == QImage::Format_ARGB32);
            
            combineMixed<uint32_t>(
                maybe_normalized, bw_content, bw_mask
            );
        }
Автор: anagnost96
Дата сообщения: 14.07.2009 11:04

Цитата:
В файле filters/output/OutputGenerator.cpp, в функции processImpl(), есть такой код:


Огромное спасибо, сам бы ни за что не догадался! Сделал пока так:


Код:
        if (m_dpi.horizontal() > 500)
            maybe_normalized.fill(0xff);
        else
            bw_content.fill(WHITE);
Автор: dma200899
Дата сообщения: 16.07.2009 07:19
Вот сейчас опять размеры страницы залипли.

Вставил в проект страницу с большими пиксельными размерами.
Увеличился размер страниц.
удалил страницу из проекта.
Широкие размеры страниц остались и не сокращаются.
Автор: Tulon
Дата сообщения: 16.07.2009 08:27

Цитата:
Вставил в проект страницу с большими пиксельными размерами.
Увеличился размер страниц.
удалил страницу из проекта.
Широкие размеры страниц остались и не сокращаются.

Проблема понятна. Исправлю до следующего релиза.
Автор: Tulon
Дата сообщения: 18.07.2009 18:44
Пора серьезно взяться за проблему со случайными падениями. Где падает я знаю, благодаря краш репортам, теперь надо выяснить почему. Собрал специальную сборку, которая при падении в этом месте будет оставлять на рабочем столе файл ST_crash.txt с полезной информацией. Вы его открываете, и copy-paste'ите сюда.

Добавлено:
Специальная сборка
Автор: dma200899
Дата сообщения: 19.07.2009 08:12
pt: (903.006, 600)
img.bits(): 0x78c29e0
img.size(): 23x17
clip: (747, 602), 250x96
sr: (0, 12), 23x6
alpha: 256
x: 903, y = 602
iw: 23, ih = 4
srcBits: 0x78c2ee8
srcBytesPerPixel: 4
srcBPL: 92
rasterBuffer->buffer(): 0x3330000
rasterBuffer adjusted: 0x358ae1c
rasterBuffer->size(): 1024x719
dstBytesPerPixel: 4
dstBPL: 4096

Добавлено:
pt: (902.595, 256)
img.bits(): 0x116e79d8
img.size(): 23x17
clip: (747, 258), 250x440
sr: (0, 4), 23x14
alpha: 256
x: 903, y = 258
iw: 23, ih = 12
srcBits: 0x116e7c00
srcBytesPerPixel: 4
srcBPL: 92
rasterBuffer->buffer(): 0x3330000
rasterBuffer adjusted: 0x3432e1c
rasterBuffer->size(): 1024x719
dstBytesPerPixel: 4
dstBPL: 4096
Автор: Tulon
Дата сообщения: 19.07.2009 08:58
Хорошо, с этой функцией все ясно - ей передаются неправильные параметры.
Если конкретнее, то sr (область исходной картинки для рисования) на один пиксель вылазит за пределы этой самой картинки (img.size()). Значит причина где-то выше в цепочке вызовов. Будем искать.
Автор: dma200899
Дата сообщения: 19.07.2009 10:59
Надо дальше присылать ? Это пока все тот же проект:


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
Автор: Tulon
Дата сообщения: 19.07.2009 11:22
Больше не надо присылать - уже все ясно. Напишу сегодня баг репорт Qt'шникам, а в своей сборке сам исправлю, чтобы их не ждать.
Автор: dma200899
Дата сообщения: 19.07.2009 14:18

Цитата:
Я вынашиваю мысль совсем от них (от 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
и про прокрутку мышкой при нажатом контроле вы не ответили
Автор: Tulon
Дата сообщения: 19.07.2009 15:00
Добавить ID в ленту предпросмотра не сложно, но все равно это не решает проблемы сдвига ID при удалении / добавлении файлов и даже при смене типа разреза.
Да, если просто отказаться от ID, то возникает проблема с одинаковыми именами файлов из разных директорий. Я уже жалею, что вообще разрешил добавлять в проект файлы из разных директоий. Это добавляет сложности и туда и сюда, а пользы - практически ноль.
Решение может быть таким: кроме _L и _R добавлять всякие там (1), (2) если такое необходимо.
То, что вы предлагаете, сделать очень и очень непросто. Нужно помнить, какие исходные файлы были записаны в какие выходные; тоже самое нужно помнить для кэша миниатюр (выходные изображения там тоже кэшируются). Причем помнить это нужно не просто в памяти, а записывать в проект. Сплошной гемморой в общем.
Автор: dma200899
Дата сообщения: 19.07.2009 15:41
у меня проблемы сдвига ID в общем-то и не было

Добавлено:

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


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

В результате у меня уже куча проектов, где в конец добавлены "поправленные" сканы. при этом оригинальные файлы в начальной директории остаются "как есть".
Автор: Tulon
Дата сообщения: 19.07.2009 16:22

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

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

Добавлено:

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

А у меня не разу не упало, но это ведь не значит, что проблемы нет
Автор: monday2000
Дата сообщения: 19.07.2009 22:23
Tulon
Кромсал я сегодня одну книжку и опять у меня возникли некоторые соображения по СТ.

Всё-таки, ИМХО один из принципиальнейших пороков СТ - это жёсткая заданность всего процесса сканобработки.

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

А именно, наиболее разумно было бы сделать:

- Для "Исправление ориентации" - отдельная, независимая программа.
- Для "Разрезка страниц" - отдельная, независимая программа.
- Для "Компенсация наклона" - отдельная, независимая программа.

Вы оба с bolega не понимаете - всё это до такой степени разнородные по смыслу задачи, что их абсолютно нелогично втискивать в одну и ту же программу. Ну не делает же Билл Гейтс гибрид MS Office и MS Excel? Почему-то взамен он делает MS Office, состоящий из набора таких офисных программ.

"Исправление ориентации" - это вообще очень редко нужная функциональность. Необходима только для неопытных юзеров - которые часть страниц сканируют "сверху вниз", а часть - "снизу вверх" (и нужно потом индивидуально-вручную поворачивать). Лично я всегда проделываю "Исправление ориентации" в Irfan View - быстро и просто.

"Компенсация наклона" - ИМХО также должна быть отделена (в отдельную программу) от "Разрезка страниц" - потому что deskew вообще склонна к ошибкам по своей природе - например, в СК deskew постоянно глючит. Мне попадались случаи, когда даже Файнридер неправильно делал deskew.

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

Этим мы и достигнем столь вожделенную простоту - которой так не хватает сейчас ни СК, ни СТ.

Что касается "Полезная область" и "Макет страницы" - тут вообще разговор отдельный. "Макет страницы" - наиболее вероятно, что тоже надо выделить в отдельную программу. "Полезная область" - быть может, заменить на "Примерная полезная область" (и почти наверняка тоже выделить в отдельную программу). Впрочем, в отношении "Полезная область" и "Макет страницы" ещё нужно много отдельно думать.

Почему я так настаиваю именно на наборе простейших программ вместо одной большой гибридной, как сейчас?

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

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

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

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

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

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

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

Одним словом - "я выбираю СканКромсатор". (и это я, который критикую СК больше всех).
Автор: Tulon
Дата сообщения: 19.07.2009 23:15
monday2000
Для подхода "все в одном" есть пара очень серьезных технических причин. Самое обидное, что я их уже называл, по моему на этом же форуме, и по моему как раз вам и отвечал - только найти не могу. Придется еще раз написать.

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

Вторая причина еще более серьезная: потеря важной информации между стадиями. Пример такой информации - границы исходного изображения после компенсации наклона. После компенсации наклона либо появляются дополнительные поля (какого интересно цвета они должны по вашему быть?), либо наоборот бока картинки обрезаются. Обрезать опасно - можно отрезать часть текста. Значит добавляем поля. Эти самые поля будут сбивать с толку некоторые алгоритмы СТ. Что будет если я сделаю вывод на произвольном этапе? Люди начнут делать там вывод, который потом загрузят обратно в СТ, создавая проблемы для его алгоритмов. Ну не любит СТ поля искуственного происхождения и все тут. Я когда вижу скан с такими полями, думаю: ну какого фига такое сделали? И качество убили (любой поворот - потеря качества), и еще и внесли туда элементы, которых там не было, и которые осложняют обработку. А вы мне предлагаете, чтобы СТ сам генерил такие сканы на промежуточных этапах.

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

Добавлено:
Я кстати сегодня убил весь день на написание test-case для этого бага в Qt. Без test-case Qt'шники его вообще вряд-ли признают багом. Очень тяжело воспроизвести этот баг - офигетельно тяжело. У меня он так не разу и не привел к падению, но по крайней мере я добился того, что Valgrind замечает чтение за пределами буффера. Отправил им баг репорт вместе с test case'ом - будем надеяться исправят. Кстати исправить его несравнимо проще, чем найти или воспроизвести. Я и сам могу исправить, только тогда придется это делать для каждого нового релиза Qt. Кстати Linux'овую версию этот баг вроде не затрагивает.

Добавлено:
Шибко умные заметят - если Linux'овая версия не подвержена багу, как же Valgrind (который только под Linux) его замечает?
Замечает, если явно указать Qt'шный програмный растеризатор вместо родного Linux'ового.
Автор: estimated
Дата сообщения: 20.07.2009 00:21
monday2000

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

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

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

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

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

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

Автор: Tulon
Дата сообщения: 20.07.2009 01:00

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

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


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

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


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

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


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

В конце концов регулировка аггресивности удаления пятен будет сделана, но только после того, как все что можно будет выжато из автоматического алгоритма. Кроме того, пока не совсем очевидно, что именно надо регулировать. У алгоритма три параметра - не делать же три ползунка.
Автор: anagnost96
Дата сообщения: 20.07.2009 11:26
Tulon


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


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


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


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

Страницы: 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172

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


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