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

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

Я вернулся.

shch_vg

Цитата:

Было бы удобно, если бы при крестообразном курсоре на перемещаемом фрагменте с помощью стрелок вверх, вниз, влево и вправо попиксельно можно было бы смещать фрагмент в нужном направлении

Вставленный фрагмент можно перемещать с помощью Ctrl-стрелки. Шаг перемещения кромсатор выбирает в зависимости от zoom, чем он больше, тем точнее будет сдвиг

badbug
Page->Special->Ignore gaps. Тогда не будет учитываться, но и поля прибавляться не будут. И действует на весь текущий файл, т.е. на левую и правую половинки. Но это не страшно, в постобработке размеры другой половинки можно быстро довести до размера книги: (в view result) special->resize->book size

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

Я в свое время разбирался с извлечением изображений из PDF, перепробовал несколько утилит и в результате остановился на "PDF To Image Converter v1.3"

У Болеги появилась новая версия СканКромсатора (Ver 5.81 NY), насколько я понял. Вот источник http://bolega.hotmail.ru/Ver%205.81%20NY/sk.rar . Скачал архив, а он запаролен, никто не подскажет пароль?

57 стр.

Добавлено:
Кстати, версии уже полгода

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

Насколько я знаю, нет. Кто-то выкладывал русификатор, но не автор.

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

Сделал мерцание спеклов, как просил Alexx S. На слабых компах лучше не использовать.

Потестирую еще 2-3 недели и тогда выложу новую версию (5.9) для всеобщего тестирования

bolega

Цитата:

Сделал мерцание спеклов, как просил shch_vg. На слабых компах лучше не использовать.

Неправда, это я просил!!!
Спасибо большое, а то с этими спеклами мистика какая-то. Последнюю книгу простматривал раза четыре, на разных масштабах, впролоть до 75% (при 600дпи) - и все равное, в готовой спеклы нахожу...

А будет в новой версии изменение размеров полей, о котором мы говорили? И Blur с Denoise очень хотелось бы...

Alexx S

Цитата:

Неправда, это я просил!!!

Извините.


Цитата:

Спасибо большое, а то с этими спеклами мистика какая-то

У меня такая же история.


Цитата:

А будет в новой версии изменение размеров полей, о котором мы говорили?

Напомните, пожалуйста, на какой странице говорили.


Цитата:

Denoise

Его не будет, слишком пока медленный. Все остальные фильтры уже включил

bolega

Цитата:

Напомните, пожалуйста, на какой странице говорили.

Предложение здесь:
http://forum.ru-board.com/topic.cgi?forum=5&topic=15877&start=1220#3



Цитата:

Его не будет, слишком пока медленный.

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


Цитата:

Все остальные фильтры уже включил

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

bolega

Цитата:

Потестирую еще 2-3 недели и тогда выложу новую версию (5.9) для всеобщего тестирования

йохохо и бутылка рома!
Ждем!

Alexx S

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

Цитата:

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

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



Добавлено:
То, что вы предлагаете, равносильно кромсанию в 2 этапа. На первом этапе все делается как сейчас. Затем почищенные выходные файлы подаются на вход 2-го задания, в котором отключены все опции и резаки, кроме automargins и выравнивания страниц. Последнее можно сделать, чтобы автоматом переходило в новое задание из 1-го, а вот малиновые резаки придется задавать по новой.

Цитата:

То, что вы предлагаете, равносильно кромсанию в 2 этапа. На первом этапе все делается как сейчас. Затем почищенные выходные файлы подаются на вход 2-го задания, в котором отключены все опции и резаки, кроме automargins и выравнивания страниц. Последнее можно сделать, чтобы автоматом переходило в новое задание из 1-го, а вот малиновые резаки придется задавать по новой.

Я после отпуска пока не в силах выйти на столь высокий уровень абстрагирования Но первое, что приходит в голову: чтобы избавить пользователей от необходимости предварительного кромсания 10-20 страниц для определения "fixed" размеров, можно ввести функцию (что-то вроде) "Compute (Get) fixed width" и "Compute fixed hight" - кнопки рядом с соответствующими полями. При выполнении такой функции Кромсатор случайным образом составлял бы "репрезентативную" выборку из страниц, и вычислял соотв. размер, исходя из среднего арифметического по выборке и заданного пользователем разрешения апсемплинга.
То есть все расчеты проводятся без обработки.
Было бы хорошо ввести также "Compute fixed width/hight using..." -> selected /bold selected...

ghosty

Цитата:

При выполнении такой функции Кромсатор случайным образом составлял бы "репрезентативную" выборку из страниц

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

"Compute fixed width/hight using..." -> selected /bold selected...

Если для этой выборки не делать выходных файлов (т.е. реально ничего не обрабатывать, а просто посчитать), то это можно сделать очень быстро. Только что потом делать с этими fixed, как убедиться, что они подходят для всех страниц.

Кроме того, Alexx S противник именно предварительного расчета fixed, он хочет, чтобы кромсатор сперва просто обрезал по резакам, не прибавляя полей. И только потом, после чистки, по команде искать контур, прибавлять поля и считать размеры. Поэтому я и говорю, что это равносильно и можно сделать просто двумя заданиями, убрав во 2-м задании все, что касается растровой обработки (всякие enhance, deskew, despeckle и т.д.).

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


Цитата:

То, что вы предлагаете, равносильно кромсанию в 2 этапа. На первом этапе все делается как сейчас. Затем почищенные выходные файлы подаются на вход 2-го задания, в котором отключены все опции и резаки, кроме automargins и выравнивания страниц. Последнее можно сделать, чтобы автоматом переходило в новое задание из 1-го, а вот малиновые резаки придется задавать по новой.

Вроде да, все так... В сочетании с тем, что раньше говорилось:


Цитата:

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

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

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

bolega

Цитата:

Кроме того, Alexx S противник именно предварительного расчета fixed

Да мы все тут противники, просто нужно решить, как с этим бороться

Цитата:

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

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

Цитата:

Только что потом делать с этими fixed, как убедиться, что они подходят для всех страниц.

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

ghosty

Цитата:

К примеру, так: из 100 страниц выбираются страницы с наибольшими размерами

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


Цитата:

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

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

bolega
Головоломка

Цитата:

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

А что Вы тогда имели в виду в этом случае:
Цитата:

Если для этой выборки не делать выходных файлов (т.е. реально ничего не обрабатывать, а просто посчитать), то это можно сделать очень быстро.

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

Цитата:

Могу сказать однозначно: отображать контуры полей на исходных сканах я не буду.

Нет, не надо. Опять забыл, извините.

bolega

Цитата:

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

А если взять медиану?

ghosty

Цитата:

А что Вы тогда имели в виду в этом случае

Это просто. Для определения контуров можно сделать как бы псевдо-обработку, используя упрощенные, но быстрые методы, т.е. fast rotate, fast resample, не сохранять файл на диск и т.д. Это заметно увеличит скорость обработки. Погрешность конечно это внесет, небольшую (3-5 пикселей), но для определения средних размеров это абсолютно несущественно.
Вопрос в другом: что дальше делать с этими fixed. И чем это лучше, например, того, что я использую часто - определяю fixed по первым 20-30 файлам. Только в данном случае я одновременно по выходным файлам могу убедиться, что подсчитанный fixed меня устраивает или нет. Если Вы скажете, что 1-й вариант имеет преимущества, то, я сделаю его. No problem.

U235
Примерно так и делается сейчас, только если страниц, которые по размеру отличаются от среднего в большую сторону, не очень мало (>5%), то кромсатор делает небольшую поправку к среднему

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

bolega

Цитата:

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

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

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

Alexx S

Цитата:

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

Это должно зависеть от значений v.align/h.align. Точку задавать не нужно.


Цитата:

В моем понимании, неплохо бы иметь это отдельной кнопкой - нажал, подождал какое-то время

Ага, часов этак 2-3 подождал... Господа, сканы - это же не векторный word в конце концов!

bolega

Цитата:

Я склоняюсь к такому решению: добавить команды "увеличить выходные размеры на столько-то" и "уменьшить выходные размеры на столько-то".

Эти команды могут быть выполнены на этапе постобработки?
Цитата:

Если Вы скажете, что 1-й вариант имеет преимущества, то, я сделаю его. No problem.

Если так, то почему бы не попробовать. Если этот вариант не будет давать сбоев, то оставим...

Цитата:

Только в данном случае я одновременно по выходным файлам могу убедиться, что подсчитанный fixed меня устраивает или нет.

Опять-таки только по выходным (обработанным) файлам. Вы говорили, насколько я понял, проблема состоит в невозможности проверить остальные страницы. После автоматического подсчета fixed размеров, можно их проверить на 2-5 файлах - но это же не 20-30...
С другой стороны можно предложить вот, что: две функции: "calculate fixed w/h fast" и "calculate fixed w/h with processing". Второй вариант предлагаю делать так: выбранные страницы обрабатываются не с пользовательскими настройками, а с самыми быстрыми, т.е. без лишних алгоритмов обработки, только апсемплинг, если есть, и тот по самому быстрому алгоритму. На полученных при этом страницах можно наносить надпись "Проба", чтобы человек не включил эти страницы в проект по ошибке, либо эти страницы сохранять в системную папку "TEMP".
Просто пытаюсь решить проблему, которая была поставлена не мной, на самом деле. Мне, к примеру, предварительная обработка 10-15 файлов нужна для того, чтобы еще раз убедиться, что установлены оптимальные параметры обработки.

bolega

Цитата:

Ага, часов этак 2-3 подождал... Господа, сканы - это же не векторный word в конце концов!

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

Да и вообще, предложение звучало совсем по другому. Да, заранее посчитать ширину страницы было бы не прлохо, но обычный алгоритм дейсвий такой
1. Кромсаем
3. Поворачиваем
4. Апсемплинг
5. Бинаризуем

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


Добавлено:
ghosty
Ответь, плз на личку

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

bolega

Цитата:

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

Если такая команда будет, и если это не приведет к ошибочному отрезанию блоков текста, то да, снимет.
Хотя сомнения остаются. Например, увеличение/уменьшение размеров должно производиться не просто так, а с учетом заданных пользователем параметров Page h/v align, правильно? Наверно, будут и еще какие-нибудь проблемы, если fixed размеры определены были неверно. К примеру, человек задал слишком большую fixed width и h. align = L. В этом случае поля будут смотреться некрасиво - слишком ассиметрично. Тогда было бы хорошо как-то исправить эту оплошность на этапе постобработки, т.е. изменять размеры полей не равным образом относительно блока текста, а со сдвигом, чтобы поля стали симметричными...
Я с такой проблемой сталкивался не раз.

Добавлено:
Alexx S

Цитата:

Ответь, плз на личку

Приехав, обнаружил много писем в личках, имейлах и т.п. Разбираюсь понемногу

Добавлено:
В версии NY в функции Process half-page - баг: обрабатываем половинку, затем переходим на любой файл выше в списке, снова обрабатываем половинку. При этом обрабатывается файл, обработанный ранее.

Маленький обучающий ролик о том, как бороться с подчеркиваниями при помощи Кромсатора. Будет интересен как новичкам, так и, возможно, опытным пользователям. Вначале применяется Auto-Clear (чтобы "отцепить" линию от буквы), затем Ctrl-Shift-Click по линии, которую следует убрать.
URL1: http://rapidshare.com/files/44788648/Kromsator.rar.html
URL2: http://rapidshare.com/files/44803886/Kromsator.zip.html

Выложите, пожалуйста, в зипе - проблемы со скачиванием рар-ов. Спасибо