» ScanKromsator СканКромсатор (Часть 2)

Цитата:

А я лично это считаю очень ненормальным (по крайней мере если сканы - не ч/б). Мне нужно точно видеть качество скана (букв): гладкие они или рваные (от этого будет зависеть какой despeckle), корявые ли (нужно ли использовать сглаживающий фильтр), есть ли дырки, блеклости и т.д. Это все будет влиять на то, какой мне профиль применить.

Вот! что и требовалось доказать - случаи разные бывают Лично я очень редко меняю эти опции. Да и всегда можно сделать Preview, о котором я писал



Цитата:

Тут нет противоречия. Дело в том, что некоторые алгоритмы, используемые при обработке - интегральные, т.е. они зависят от параметров, вычисляемых исходя из всего изображения. Эти параметры могут измениться при изменении резаков (поверьте мне). Это может (хоть и не сильно) повлиять на качество, контур, зоны. Поэтому полный пересчет необходим. Например, в SK есть команда пересчета зоны. По этой команде все равно идет полный цикл обработки страницы (но без сохранения ее), иначе получится либо другое качество, либо местоположение зоны на выходе съедет.

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

Т.е предлагалось не менять основной метод, а дополнить "упрощенным" режимом проверки драфта.


Цитата:

Драфт - это отдельная, независимая от обработки операция, и вопрос автоматизации контроля правильности драфта пока открыт.

Мне кажется, что сильно поможет развитие Thumbnails, что-то вроде этого:



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

Постараюсь говорить о том, что кажется абсолютно очевидным. На данном этапе концепция кажется еще не совсем устоявшейся, и если будем высказывать смутные предположения, быстро запутаемся.
Вначале скажу, что мне кажется принципиальным в новом подходе:
Метод призван увеличить удобство и скорость работы со сканами, а это значит, что он, как минимум, не должен удваивать (с точки зрения пользователя) некоторые этапы – т.е. мне кажется очевидным, что любого рода границы (резаки это или контуры блока текста) пользователь должен выставлять только один раз. Иначе путаницы не избежать, да и ускорения не получится.
Этот метод вряд ли можно сделать универсальным для всех возможных сканов. Он хорошо подойдет для сканов, полученных с ОптикБука, и вряд ли подойдет для разворотов. Т.к. в случае последних проверка правильности расстановки резаков – как правило, обязательный этап. (Т.е. опять-таки придется два раза контролировать границы). Он также не подойдет и для книг с полутоновыми изображениями, т.к. и в этом случае нам придется просматривать все страницы книги.
Иными словами, данный метод действительно позволит сэкономить кучу времени только в том случае, если пользователю не придется просматривать все сырые сканы один за другим.[more]К примеру, вчера обработка всего 50 страниц, полученных с фотосканера (500dpi в цвете – около 20 мб на страницу) заняла весь вечер).[/more]
Если пп. 1,2 верны, то весь процесс принятия решения относительно границ стоит перенести с этапа проверки работы DK на этап постобработки.
Таким образом, алгоритм работы будет примерно таким:
Делаем DK. Полностью автоматический – т.е. результаты его работы не проверяем.
Устанавливаем параметры обработки на нескольких выбранных страницах книги.
Обрабатываем.
На этапе постобработки проверяем границы блока текста, определяем ориентацию блока текста на странице, очищаем мусор вручную и т.п.
Рассчитываем средние фиксированные размеры страницы и производим «финализацию».

bolega

Цитата:

А я лично это считаю очень ненормальным (по крайней мере если сканы - не ч/б). Мне нужно точно видеть качество скана (букв): гладкие они или рваные (от этого будет зависеть какой despeckle), корявые ли (нужно ли использовать сглаживающий фильтр), есть ли дырки, блеклости и т.д. Это все будет влиять на то, какой мне профиль применить.

Да, но дело в том, что мы, как правило, стараемся установить параметры обработки, которые подошли бы в равной степени для всех страниц в книге. А это значит, что для того, чтобы установить параметры, нам не (всегда) нужно просматривать все сырые сканы один за другим в оригинальном качестве.
К примеру, книга может быть отсканирована в 600dpi и в цвете (см. пример выше за тегом [no][more][/no]). Размер одной такой страницы может превышать 20 Мб. А это значит, просматривать все эти страницы в хорошем качестве будет сущей мукой.
Так что в этом случае я соглашусь с Alexx S и предложу сделать переключаемый режим рендеринга страниц - к примеру, очень быстро, средне, качественно.
А еще интересно узнать, по какому принципу работает FastPictureViewer
Кстати, в СК есть предварительное кэширование просматриваемых сырых сканов?

ghosty

Цитата:

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

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

Цитата:

Так что в этом случае я соглашусь с Alexx S и предложу сделать переключаемый режим рендеринга страниц - к примеру, очень быстро, средне, качественно

1-е и 3-е уже есть (начиная с 1-й верии). Поэтому Ваше предложение я не понял. Как сделать средне - я не знаю, т.е. не знаю другого алгоритма, кроме тех, которые исп-ся в 1-м и 3-м варианте. Кстати, рендеринг - это тоже по сути downsample в размер окна.


Цитата:

Таким образом, алгоритм работы будет примерно таким

А чем он отличается от того, что используется сейчас?? Я так и делаю. Контроль обрезания номеров страниц на этапе DK (!) проверяю так: в окне VR сортирую иконки по высоте контента, просматриваю иконки сверху списка (чтобы выявить те, в контур которых попало что-то лишнее), затем - снизу списка (чтобы выявить те, которые имеют наименьшую высоту, возможно из-за того, что резак стоял неправильно). Достаточно просмотреть по 10-20 файлов с каждой из сторон. Те файлы, которые располагаются в середине списка, имеют примерно одинаковую высоту и практически гарантированно имеют правилтный контур и расположение резаков).

Добавлено:

Цитата:

А еще интересно узнать, по какому принципу работает FastPictureViewer

В принципе существует только 3 способа ускорить любой алгоритм, будь то вьюер или еще что:
- применять asm через MMX, SSE
- распараллелить процесс
- использовать упреждающее кэширование (чуть медленнее будут операции с текущим, но быстрее загрузка следующих). Используется во всех djvu-просмотрщиках.
У меня рендеринг идет через MMX, т.е. здесь уже потолок. Ускорить можно только 2-м способом, при условии что ядро у проца не одно. 3-й вариант тоже может помочь, правда, если просматривать файлы не по порядку, то будет наоборот, еще медленнее.

Цитата:

Изменения в новой версии (5.92) + описание нового порядка обработки (с "финализацией" файлов)

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

bolega

Цитата:

Контроль обрезания номеров страниц на этапе DK (!)

Т.е. теперь в том случае, если сканы представляют отдельные страницы (не развороты), DK можно доверять и не проверять? Точнее можно смело проверять на этапе постобработки?
Хотя, с другой стороны, я видел, что если поля на сыром скане слишком велики, резаки иногда вообще не ставятся (захватываются темные области) - т.е. интегральные алгоритмы могут не очень корректно работать...

Цитата:

А чем он отличается от того, что используется сейчас?? Я так и делаю.

Мне было важно понять, правильно ли я следую за Вашей мыслью
Отличается следующим (по ходу перечисления отличий возникли новые вопросы ):
Сейчас на этапе проверки контура постобработка невозможна - только после "финализации". Можно ли совместить и то, и другое? Кстати, нужен аналог функции Automargin - т.е. чтобы можно было сделать так, чтобы после одной из указанных сторон контура все стиралось - было бы очень удобно в том случае, когда куча пометок примыкает непосредственно к блоку текста.
Почему сразу после обработки не рассчитать фиксированные размеры автоматически (думаю, удобно было бы сделать в виде опции)? Тогда в режиме VR можно открывать Book properties также автоматически - удобнее даже в виде ToolBar'a сбоку.
Если мы доверяем DK, то и его тоже можно делать автоматически непосредственно в ходе обработки, причем процессы DK и собственно обработки можно было бы в этом случае распараллелить.

Таким образом, алгоритм был бы таким:
Устанавливаем параметры обработки на нескольких выбранных страницах книги.
Нажимаем кнопку "Process", появляется окно DK с дополнительными опциями, вроде "Рассчитывать фиксированные размеры автоматически". После установки опций и нажатия "ОК" начинается обработка.
На этапе постобработки проверяем границы блока текста, определяем ориентацию блока текста на странице, очищаем мусор вручную и т.п.
Производим «финализацию».


Цитата:

1-е и 3-е уже есть (начиная с 1-й верии). Поэтому Ваше предложение я не понял.

Подождите, но ведь Вы совсем недавно сказали, что отключили опции рендеринга (и они действительно отключены в Options -> Main win).

Цитата:

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

Ну, сейчас, по-моему, уже у большинства не одно

Цитата:

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

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

ghosty

Цитата:

DK можно доверять и не проверять? Точнее можно смело проверять на этапе постобработки?

Иногда можно Думаю, полностью доверять нельзя ни одной программе.


Цитата:

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

Нет, здесь дело как правило в другом. SK не расчитан на такие сканы, я честно говоря не особо прорабатывал такие случаи. Они довольны редки, а анализировать их очень сложно. Сейчас SK "рассуждает" примерно так: если грязи по краям тааак много, значит, это для чего-то нужно, пусть остается"


Цитата:

Сейчас на этапе проверки контура постобработка невозможна - только после "финализации". Можно ли совместить и то, и другое?

Да, я так и написал: "пока нельзя". Не успел просто.


Цитата:

Почему сразу после обработки не рассчитать фиксированные размеры автоматически

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


Цитата:

Если мы доверяем DK, то и его тоже можно делать автоматически непосредственно в ходе обработки

Нет, мы еще не доверяем настолько


Цитата:

Подождите, но ведь Вы совсем недавно сказали, что отключили опции рендеринга

Эта была опция для того упомянутого Вами "среднего" метода. Т.к. я в итоге перешел на asm, то она стала бессмыслена, т.к. при оптимизированной реализации что средние, что наилучшие дают одинаковое время. Так что остались только 1-й и 3-й. Напомню, что 1-й (быстрый) - это когда отключен фильтр Image->No zoom filter (для серых/цветных 600dpi - то что надо).
Более того, основной вклад в скорость показа теперь вносит не рендеринг, а время считывания файла с диска и декодирование. Думаю, что распараллеливание самого рендеринга практически не даст никакого выигрыша. Ну и объем конечно. Например, цветной скан 600dpi, который занимает на диске мегов 10-20, после загрузки в память (а в ней он хранится как 24-ьитный windows bitmap + возможно 8бит для прозрачности) занимает уже 100-120 мегов! Это много даже для internal-cpu-кэша. А учитывая, что при обработке для ряда фильтров создается 1-3 копии скана, представляете, какая идет нагрузка на проц и шину.

bolega

Цитата:

Нет, мы еще не доверяем настолько

Надолго вчера задумался
А что если... сделать так:

DK все-таки выполняем вместе с основной обработкой (как писал ранее). При этом область за пределами резаков не обрезается, но и не обрабатывается - она участвует только в бинаризации и апсемплинге.
Тогда после обработки получаем следующее в режиме VR:
мы видим необрезанную страницу полностью, на ней видим мусор, оставшийся за резаками (его можно дать серым, чтобы глаза особо не мозолил ), видим блок текста в рамке.

Таким образом, мы можем действительно контролировать работу DK уже после обработки. Для этого в режиме VR у нас должна быть кнопочка Reprocess. Есть два случая ошибки DK - когда отрезается часть текста и когда оставляется слишком большая часть полей.
Если DK отсек часть текста (к примеру, часть таблицы), мы это увидим - такая часть окажется за резаками, т.е. будет серой и довольно жуткой Исправляем рамку, нажимаем Reprocess.
Если, к примеру, DK оставил слишком много мусора, но при этом координаты блока текста определились правильно, ничего не меняем и жмем Reprocess - обработка будет произведена уже только в выделенной рамке (понятно, что при апсемплинге нужно будет пересчитывать координаты рамки, но это, думаю, не сложно).

Это решает сразу три проблемы:
1) Двухэтапный метод становится универсальнее, т.е., возможно, теперь он подойдет и для разворотов.
2) Пользователь все-таки будет контролировать только один контур, причем уже на черно-белых сканах. Он не будет тратить время на контроль работы DK перед обработкой, когда необходимо делать это на сырых сканах, загружая их один за другим по порядку.
3) Мой последний алгоритм из 4-х пунктов, предложенный выше, становится возможным

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

ghosty

Цитата:

Тогда после обработки получаем следующее в режиме VR:
мы видим необрезанную страницу полностью, на ней видим мусор, оставшийся за резаками (его можно дать серым, чтобы глаза особо не мозолил )

Так я это и предлагал ранее


Цитата:

Alexx S

Цитата:При обработке без финализации не вычищать области за резаками, а маскировать их


В при любом режиме перед обработкой идет обрезка по резакам! (именно по резакам, а не по контуру) Это аксиома, идеология программы (отрезать мусор и тени). Иначе зачем тогда они нужны?? Представьте, что исходный файл - разворот, если ничего не отрезать, а маскировать - sk так и будет его "таскать" по всем алгоритмам и окнам (целиком разворотом) ??? И какие объемы памяти для этого нужны, страшно подумать (не забывайте о 300dpi gray->600dpi gray)

Собственно, после этого и зашла речь о СТ и упрощенной отрисовке

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

ghosty
Идея понятна. Принцип хороший.

1.

Цитата:

мы видим необрезанную страницу полностью

Что мы увидим в случае разворота?

2. если не обрезать разворот, то при апсэмплинге до 600dpi его размер достигнет 200-250 мегабайт. Учитывая фильтры, умножим на 2-3. Система просто упадет... При этом никакой речи о параллельности тоже не может быть. Каждому потоку потребуется по 600-700 метров как минимум.


Цитата:

обработка будет произведена уже только в выделенной рамке

Я себе это плохо представляю. Проблема еще и в том, что после deskew уже не будет точного соответствия между координатой на выходе и координатой на входе. Т.е. нет формулы, по которой, зная ко-ту на выходе, можно посчитать ко-ту на входе. Это из-за того, что мои алгоритмы поворота не описываются формулами (типа x2=x1*cos+y1*sin). Они, грубо говоря, в некотором роде итерационные.

Идея неплохая. Вы в точности описали принцип работы ST

Alexx S

Цитата:

Так я это и предлагал ранее

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

Alexx S

Цитата:

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

Да уж, не просто...
И не забывайте одну вещь. Многие усовершенствования только кажутся что облегчат жизнь, а на поверку 99% пользователей они не устраивают. Вспомните идею с подсветкой спеклов и "аферу" с их миганием На практике оказались совсем бесполезными...

Цитата:

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

Нет, не так. Я предлагал обрабатывать все, это было отвергнуто, теперь пытаюсь найти альтернативный вариант.


Цитата:

спомните идею с подсветкой спеклов и "аферу" с их миганием На практике оказались совсем бесполезными...

Мигание - да, бесполезно, зато подстветкой текста пользуюсь постоянно и очень доволен

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

И еще одно. Чтобы мы ни придумали, но смысл проверки от этого не изменится: все равно в мозгу нужно будет соотносить исходный и обработанный скан (в этом ведь принцип проверки, иначе как еще увидишь, что что-то лишнее, или наоборот, чего-то не хватает). Я хочу сказать, что Ваши предложения все-равно потребуют проведения нудного постраничного сравнения, поменяется лишь форма отображения, что в принципе ничего не меняет и вряд ли снизит усталость от этой процедуры.
Так есть ли смысл все усложнять и замедлять, если результат будет такой же?
Я предложил оптимальный на мой взгляд вариант: кто хочет быть на 100% уверен в правильности, тот все равно вынужден будет проверять все страницы. Кому лень, пусть проверит только самые первые и самые последние файлы в отсортированном списке VR, т.е. те, где вероятность ошибки максимальна. И не отвлекаясь на те, где ошибка практически исключена

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

bolega

Цитата:

Что мы увидим в случае разворота?

Разворот мы все-таки разрезаем на половинки. Поэтому видим те же отдельные страницы, обрезанные до Inner Cutters. Так будет нормально?


Цитата:

Они, грубо говоря, в некотором роде итерационные.

Да, но разве нельзя померить угол до Deskew? Особой точности тут не нужно - можно просто накинуть немного к координатам прямоугольника с учетом поворота.


Цитата:

Идея неплохая. Вы в точности описали принцип работы ST

Давно его не видел, но там, по-моему, тоже на сырых сканах устанавливаются границы...
В любом случае, я был за двухэтапный метод обработки (поддерживая Alexx S, который подбросил идею с наложением полей постфактум) еще в то время, когда СТ не было даже в проекте

Цитата:

Так есть ли смысл все усложнять и замедлять, если результат будет такой же?
Я предложил оптимальный на мой взгляд вариант: кто хочет быть на 100% уверен в правильности, тот все равно вынужден будет проверять все страницы. Кому лень, пусть проверит только самые первые и самые последние файлы в отсортированном списке VR, т.е. те, где вероятность ошибки максимальна. И не отвлекаясь на те, где ошибка практически исключена

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

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

bolega

Цитата:

Кому лень, пусть проверит только самые первые и самые последние файлы в отсортированном списке VR, т.е. те, где вероятность ошибки максимальна. И не отвлекаясь на те, где ошибка практически исключена

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

Alexx S

Цитата:

самого жутко бесит подобное поведение.

Ни в коей мере! Наоборот, я все внимательно изучаю и мотаю на ус.
Вообще-то, друзья называют меня мастером отмазок

Цитата:

Разворот мы все-таки разрезаем на половинки. Поэтому видим те же отдельные страницы, обрезанные до Inner Cutters. Так будет нормально?

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

Цитата:

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

Да, Вы правы. Поэтому Ваши с Alexx S предложения я буду обдумывать, с поправкой конечно на быстродействие и увязки с ядром и структурой SK

Цитата:

Ни в коей мере! Наоборот, я все внимательно изучаю и мотаю на ус.
Вообще-то, друзья называют меня мастером отмазок

Я имел в виду то, что правка полей, ради котрой все затевалось, не имеет никакого отношения к редактированию результатов драфта в окне VR , о котором и не говорили никогда.

Alexx S

Цитата:

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

Подождите, а зачем мне как пользователю тянуть что-то куда-то, если я там ничего не вижу (а имею возожность увидеть, только потянув)? Т.е. зачем Вы предлагаете именно маскировать то, что отрезано? (я предлагаю серым его давать).

Добавлено:

Цитата:

Я имел в виду то, что правка полей, ради котрой все затевалось, не имеет никакого отношения к редактированию результатов драфта в окне VR , о котором и не говорили никогда.

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

Цитата:

Т.е. зачем Вы предлагаете именно маскировать то, что отрезано? (я предлагаю серым его давать).

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

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

Против показа отрезанного я ничего не имею. да и сам это предлагал ранее.


Цитата:

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

Alexx S

Цитата:

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

Тогда получилось бы, что опять-таки имеем удвоение контура (резаки и граница блока текста), а это скверно в плане юзабилити

Цитата:

Тогда получилось бы, что опять-таки имеем удвоение контура (резаки и граница блока текста), а это скверно в плане юзабилити

Я имел в виду что-то наподобие этого:

Alexx S

Цитата:

Я имел в виду что-то наподобие этого:

И я о том же - какой смысл проверять контур на thumbnail'ах, если отсутствует возможность его изменять - в силу их невысокого разрешения и неточности, связанной с этим?
Значит, придется этот контур показывать еще и на полноразмерных сканах (сырых или конечных), и это, ИМХО, неоправданное усложнение.

Добавлено:

Цитата:

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

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

ghosty

Цитата:

И я о том же - какой смысл проверять контур на thumbnail'ах, если отсутствует возможность его изменять - в силу их невысокого разрешения и неточности, связанной с этим?

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

Подскажите плиз начинаю обработку изображения и выскакивает Нехватка памяти... проверял как на версии 5.91 так и на версии 5.92
Выскакивает только после того как я ставлю в настройках изменить разрешение на 600DPI и цвет чёрно-белый.
Вот скан
Зеркало

MIHMIH007
у меня с 4GB тоже выскакивает.

Добавлено:
но, по-видимому, к памяти отношения не имеет

Цитата:

Нехватка памяти

не совсем точный перевод "not enough storage"

Olive77
У меня в версии 5.91 выскакивает out of memory ..... самое интересно что пробовал ВСЁ!!... Даже тупо в файнридер добавлял а потом извлекал как несжатый Тифф.... всё равно пишет такую ошибку. Книгу извлёк DJVU формата.... и на всех страницах такая ошибка. Дело действительно не в том скоко там 4gb или 500кб ....