ghosty Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору ScanKromsator: Знаменитый Кромсатор для обрезки получаемых при сканировании изображений, а также для разделения страниц, очистки от мусора и т.п. (есть FAQ). Автор: bolega. http://bolega.hotmail.ru/   Старые версии:   5.52beta (1,81 МБ) + dll-ки, необходимые для работы программы (405 КБ)   Full-версии - вкл. dll-библиотеки и Help к SK v1.0 в формате Pdf:   v3.5 (1,52 МБ)  v5.07 (1,98 МБ)  v5.51b (2,06 МБ)  v5.52b (2,05 МБ)     Текущая версия:   ScanKromsator v5.6А Full (вкл. dll-библиотеки и Help к SK v1.0 в формате Pdf). (2,25 МБ) What's new  Зеркало   Хелп v1.0 для Кромсатора:   1. В формате PDF: http://rapidshare.de/files/1815394/ScanKromsator.pdf.html (размещен временно):   2. В форматах HTM и DOC: http://www.djvu-soft.narod.ru/sk_doc_htm_help_v1_0.rar  (537 КБ)   Вопросы и ответы по работе со СканКромсатором последних версий: http://abab.front.ru/QandA_SK.zip (80 КБ, от 20.06.06)   Пособие по Кромсатору: http://www.djvu-soft.narod.ru/kromsator/ (Составлено на базе "Вопросов и ответов" + Хелп v1.0).  См. подробности.   ScanAndShare - инструкция в картинках, в том числе и начальные установки SK 1.03 или 1.06 Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 12:53 17-05-2005 | Исправлено: vitaly1, 16:02 10-01-2007

Alexx S Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору bolega Цитата: Сделал мерцание спеклов, как просил shch_vg. На слабых компах лучше не использовать. Неправда, это я просил!!! Спасибо большое, а то с этими спеклами мистика какая-то. Последнюю книгу простматривал раза четыре, на разных масштабах, впролоть до 75% (при 600дпи) - и все равное, в готовой спеклы нахожу...   А будет в новой версии изменение размеров полей, о котором мы говорили? И Blur с  Denoise очень хотелось бы... Всего записей: 1580 | Зарегистр. 15-04-2004 | Отправлено: 13:12 21-07-2007

Alexx S Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору bolega Цитата: Напомните, пожалуйста, на какой странице говорили. Предложение здесь: http://forum.ru-board.com/topic.cgi?forum=5&topic=15877&start=1220#3     Цитата: Его не будет, слишком пока медленный.     Жалко... Меня бы устроил и десяток страниц в час, уж больно хорошо получается...   Цитата: Все остальные фильтры уже включил Все остальные - это очень  даже хорошо. Может, тогда пример сделаете с применением размытия и контурной резкости? Всего записей: 1580 | Зарегистр. 15-04-2004 | Отправлено: 17:05 21-07-2007

terminat0r Silver Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору bolega Цитата: Потестирую еще 2-3 недели и тогда выложу новую версию (5.9) для всеобщего тестирования йохохо и бутылка рома! Ждем! Всего записей: 2084 | Зарегистр. 31-03-2002 | Отправлено: 20:26 21-07-2007

ghosty Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Цитата: То, что вы предлагаете, равносильно кромсанию в 2 этапа. На первом этапе все делается как сейчас. Затем почищенные выходные файлы подаются на вход 2-го задания, в котором отключены все опции и резаки, кроме automargins и выравнивания страниц. Последнее можно сделать, чтобы автоматом переходило в новое задание из 1-го, а вот малиновые резаки придется задавать по новой. Я после отпуска пока не в силах выйти на столь высокий уровень абстрагирования Но первое, что приходит в голову: чтобы избавить пользователей от необходимости предварительного кромсания 10-20 страниц для определения "fixed" размеров, можно ввести функцию (что-то вроде) "Compute (Get) fixed width" и "Compute fixed hight" - кнопки рядом с соответствующими полями. При выполнении такой функции Кромсатор случайным образом составлял бы "репрезентативную" выборку из страниц, и вычислял соотв. размер, исходя из среднего арифметического по выборке и заданного пользователем разрешения апсемплинга. То есть все расчеты проводятся без обработки. Было бы хорошо ввести также "Compute fixed width/hight using..." -> selected /bold selected... ---------- пропадет-растает Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 18:52 23-07-2007 | Исправлено: ghosty, 18:53 23-07-2007

Alexx S Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору bolega Честно говоря, я уже с трудом вспоминаю свой ход мыслей по этому поводу. Вообще-то, самое-самое первое пожелание было таким - если я в текущем задании изменил значение поля, то хотелось бы одним нажатием кнопки подогнать размер результирующих страниц по него.   Или самы простой вариант - поля, какие есть в любой граф. программе, прибавить, убавить и т.п.   Цитата: То, что вы предлагаете, равносильно кромсанию в 2 этапа. На первом этапе все делается как сейчас. Затем почищенные выходные файлы подаются на вход 2-го задания, в котором отключены все опции и резаки, кроме automargins и выравнивания страниц. Последнее можно сделать, чтобы автоматом переходило в новое задание из 1-го, а вот малиновые резаки придется задавать по новой.   Вроде да, все так... В сочетании с тем, что раньше говорилось:   Цитата: Цитата:Все, что я прошу - это возможность переделки полей. Автоматического определения области текста не надо - если мусор и помешал, выровнять такую страницу можно и вручную     Нет, как раз автоматически это сделать не сложно. Ведь сканы уже будут вычищенные, и можно применить упрощенный, но более быстрый и надежный способ по новой определить контур. Это не проблема.   Т.е. малиновые уже не имеют значение. В вот с расстановвкой резаков по-новой сложнее, тут как раз нужно будет просматривать все задание, да и зачем? Резаки уже есть ведь, надо только их повернуть вместе с изображением и повигать если применялся сдвиг текста. И даже если этого не делать, то можно ориентироватся исключительно на пустое пространство - резаки-то уже все порезали   Всего записей: 1580 | Зарегистр. 15-04-2004 | Отправлено: 19:54 23-07-2007

ghosty Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору bolega Цитата: Кроме того, Alexx S противник именно предварительного расчета fixed Да мы все тут противники, просто нужно решить, как с этим бороться Цитата: Не пойдет, в эту выборку может попасть страница, состоящая из 2-3-х строк, которая из среднего арифметического сделает полную ерунду. Поэтому я и говорил о "репрезентативности". К примеру, так: из 100 страниц выбираются страницы с наибольшими размерами и разбросом этих значений меньше заданного, затем вычисляется среднее арифметическое. Хотя если попадутся одинаковые артефакты какие-нибудь на полях, которые одинаковым образом будут влиять на определение границы текста, может закрасться ошибка, но это как-то маловероятно... Цитата: Только что потом делать с этими fixed, как убедиться, что они подходят для всех страниц. Да, но мы и в случае предварительного кромсания 10-20 страниц не можем гарантировать, что посчитали эти размеры правильно. Поэтому предлагаю убить двух зайцев сразу - отображать рассчитанную границу непосредственно на сырых сканах (сделав обратный перерасчет с учетом апсемплинга). Тогда можно будет увидеть, что будет отрезано, на каждой странице. ---------- пропадет-растает Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 00:52 24-07-2007 | Исправлено: ghosty, 00:52 24-07-2007

ghosty Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору bolega Головоломка Цитата: Чтобы выбрать наибольшие размеры (не страниц, а контуров текста на них), придется все эти 100 страниц обработать. А что Вы тогда имели в виду в этом случае: Цитата: Если для этой выборки не делать выходных файлов (т.е. реально ничего не обрабатывать, а просто посчитать), то это можно сделать очень быстро. Т.е. не совсем понятно, почему ср. арифметическое посчитать можно, а наибольшие размеры определить нельзя... Цитата: Могу сказать однозначно: отображать контуры полей на исходных сканах я не буду.   Нет, не надо. Опять забыл, извините. ---------- пропадет-растает Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 03:23 24-07-2007

Alexx S Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору bolega Цитата: Я склоняюсь к такому решению: добавить команды "увеличить выходные размеры на столько-то" и "уменьшить выходные размеры на столько-то". С первым все просто. Со вторым сложнее - придется контролировать границы текста, и если есть угроза отрезания его, ничего не делать и метить такие файлы жирным. Еще неплохо бы задавать точку, из которой делается увеличение - из центра, из угла и тп.     По поводу определения полей я нить потерял . В моем понимании, неплохо бы иметь это отдельной кнопкой - нажал, подождал какое-то время и получил информацию о среднем ( а можно и о максимальном и минимальном) размере текста. Ввел округленное значение в поле фиксед и вперед. Опять же, не понравились поля, решил переделать - переделал без повторной расстановки резаков и т.п. Всего записей: 1580 | Зарегистр. 15-04-2004 | Отправлено: 11:15 24-07-2007

ghosty Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору bolega Цитата: Я склоняюсь к такому решению: добавить команды "увеличить выходные размеры на столько-то" и "уменьшить выходные размеры на столько-то". Эти команды могут быть выполнены на этапе постобработки? Цитата: Если Вы скажете, что 1-й вариант имеет преимущества, то, я сделаю его. No problem. Если так, то почему бы не попробовать. Если этот вариант не будет давать сбоев, то оставим... Цитата: Только в данном случае я одновременно по выходным файлам могу убедиться, что подсчитанный fixed меня устраивает или нет. Опять-таки только по выходным (обработанным) файлам. Вы говорили, насколько я понял, проблема состоит в невозможности проверить остальные страницы. После автоматического подсчета fixed размеров, можно их проверить на 2-5 файлах - но это же не 20-30... С другой стороны можно предложить вот, что: две функции: "calculate fixed w/h fast" и "calculate fixed w/h with processing". Второй вариант предлагаю делать так: выбранные страницы обрабатываются не с пользовательскими настройками, а с самыми быстрыми, т.е. без лишних алгоритмов обработки, только апсемплинг, если есть, и тот по самому быстрому алгоритму. На полученных при этом страницах можно наносить надпись "Проба", чтобы человек не включил эти страницы в проект по ошибке, либо эти страницы сохранять в системную папку "TEMP". Просто пытаюсь решить проблему, которая была поставлена не мной, на самом деле. Мне, к примеру, предварительная обработка 10-15 файлов нужна для того, чтобы еще раз убедиться, что установлены оптимальные параметры обработки. ---------- пропадет-растает Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 15:56 24-07-2007

Alexx S Advanced Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору bolega Цитата: Ага, часов этак 2-3 подождал... Господа, сканы - это же не векторный word в конце концов! Да это понятно, но можно некоторые трудоемкие задачи исключить - тот же апсемплинг, к примеру.   Да и вообще, предложение звучало совсем по другому. Да, заранее посчитать ширину страницы было бы не прлохо, но обычный алгоритм дейсвий такой 1. Кромсаем 3. Поворачиваем 4. Апсемплинг 5. Бинаризуем   На всех этих этапах нам поля не важны совершенно, мы занимаемся вопросами обработки, поля же - это уже этап оформления книги.   Во время выполнения этих этапов мы и собираем иформацию для определения ширины страниц. На данный момент кромсатор сам определяет ширину страницы, я в это вмешаться не могу.   Вот и хотелось бы, чтобы на предварительных этапах осуществлялся сбор информации, после чистки информация уточнялась бы по упрощенным методам (я почистил мусор, это надо учесть) и пользуясь этой информацией я бы сам определял результирующий размер страницы. Опять же, пиксели это одно, а реальная книга другое. Поэтому и поля хотелось бы менять на лету. Опять же, анализа никакого не надо - все уже есть.     Добавлено: ghosty Ответь, плз на личку Всего записей: 1580 | Зарегистр. 15-04-2004 | Отправлено: 16:28 24-07-2007

bolega Silver Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору ghosty Я уже сам начинаю забывать, зачем все это нужно делать (лично я никогда таких проблем не имел, поэтому до конца понять не могу)   Все, что я знаю, это была такая проблема: книга обработана, и вдруг видим, что поля оказались слишком большими или наоборот. Все, что надо сделать, это или увеличить их, или уменьшить. Мудрствование же с определением fixed - по моему, от лукавого и никому не нужно. Я часто определяю его только лишь по одному скану, выбираю самую заполненную текстом страницу, и не нужно никаких лишних расчетов. Если же окажется, что полученный размер все-таки не удовлетворяет, то наличие команды по изменению размеров уже обработанных файлов думаю полностью снимет проблему. Всего записей: 4571 | Зарегистр. 09-09-2002 | Отправлено: 16:46 24-07-2007

ghosty Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору bolega Цитата: Если же окажется, что полученный размер все-таки не удовлетворяет, то наличие команды по изменению размеров уже обработанных файлов думаю полностью снимет проблему. Если такая команда будет, и если это не приведет к ошибочному отрезанию блоков текста, то да, снимет.   Хотя сомнения остаются. Например, увеличение/уменьшение размеров должно производиться не просто так, а с учетом заданных пользователем параметров Page h/v align, правильно? Наверно, будут и еще какие-нибудь проблемы, если fixed размеры определены были неверно. К примеру, человек задал слишком большую fixed width и h. align = L. В этом случае поля будут смотреться некрасиво - слишком ассиметрично. Тогда было бы хорошо как-то исправить эту оплошность на этапе постобработки, т.е. изменять размеры полей не равным образом относительно блока текста, а со сдвигом, чтобы поля стали симметричными... Я с такой проблемой сталкивался не раз.   Добавлено: Alexx S Цитата: Ответь, плз на личку Приехав, обнаружил много писем в личках, имейлах и т.п. Разбираюсь понемногу   Добавлено: В версии NY в функции Process half-page - баг: обрабатываем половинку, затем переходим на любой файл выше в списке, снова обрабатываем половинку. При этом обрабатывается файл, обработанный ранее. ---------- пропадет-растает Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 17:02 24-07-2007 | Исправлено: ghosty, 17:11 24-07-2007

ghosty Gold Member Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору Маленький обучающий ролик о том, как бороться с подчеркиваниями при помощи Кромсатора. Будет интересен как новичкам, так и, возможно, опытным пользователям. Вначале применяется Auto-Clear (чтобы "отцепить" линию от буквы), затем Ctrl-Shift-Click по линии, которую следует убрать. URL1: http://rapidshare.com/files/44788648/Kromsator.rar.html URL2: http://rapidshare.com/files/44803886/Kromsator.zip.html ---------- пропадет-растает Всего записей: 6808 | Зарегистр. 21-09-2002 | Отправлено: 21:54 24-07-2007 | Исправлено: ghosty, 23:22 24-07-2007

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

Компьютерный форум Ru.Board » Компьютеры » Программы » ScanKromsator СканКромсатор

Widok (17-08-2007 15:16): лимит страниц. продолжаем здесь

Переход по форумам  Закладки   » Компьютеры Цифровое изображение Программы Microsoft Windows UNIX Другие OS Hardware В помощь сисадмину Прикладное программирование Игры Форумные игры   » Интернет Web-программирование В помощь вебмастеру Графика Хостинг Зацените-ка!   » Тематические Ikonboard v.2 Ikonboard v.3 Invision Board Другие форумы PHP-Nuke и другие порталы Мобила   » Общие Спорт Флейм Темы по региональным встречам Музыка и Кино Юмор Литература и Живопись   » Ru.Board Новости Помощь по форуму   » Андеграунд eBookz Варезник Раздачи и акции Мобильный варезник Андеграунд Игры и фильмы   » Специальные Тестирование