» ScanKromsator СканКромсатор

bolega
Может уже спрашивали, но я всё же ещё раз...
В Shift image так и задумано слежение за введёным числом? Можно ли как-нибудь отключить автоматическое выставление при изменение(т.е. хочу поставить 200, а он мне после ввода 3 знака ставит 100)?

Хотел еще спросить. Вкладка files. Расположение галок и функций: DPI: original, Input DPI: 600. Галка с only unknown DP снята. Обычно делал так.
В руководстве VadimirTT имеется другое расположение DPI: 600, Input DPI:auto. При условии, что и те и другие исходники выполнены в 300 dpi
Второй вариант у меня «кромсался» дольше по времени. На конечных файлах, глазом разницы не заметил.
Спрашивается от перемены мест слагаемых сумма измениться?
Заранее спасибо.

Oxо-хо.
Придавили так придавили. Я за неделю не написал ни строчки кода! Потому что все время ушло на ответы (в конфе и по почте). Пощадите!
Отвечу пока на что хватит силы.

monday2000
Я уже писал почему резаки, а не зоны. Обычно когда говрят о необходимости зон в ск, то приводят пример FR, программ сканирования и т.д. Но совсем забывают, что там зоны - это "последняя инстанция", внутри их уже ничего конкретизироваться не будет, т.е. есть зона - и к ней применяется то-то и то-то, как к целому. В СК же нужно внутри отрезаемых областей ставить всякие exclude-зоны, а также работать с выделениями, чистить, редактировать и т.п. Ни одна другая программа это не позволяет! И правильно делает. Т.к. неоднозначность в обработке нажатий мыши. Как интерпретировать щелчок на зоне, лежащей внутри другой зоны (под щелчком понимается не просто нажал-отпустил, но также и начало процесса выделения).
Кроме того, у меня в графическом движке нет возможности работать с непрямоугольными зонами. В принципе его можно переписать, но вы просто не представляете, что такое графич. движок - это десятки мегабайт кода! На это я точно уже не буду время тратить.
Так же нужно учитывать, что показать окончательный контур после кромсания на _исходном_ скане - большая проблема. Ведь если на выходе он прямоугольный, то на исх. скане - увы, в большинстве случаев нет.

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

Per_aspera_ad_astra
Inputdpi не нужно использовать, если у Вас нормальные изображения. Кромсатор будет сам брать значения dpi из файла. Ручное задание dpi предназначено для довольно редких случаев, когда графич. файл не содержит инфы о dpi. Это относится к gif-ам либо jpg-ам из-под фотика. Бывает, конечно, что некоторые левые графич.программы суют в файлы вместо dpi всякую лабуду, но это очень редко.


Цитата:

Input DPI: 600. Галка с only unknown DP снята. Обычно делал так.

Неправильно делали, у Вас исх.файлы - 300dpi, а Вы говорите кромсатору, что 600.
Кромсатор использует разные алгоритмы и и последовательность их применения для разных dpi, отсюда и разница.

bolega

Цитата:

Я уже писал почему резаки, а не зоны.

Ага, всё понятно. Теперь всё ясно. Извините, не подумал, что всё так сложно. Конечно, пускай всё так и остаётся, раз так проблематично изменить. Будем думать тогда о более простых изменениях интерфейса.

Цитата:

Пощадите!

Да уж хотелось бы, да вот такие вопросы фундаментальные встают, что, как ни крути - а надо в них разобраться, иначе ВСЁ остальное непонятно и в голове каша. Зато я когда разберусь - обязуюсь разжевать всё в Пособии.

Цитата:

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

Признаюсь - это глупость я сморозил. И даже Result view напрасно предложил убрать - просто действительно Кромсатор настолько специфичен, что тут нужен свой подход. Будем думать.

bolega
Пока что очень прошу помочь мне разобраться в том, что я написал:

Цитата:

Читая имеющуюся разношёрстную документацию по Кромсатору, я сделал следующее "открытие": Прошу прокомментировать, подтвердить, или опровергнуть:

Определяет ли Draft kromsate точно контур голого текста, или ему на это плевать, и он только грязь распознаёт (обозначая её резаками) и всё, оставляя эту задачу Process'у? Я сужу по тому точно установленному на днях факту, что Draft kromsate ставит резаки не точно по контуру голого текста, а лишь по контуру упомянутой ранее "рабочей зоны" (наверное, это он просто грязь отсекает и всё). Значит, это именно Process находит контур голого текста, и подсчитывает средние размеры, а не Draft kromsate?

Вроде бы Вы именно так и писали:

Цитата:

важно: резаки не определяют размеры итоговой книги. (я так понял, что речь тут о Draft kromsate)
...
Обработать сканы (кнопка Process).
...
В итоге остается голый текст, без всяких полей.
...
После обработки всех страниц путем несложного статистического анализа определяется средняя ширина/высота книги.

Так что вроде бы это как бы понятно - но 100% уверенности пока нет.

Итак:

Определяет ли Draft kromsate точно контур голого текста, или ему на это плевать, и он только грязь распознаёт? (обозначая её резаками)

Цитата:

Зато я когда разберусь - обязуюсь разжевать всё в Пособии.

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

Добавил в Пособие http://www.dstu2204.narod.ru/djvu/kromsator/ (кусочками в соотв. места) содержимое файла http://www.dstu2204.narod.ru/djvu/kromsator/whatsnew_sc56a.htm . Также добавил туда же несколько скриншотов (окон, не замеченных ранее) плюс заменил несколько неправильных скриншотов.

Выложил старый хелп к Кромсатору: http://www.dstu2204.narod.ru/djvu/kromsator/help_v1.htm (ещё раз тщательно проверил его на совпадение с pdf-оригиналом). Старый хелп в формате Pdf выложил тоже: http://www.dstu2204.narod.ru/djvu/kromsator/sk_help1.rar (368 КБ).

Более упорядочил (по темам) советы по Кромсатору http://www.dstu2204.narod.ru/djvu/kromsator/sovety.htm . (Почему-то именно они пользуются наибольшей популярностью - судя по Яндекс-запросу "кромсатор").
romanef

Цитата:

освоение кромсатора методом тыка.

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

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

Конечно, я буду применять экспериментальные пути исследования Кромсатора. Но насколько всё это тогда растянется и какого качества будет тогда Пособие?

Всё равно, спрашивать bolega придётся, тут ничего не поделаешь. Конечно, надо стараться задавать эффективные вопросы, а не мелочные (это имхо всех касается ).

monday2000

Цитата:

Итак:

Определяет ли Draft kromsate точно контур голого текста, или ему на это плевать, и он только грязь распознаёт? (обозначая её резаками)

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

bolega

Цитата:

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

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

Попалась книжка, качество отличное, привлекло внимание наличие печати made with scankromsator .

bolega
Спасибо за объяснение такого важного вопроса!

Остались ещё вопросы, которые я уже писал:

Цитата:

Кстати, единственное, в чём я ВООБЩЕ не смог разобраться - это работа с Gray image enhance - из того, что есть, ни черта не удалось понять. Да и вообще надо для начала понять - что такое "контраст"? Это когда ставится порог, и всё, что светлее - светлеет, а всё, что темнее, темнеет? Как работать с гистограммой, что это за зверь?

Самое непонятное - что такое "Correct low contrast" и чем оно отличается от Contrast на вкладке Contrast? Каков принцип работы клинера? Ну и sensitivity - очень смутно представляю себе.

Что значат на вкладке Quality - Smooth, Blur, Sharpen? Впечатление такое, что это первоначальный вариант Gray image enhance, который просто забыли убрать.

Нельзя ли коротенько так и по-простому описать основные элементы управления на Gray image enhance? Сам я точно не смогу тут разобраться, и даже экспериментальным путём. Самое интересное - это вкладки Background cleaner, Contrast, Histogram - остальное можно пока не объяснять.

Это пока самые важные вопросы, т.к. самые неясные.

И ещё менее важные вопросы:

Цитата:

Ещё такой вопрос: После кромсания по кнопке Process Кромсатор вычисляет средние размеры и подставляет их в поля Book -> Page width [поле ввода] и Book -> Page height [поле ввода] (кстати, я ещё так не пробовал, интересно, так ли это). Затем Вы пишете, что "надо вручную переключиться с Page width (height) = Auto на Page width (height) = Fixed". А почему бы не сделать, чтобы это переключение осуществлялось автоматически после Process? (или пусть как ini-опция по-умолчанию будет).

И ещё вопрос: Зачем нужно Page width (height) = None, если можно поставить Page width (height) = Fixed и сбросить H.(V.) Gap value в ноль? Разве результат будет не точно таким же, как и при Page width (height) = None?

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

Добавлено:
bolega
Добавил эту информацию в http://www.dstu2204.narod.ru/djvu/kromsator/sovety.htm как совет № 5.

bolega

Цитата:

Melirius

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

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

Тогда ещё вариант - скан в 48bit, затем batch в Photoshop - Automatic Levels (Contrast, etc.)

Давайте ещё раз воспроизведём механизм обрезки кромсатором. Если я в чём-то ошибаюсь, поправьте меня.

Кромсатор расставляет резаки. По синему резаку: если поставлено cut&clear - обрезает в буквальном смысле слова всё, что за синим резаком, внутри от него ищет край текста, а оставшееся до края текста пространство чистит. По малиновому резаку - делает всё то же самое, но без поиска края текста - он задан положением резака (т. е. ничего внутри от резака не чистится). Если не поставлено cut&clear - тогда оставшееся до края текста пространство не чистится, а остаётся как в исходнике. Так?

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

Вопрос: я прав или что-то неверно?

monday2000

Цитата из пособия по кромсатору.



Цитата:

Page width - (Book page width calculation method)    Auto - Fixed (0-100000) - None    - Auto: После обработки книги, если было задано Page width = Page height = Auto (т.е. кромсатор сам определял итоговые размеры книги с учетом заданных полей gaps), кромсатор сам подставляет получившиеся размеры в соответствующие поля (как я понял - в поля H.Gap value и V.Gap value ?). После обработки нужно обязательно сменить Auto на Fixed, чтобы при переделке (т.е. повторном применении Draft Kromsate ? ) каких-то отдельных страниц их размер выдерживался равным итоговому размеру книги.

Рекомендую этот вопрос убрать, раз Вы с ним разобрались - я так понял из Ваших постов.

Цитата из советов


Цитата:

17. Как сделать, чтобы Кромсатор выдавал голый текст без полей на выходе?

Задайте параметры на вкладке Book:

H.Gap Value = 0, V.Gap Value = 0, Page width = Nonе и Page height = Nonе. по-моему, тут ошибка: ставить Page width = Nonе и Page height = Nonе не надо, достаточно выставить H.Gap Value = 0, V.Gap Value = 0.

Тут нет ошибки - если не ставить Page width = Nonе и Page height = Nonе, то Кромсатор будет вычислять средний размер страниц, а потом подгонит все страницы к нему, а не оставит как есть.


Цитата:

Что значат на вкладке Quality - Smooth, Blur, Sharpen? Впечатление такое, что это первоначальный вариант Gray image enhance, который просто забыли убрать.

Так они и для ч/б сканов работают, а не только для серых или цветных.

Melirius

Цитата:

а оставшееся до края текста пространство чистит.

Не чистит, а опять-таки обрезает, не так ли?

Если cut&clear и галка на резаке белая (не засерена), или Only cut, то обрезает по резаку, независимо от его цвета.
Если cut&clear и галка засерена, то ничего не обрезает, а чистит все, что за пределами засереного резака.

Melirius

Цитата:

а оставшееся до края текста пространство чистит

Нет, между краем страницы и краем текста ничего не чистит. Если не считать despeckle.
Ведь край текста невозможно определить с пиксельной точностью, поэтому и чистить ничего нельзя.
Итак, после обрезок ищется контур текста. К найденному контуру прибавляются поля. Лишнее снова обрезается, либо, наоборот, прибавляется недостающее. (На самом деле кромсатор выполняет все немного оптимальнее, но не суть важно, например, если с одного края - лишнее, а с другой - нехватает, то отрезка-прибавка заменится просто сдвигом).
В итоге получим на выходе страницы с нужными полями, но, с разными размерами.
Если задано pagewidth=none, то на этом все и заканчивается.
Если pagewidth=auto, то после обработки всех сканов высчитывается средний размер. Далее пробегаемся по всем страницам. Где нехватает - прибавляем (с учетом выравнивания), где лишнее - нет, не отрезаем, а анализируем: в зависимости от соотношения ширины поля и величины отреза принимается решение о том, как отрезать. Это чтобы не отрезать текст (бывают, и не редко, страницы с шириной, намного превосходящей среднюю ширину книги: например, широкие таблицы, вылазящие на поля, или такие же иллюстрации). Если окажется, что ширина отреза почти равна или превосходит ширину поля, то отрез равномерно распределяется по обе стороны страницы, если и этого будет много, то страница вообще не трогается, точнее, подрезается только на половину полей.

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

Melirius

Цитата:

Что значат на вкладке Quality - Smooth, Blur, Sharpen? Впечатление такое, что это первоначальный вариант Gray image enhance, который просто забыли убрать.

Так они и для ч/б сканов работают, а не только для серых или цветных.

Именно так. Я свои ч/б сканы (если хорошая печать в книге) всегда прогоняю через smooth - размер djvu после этого заметно падает.
Не помню, говорил, или нет (подозреваю, что нет), но как это ни покажется странным, значение Convert тоже играет большую роль для b/w-сканов! Играет, правда, только в двух случаях: при resample и при наличие этих самых smooth,blur,sharpen. При resample используется интерполирование, в результате которого, понятное дело, получается уже не чисто белый и черные цвета, а слегка или даже не очень, отличные от них. Но поскольку файл должен оставаться ч/б, то получившееся значение цвета тут-же переводится по порогу в ч. или б. Порог берется из Convert. Аналогично и для smooth,....

bolega

Цитата:

Я свои ч/б сканы (если хорошая печать в книге) всегда прогоняю через smooth - размер djvu после этого заметно падает.

А вот про это можно подробнее? Если включить для не очень хороших сканов, то что будет?

Judge_AK
Лучше всего самому попробовать
Бледные рассыпчатые буквы станут еще хуже, эффект будет как от despeckle, хотя и в меньшей степени. А для хороших букв слегка сгладит заусеницы.
exclude-зоны при задании smooth,... не трогаются.

Хотел на неделе выложить новую версию, но не получилось - очень загружен на работе, не знаю, когда освобожусь.

bolega
Есть ли способ быстро перейти в редактор постобработки? Скажем есть 700+ файлов, уже обрезаны и все такое (не мной), но остался всякий мелкий мусор, который удобнее всего чистить в постобработке. Я убрал despeckle, descew, automargins, выставил original в файлах на выходе (дпи и цвет), резаки тоже отключены. Но все равно СК пишет о том, что он рассчитывает какие-то поля, и обработка всех 700 файлов занимает минут 15 на моем компьютере. Есть ли более быстрый добраться до редактора постобработки?

vitaly1
А в закладке Book убрать Gap, выставить Page width(height) в None и снять галку с Use average width пробовали?

Judge_AK
Неа Разобрался, теперь гораздо быстрее. А все-таки, нет ли такой волшебной кнопочки, чтобы сразу в этот редактор попасть? Без того, чтобы снимать все эти галки.

vitaly1

Цитата:

А все-таки, нет ли такой волшебной кнопочки, чтобы сразу в этот редактор попасть?

Есть.
Гл. меню Result->Show source files. Только учтите, что чистка и прочие изменения будут выполняться непосредственно над исх.файлами.

bolega
Столкнулся в СканКромсаторе с таким неудобством:
Сканы книги заняли 2 гигабайта, записал их на три 700 мб RW-шки. Для обработки в кромсаторе приходится создавать 3 разных задачи под каждую RW-шкy, а хотелось бы это делать в рамках одной задачи. Сейчас же, добавив в задание сканы с первого RW, а затем с последующих, я буду иметь проблему с повторным открытием задачи. Программа, не найдя на СДРОМе какого-то файла выдаст окно "Обзор папок" и предложит либо выбрать путь, либо отменить выбор. После отмены выдается предупреждение с возможностью выбора "ОК" - remove file from task, "No" - do not remove file и "Cancel" - stop loading task. Теперь после выбора варианта "No" выполняются те же действия по следующему отсутствующему на СДРОМе скану.
Хорошо бы здесь сделать пропуск всех файлов, которые выбираются по этому пути, т.е. пусть они появятся в окне файлов, тогда можно обрабатывать те сканы, которые есть на RW, а при обращении к отсутствующему скану выдается ошибка с возможностью продолжения работы программы. Тогда можно будет распространять параметры обрабатываемых сканов на отсутствующие в данный момент.
Наговорил много и сумбурно, но надеюсь, что мысль ясна

Melirius

Цитата:

Рекомендую этот вопрос убрать

Спасибо, уберу, и про None подправлю, только не сразу, а через некоторое время, т.к. буду стараться теперь накапливать и оптом вносить изменения, а ещё я именно этот момент хочу экспериментально проверить.

Цитата:

Тут нет ошибки - если не ставить Page width = Nonе и Page height = Nonе

Судя по этой фразе

Цитата:

В итоге получим на выходе страницы с нужными полями, но, с разными размерами.
Если задано pagewidth=none, то на этом все и заканчивается.

получается, что наоборот, ставить H.Gap Value = 0, V.Gap Value = 0 не надо, достаточно выставить Page width = Nonе и Page height = Nonе, правильно?

Цитата:

Так они и для ч/б сканов работают, а не только для серых или цветных.

Этого я не знал. Кстати, там справа от Smooth-Blur-Sharpen окошки с циферками (1-5) (между прочим, тесновато налеплены - из-за вынужденной экономии места, что можно решить слиянием вкладок в большие вызываемые вкладки) - это кол-ва проходов обработки Smooth-Blur-Sharpen, как я понял (совет №39):

Цитата:

В действительности кромсатор сглаживает форму букв. Но для этого надо включить опцию Enhance.Smooth и задать кол-во проходов (1-3).

Цитата:

Давайте ещё раз воспроизведём механизм обрезки кромсатором. Если я в чём-то ошибаюсь, поправьте меня.

Вот об этом я как раз на днях допытывался у bolega:

Цитата:

задача драфта - расставить резаки так, как это бы сделал человек. Учитывая, что назначение резаков - отсекать грязь, то и драфт соответственно делает именно это.

Я бы так сказал: Draft kromsate "грубо" распознаёт, где грязь, а где текст, и ставит между ними резаки-разделители (при Automargins=on). В общем, Draft kromsate гораздо больше интересует грязь, нежели текст (хотя полностью про текст он тоже не забывает, т.к. старается в текст не влепить резак). Кстати, я вот предлагал переименовать Draft kromsate в "Auto pre-kromsate" для понятности.

А вот чтобы ТОЧНО определить контур голого текста внутри резаков, расставленных Draft kromsate'ом, мы уже запускаем Process (это и есть само кромсание).

Только до запуска Process'а нужно вручную подправить погрешности работы Draft kromsate'а - путём подправления нужных резаков и сброса их подгалок в Automargins=off - причём это по сути делается чисто "силовым" путём: на самом деле тут ведь не результаты работы Draft kromsate'а подправляются (это был бы идеальный подход, но реально очень трудноосуществимый), а вносятся заведомые поправки для будущей работы Process'а (который мы запустим после внесения этих поправок и поправки повлияют именно на Process)
bolega

Цитата:

Если cut&clear и галка засерена, то ничего не обрезает, а чистит все, что за пределами засереного резака.

Интересно, а зачем это вообще может быть кому-то нужно? Для сканеров с автоподатчиком?

Цитата:

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

Не совсем ясно. Я так понимаю, что контур голого текста (который находит Process) - это прямоугольник с гор.-верт. сторонами, максимально плотно описанный вокруг реального текста на скане, правильно?

Цитата:

В заключение хочу еще раз обратить внимание на то, что automarging с гапами и pagewidth type - это совершенно разные, независимые, вещи.

Важная подробность, спасибо. Хорошо бы, кстати, эту двухэтапность отобразить в интерфейсе, чтобы чайнику было интуитивно ясно, что тут имеется 2 этапа обработки. Буду думать, что предложить конкретно. Вот если бы Вы сделали слияние вкладок в большие + вызов их (по кнопке или т.п.), то там можно было бы проще такую вещь сделать, т.к. простора больше было бы.

Цитата:

Хотел на неделе выложить новую версию, но не получилось

Такие мини-пожелания: нельзя ли на вкладке Files в поле DPI изменить умолчание с "300 dpi" на "Original"? И ещё там я просил по возможности подровнять 2 вещи: элементы управления в Task options settings и в Result view статус-бар куда-то вниз уехал - хорошо бы подправить. И ещё такая мелочь: в Result view окно Rotate selection ( http://www.dstu2204.narod.ru/djvu/kromsator/131.gif ) имеет 3 недостатка:
1. Появляется не по центру Result view, а уехав вниз-вправо.
2. Вообще имеет зачем-то гигантский размер.
3. Имеет название почему-то "Form19".
И ещё: Options 2 -> Cutters state: Вы как-то писали, что планируете убрать cut&clear t/b, может, сейчас момент подходящий?
shch_vg

Цитата:

Столкнулся в СканКромсаторе с таким неудобством:

Имхо не самая лучшая идея просить bolega реализовывать фичи, имеющие крайне далёкое отношение к скан-обработке. Давайте ценить чужое время и силы. Вашу проблему можно удовлетворительно решить так: перегнать сканы в CCIT FAX G4 (т.е. ч.б. битовый малого размера) через Irfan View или частями через Кромсатор (что лучше, т.к. можно порог подобрать). Да, понятно, качество их немного ухудшится - но зато не надо новый бОльший винт покупать, а задача обработки сканов Кромсатором так худо-бедно, но решается.

monday2000

Цитата:

перегнать сканы в CCIT FAX G4

Как можно понять из того что у shch_vg получилось 2 гига, то это серые сканы в 300 дпи без сжатия, посему перегонять их до обработки в CCIT FAX G4 значит всю работу портить. Вроде бы кромсатор поддерживает тифы со сжатием LZW, но тут я не уверен, просто надо попробовать.

VadimirTT

Цитата:

Вроде бы кромсатор поддерживает тифы со сжатием LZW

Да, bolega совсем недавно говорил, что не только поддерживает, но и обрабатывает быстрее. В том же VueScan, кстати, есть возможность паковать RAW-tiff'ы (если речь о них).
А с неудобством, описанным shch_vg, я тоже встречался, и считаю, что это имеет прямое отношение к обработке сканов

VadimirTT

Цитата:

Как можно понять из того что у shch_vg получилось 2 гига, то это серые сканы в 300 дпи без сжатия

Это серые сканы в 600 дпи со сжатием ( ghosty прав, они получены во VueScan ), причем книга все лишь 200 стр.

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

bolega

Цитата:

Но Вы подали мне одну идею: если резак двигать например с нажатым Shift, то кромсатор автоматически бы сбрасывал бы под-опцию automargins, все ж меньше щелкать.

Вопрос
А почему это не организовать вообще без шифта?
Ведь если я трогаю резак, значит что-то там не так на автомате и пользователь знает что делает? (я надеюсь) Или для этого есть какая-то причина?
От себя замечу,что уже сейчас работа с кромсатором похожа на игру на пианино

Кстати, есть где нибудь список всех short-hotkeys?

bolega

Цитата:

Кстати, есть где нибудь список всех short-hotkeys?

Присоединяюсь! Уваwаемый BOLEGA, может сделаете, это все-таки не то, что
полную доку писать...

bolega

terminat0r согласен, то же самое и я хотел уточнить.

Вроде в новой версии список полностью настраиваемый будет.

dimaniac

Цитата:

Вроде в новой версии список полностью настраиваемый будет.

Интересно .Когда выйдет?