» Scan Tailor: Часть 2

StanFreeWareСовершенно верно, это второй и возможно главный фактор, который надо учитывать, если корректировать Полезную зону после Вывода.Благодарю!
Цитата:

это случайно не уменьшить полезную область для самой высокой/широкой страницы

PS И так: А)Стандартная методология.
1)Прогнать обработку на Автомате включая Макет.
2) Просмотреть Полезную зону и откорректировать, дабы все что надо туда попало.
3) Откорректировать по необходимости Макет
4) Сделать Вывод на автомате
5) Просмотреть Вывод и без изменения Полезной зоны откорректировать параметры Вывода
Б) Укороченная
1) На нескольких страницах определиться с соотношением полезной зоны и макета
2) Сделать Вывод на автомате
3) Просмотреть Вывод. При необходимости корректировать и Полезную зону и параметры Вывода
Но!!!
- случайно не уменьшить полезную область для самой высокой/широкой страницы
- при корректировке иных страниц контролировать, что нет выхода ПЗ за пределы самой высокой/широкой страницы

Tulon В связи с этим несколько замечаний для Укороченной методики. 1) Нельзя ли искать не только самую высокую/широкую, но и самую маленькую Полезную зону - это как правило неправильно определенная на автомате, обрезанная зона. Это надеюсь ускорит их поиск и исправление при необходимости (вроде этот вопрос уже поднимался в несколько иной транскрипции). 2) Нельзя ли в Макете поставить галку - Зафиксировать максимальный Макет, чтобы после этого корректировки Полезной зоны не выходили за его пределы и Вывод не будет сбиваться. Или как-то по иному решить эту беду

Цитата:

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

Возможно тогда стоить выводить предупреждение в СТ? Или подкрашивать 2 (самая высокая и широкая) страницы справа в предпросмотре?

alpopo

Цитата:

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

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


Цитата:

2) Нельзя ли в Макете поставить галку - Зафиксировать максимальный Макет, чтобы после этого корректировки Полезной зоны не выходили за его пределы и Вывод не будет сбиваться. Или как-то по иному решить эту беду

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

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

terminat0r

Цитата:

Возможно тогда стоить выводить предупреждение в СТ? Или подкрашивать 2 (самая высокая и широкая) страницы справа в предпросмотре?

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

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

are, не могли бы вы кинуть ссылку на русскую инструкцию?

Цитата:

are, не могли бы вы кинуть ссылку на русскую инструкцию?

нет, русская есть только scan&share 1.07, без ST.

are
Ну а есть надежда, что будет и на русском?

alpopo
Чем вводить опцию без визуальной обратной связи, я бы посоветовал всем не заниматься ерундой и использовать стандартную методику, при которой вы проверяете правильность рамок контента до вывода.

drcode

Цитата:

Since which year are the russian/soviet books in the public domain ?

< 1940. http://lenta.ru/articles/2004/07/30/copyrights/

2010 - 70 = 1940

Добавлено:
are

Цитата:

вот обновленный "scan and share 1.07st", там добавлены основные сведения и примерный ход работы для scantailor. (на английском)
http://ifile.it/y8b41dw/Scan_and_Share_1.07st.pdf

Обратите внимание, что уже существует версия DjVu Hyperlinks Editor с английским интерфейсом. (версия 0.8)

Добавлено:
Буржуи не хотят сканировать, буржуи кое-как согласны лишь фотографировать.

Добавлено:
anagnost96
У меня имеется такая идея: добавить функционал cpaldjvu в miniDjVu. Точнее, ту часть функционала cpaldjvu, которая отвечает за создание FGbz-чанка (т.е. цветного текста). Идея навеяна фразой из http://djvu.sourceforge.net/doc/man/cpaldjvu.html :

Цитата:

This program should be rewritten as a pre-processor for csepdjvu.

Вам это интересно? Я как бы другими вещами пока занимаюсь - так может Вы как-нибудь сделаете по свободе...

Новая сборка, с динамической сортировкой миниатюр на этапе полезная область: http://www.onlinedisk.ru/file/421091/
Теперь, когда архитектура такое позволяет, ввести такой же механизм на этапе макета будет раз плюнуть. За одно уберу ссылки "Самая широкая (высокая) страница".
Один момент: на старых проектах это работать не будет, пока не сделаете полный прогон (пусть даже холостой) на этапе полезной области или более позднем.

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

Цитата:

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

Может и будет, а может это все же перебор. Пока делать не буду, а там посмотрим.
Для стадии макета уже сделал кстати.

Попробовал сортировку, очень понравилось. Реально полезная фича получилась.

Tulon:
Вы ранее просили сканы замусоренные, для проверки работы деспекла. Вот пара таких (книга старая), где не хватает даже Агрессивного удаления пятен: http://www.onlinedisk.ru/file/421977/
Я всю эту книгу прогоняю через Агрессивную очистку пятен (кое-где меняю на Обычную, но редко). Но даже Агрессивной не хватает.
Надеюсь, эти сканы помогут вам...
Отдельное спасибо за сортировку контента - очень помогает искать обрезанные сканы.

kvesda
На самом деле despeckle там очень хорошо отработал. Просто не надо ждать чудес, типа удаления карандашных подчеркиваний.

Tulon
Еще пару слов по проблеме наложения сквозной нумерации страниц при изменении структуры частично выведенного проекта. Может быть, не менять формат именования на -l и -r, а просто переименовывать выходные файлы в соответствии с новой структурой.
Иными словами, держать папку out в полном соответствии с текущей структурой проекта. Технически это, насколько я понимаю, не очень сложно. Или я упускаю какие-то соображения не технического характера, не позволяющие это делать?

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

Tulon
я бы ко всему сделанному и сказанному (оценка +) еще раз попросил бы автора зацепиться за поле "номер страницы"

StanFreeWare

Цитата:

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

Я уже начал делать вариант с L/R. Он и проще и чище варианта с переименованием.

alpopo

Цитата:

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

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

Dashout
Я вам уже объяснял, что ST понятия не имеет, где там на странице ее номер.

Tulon
L/R хорошо, правда, основным следствием будут обе обложки в конце книги (у пользователей, которые не догадаются сделать сквозную сортировку до СТ). Главное - чтобы "фантомных" файлов в папке OUT не получалось при изменении проекта.

И еще - с учетом наличия сортировки стал особенно необходим механизм перехода на первый/последний элемент полосы предпросмотра. Хотя бы тупо Home и End..

2 Tulon
Кстати, давно хотел спросить -- я несколько раз пытался ставить галочку "Звуковой сигнал по окончании", но так ничего и не услышал.

iit512

Цитата:

Кстати, давно хотел спросить -- я несколько раз пытался ставить галочку "Звуковой сигнал по окончании", но так ничего и не услышал.

В Линуксе соответствующая Qt функция реализована посредством X'овой функции XBell(). Так вот, во многих дистрибутивах XBell() насильно отключен, надо полагать из-за того, что программы вроде терминалов им злоупотребляют.

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

woodyfon
Новая система именования будет такая:
origname_1L.tiff, origname_2R.tiff - половинки двухстраничного скана.
Для систем письменности справа-налево будет 1R и 2L.
origname.tiff - одностраничный скан.
Ну и наконец:
origname(1).tiff, origname(1)_1L.tiff, ... - если вас угораздило добавить в проект файлы с одинаковыми именами из разных директорий.

Добавлено:
А пакетное переименование лучше делать до ST.

Пакетное переименование я произвожу и до ST. Система нумерации у меня такова. Основное имя файла - Scan, далее в зависимости от количества страниц, количество цифр в индексе от 2 до 3, иногда 4 (было один раз ), далее цифровой индекс, который обозначает обычно двухстраничный скан. Например, титульная страница (1 страница) и БО&C (2 страница), то тогда получаемый файл будет Scan001.tiff(tiff), далее начало книги как таковой (3 страница) и продолжение (4 страница) - Scan002.tif(tiff). Т. е. в дальнейшем можно будет себя проверять при сканировании, например, Scan074 - страницы 146-147. После обработки в ST именую страницы таким образом, чтобы цифровой индекс отвечал номеру страницы в книге, например, Page0153 - страница 153. Далее такая система нумерации помогает сборке. Хотелось чтобы, система нумерации осталась прежней, но, конечно, добавилось, бы Номер обработанного изображения по счету+оригинальное название, сторона страницы (левая и правая). Такая система нумерации учла бы преимущества прежней нумерации (конечно, у других юзверей она может и не иметь преимуществ) и добавила бы возможность левых и правых страниц. Обычно левая страницы - четная, правая - нечетная. ИМХО, в дальнейшем следует ввести шаблон нумерации.

Ну а у меня схема обычно такова: prefix_XX_XXX (для одностраничных сканов) или prefix_XX_XXX-XXX (для разворотов), где prefix -- некое условное обозначение книги, XX -- номер пагинации (важно для книг, где, например, страницы предисловия пронумерованы римскими цифрами или просто обложка, титул и т. д. не входят в общую нумерацию), а XXX или XXX-XXX -- номер страницы в книге или пара таких номеров. Соответственно, дополнительные номера от СТ мне не нужны и после обработки их приходится убивать. Так что я всецело поддерживаю новый вариант, при котором одностраничные сканы никакого дополнительного переименования требовать не будут.

Цитата:

В Линуксе соответствующая Qt функция реализована посредством X'овой функции XBell().

Под WinXP SP2 тоже не работает...

Цитата:

origname_1L.tiff, origname_2R.tiff

Цитата:

origname(1).tiff, origname(1)_1L.tiff

А можно попросить давать имена в нижнем регистре? И, если можно, без скобок, а только с подчеркиванием типа origname_1_1l.tiff? Так можно будет избежать проблем с виндами, выкладыванием в сеть файлов с разным регистром, и еще с shell скриптами.

iit512

Цитата:

Под WinXP SP2 тоже не работает...

У меня работает. Тоже XP SP2.


Цитата:

А можно попросить давать имена в нижнем регистре? И, если можно, без скобок, а только с подчеркиванием типа origname_1_1l.tiff? Так можно будет избежать проблем с виндами, выкладыванием в сеть файлов с разным регистром, и еще с shell скриптами.

Заглавные L и R просто лучше выглядят. Проблем с регистром мне даже сложно представить. Что касается (1), то это как бы стандартный способ представления файлов с одинаковыми именами. Шелл скрипты их поймут, если они аккуратно написаны - кавычки и все такое. К тому же, вы скорее всего не будете добавлять в проект файлы с одинаковыми именами их разных директорий. В общем я бы не стал что-то менять из-за таких сомнительных опасений.

Жаль, что Вы так не хотите ничего менять.
Проблемы с регистром просты -- винды его помнят, но не учитывают. Следствие -- проблемы с переносом файлов между платформами.
Что же, буду пакетно переименовывать, как сейчас переименовываю tiff -> tif
Все же очень хочется, чтобы неудобств слало не больше, а меньше.

Tulon:
Подскажите, что можно сделать в этой ситуации:
Делаю вывод в Смешанном режиме. Автоопределение картинки включает в картику еще и часть текста. После вывода этот "захваченный" текст выглядит СЕРЫМ, что не красиво на общем ЧЕНОМ фоне бинаризованного текста выше, ниже и (или) вокруг картинки.
Можно ли в этой ситуации:
1). Зоной указать, что часть автоопределенной картинки (текст) не должен восприниматься, как текст?
2). Вычесть зоной этот фрагмент...
Может еще как?
Спасибо.