Перейти из форума на сайт.

НовостиФайловые архивы
ПоискАктивные темыТоп лист
ПравилаКто в on-line?
Вход Забыли пароль? Первый раз на этом сайте? Регистрация
Компьютерный форум Ru.Board » Компьютеры » Программы » Scan Tailor (часть 3)

Модерирует : gyra, Maz

 Версия для печати • ПодписатьсяДобавить в закладки
Страницы: 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

Открыть новую тему     Написать ответ в эту тему

Maz



Дед Мазай
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
 Предыдущие части: Часть 1,  Часть 2

Scan Tailor


Задача программы - автоматизированная пост-обработка сырых сканов типовых книг (ЧБ текст + прямоугольные иллюстрации) для последующей сборки в PDF/DJVU,CBR/CBZ и т.д.
Программа обеспечивает большое удобство для использования, большую интерактивность и не меньшую автоматизацию процесса, что сильно ускоряет обработку типового материала  (ЧБ текст + прямоугольные иллюстрации). Для нетипового материала следует использовать СканКромсатор, PhotoShop, или GIMP.
ST изначально не позиционировался как единственный инструмент обработки и применяется в комплексе с другими программами.
Кросс-платформенный (Windows,Mac OS, Linux) проект с открытыми исходниками.


Англоязычный топик по ScanTailor
 
Ветки:
Scan Tailor (ST) (ncraun) >>>  последняя версия
Scan Tailor Experimental (STex) (Tulon) >>>  последняя версия (обсуждение на DIY Book Scanner)
Scan Tailor Experimental (STEX) (мод. звездочёта, Нубия-IV и plzombie) >>>  последняя версия (статистика)
Scan Tailor Deviant (STD) (Нубия-IV) >>>  последняя версия ("фотосканы")
Scan Tailor Plus (STP) (Vadim "DikBSD" Kuznetsov) >>>  последняя версия (отличия от авторской версии)
Scan Tailor Еnhanced (STE) (Petr "pejuko" Kovar) >>>  последняя версия (отличия от авторской версии)
Scan Tailor Featured (STF) (monday2000) >>>  последняя версия (отличия от авторской версии)
Scan Tailor Universal (STU) (trufanov-nok) >>>  последняя версия (обсуждение на publ.lib.ru)
Scan Tailor Advanced (STA) (4lex4) >>>  последняя версия (отличия от авторской версии)
Scan Tailor Advanced (STA) (актуальный форк) >>>  история версий
 
Документация:
Документация (Wiki) | Зоны картинок в ScanTailor | ScanTailor. Быстрое начало | Видеоуроки и скринкасты новых функций СТ от Tulona
Статья: Scan Tailor. Программа для обработки отсканированных книг
Видеоурок: Создание DjVu с помощью Scan Tailor (зеркало)
Использование Scan Tailor совместно с Djvu Imager (сборка djvu методом разделенных сканов)
Как собрать Scan Tailor из исходных кодов под Windows
Почему нельзя сделать сплошную нумерацию вывода

"Описание порогов от AlVaKo"
"Дополнение к описание порогов в контексте ST от звездочёта"

Автор проекта - Tulon. Почему его здесь не видно? .
DikBSD автор ветки ScanTailor Plus история повторяется.
Юзеры! Будьте скромнее!


Прочие дистрибутивы, форки, дополнения
 
Хронология разработки Scan Tailor и её форков (livejournal, 20 февраля 2025).

Всего записей: 39702 | Зарегистр. 26-02-2002 | Отправлено: 10:44 10-01-2024 | Исправлено: ndch, 15:44 06-11-2025
jourmager

Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Сорри за оффтоп
 
useretail

Цитата:
надо переходить на JPEG 2000

Да не вопрос. Но сначала посоветуйте pdf-вьювер, который будет обеспечивать такую же скорость просмотра на JPEG2000 как и на простом JPEG.  
Тогда можно будет думать о том, чтобы СканТейлор на выходе сразу JPEG2000 выдавал.
 
Archivist

Цитата:
Может быть у вас ЭЛТ монитор?

Не понял, к чему это?
ЭЛТ монитор имеет кучу преимуществ по сравнению с ЖК-монитором:
- нет зависимости яркости и цветопередачи от угла просмотра
- нет засветки при чёрном цвете из-за подсветки
- нет всяких эффектов на скоростных кадрах типа гостинга, инпут лага и прочей фигни
- неравномерность цвета и яркости из-за краевой подсветки
- всякие глоу эффекты и прочие
- и т.д., и т.п. и пр., про что я уже 20 лет как забыл
Кроме меньшего веса, меньшего энергопотребления, возможности большей диагонали, у ЖК-мониторов ЕМНИП только одно-единственное преимущество в качестве - идеальная геометрия, которая идёт к лешему, если картинка попадает на полпикселя.
 

Всего записей: 1056 | Зарегистр. 04-11-2019 | Отправлено: 20:17 08-11-2025 | Исправлено: jourmager, 20:41 08-11-2025
TelecomUral

Silver Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
оффтоп
 
jourmager
справедливости ради замечу, что тормоза начинаются не столько на jpeg2000, сколько на применении масок прозрачности вместе с этим кодеком. простые фотки, врезанные рядом с текстом, прекрасно быстро листаются и пожатые как j2k.

Всего записей: 3625 | Зарегистр. 15-07-2010 | Отправлено: 20:32 08-11-2025
zvezdochiot



Advanced Member
Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
jourmager say:
Цитата:
предлагайте методику анализа.

  • Открыл выложенный вами скан в GIMP. Сделал белые поля, расширив холст до 2500x3500 с выравниванием по центру. Сохранил.
  • В STEX без обрезки повернул изображение вручную ровно на 5 градусов. Вывод в "Цветное/Серое" с полностью обнулённой префильтрацией.
  • Опять в STEX создал проект из результата первой обработки. Без обрезки повернул изображение вручную ровно на (-5) градусов. Вывод в "Цветное/Серое" с полностью обнулённой префильтрацией.
  • Открыл результат второго обратного поворота в GIMP. Обрезал поля, уменьшив холст до 2500x3500 с выравниванием по центру. Сохранил.
  • Открыл выложенный вами скан и результат обрезки в GIMP как слои. В слоях выбрал режим наложения "Извлечение зерна", получив "разницу" или "дефект" двухкратного вращения в STEX.
     
    Собственно, вот.

  • Всего записей: 1022 | Зарегистр. 18-05-2023 | Отправлено: 20:34 08-11-2025
    jourmager

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    zvezdochiot
    Как вариант. Я пока не готов высказать свою оценку.
    Но выскажу несколько мыслей. Не по порядку.
    - как я уже говорил, любой поворот на любой угол с применением интерполяции (билинейной, бикубической, Ланцоша, етс) влечёт за собой размытие контуров букв (и прочего с резкими переходами). А тут текст уже изначально повёрнутый, т.е. на прямоугольную сетку аж никак не лёг ровно, потом один поворот, потом второй. Конечно же там пойдут артефакты.  
    - если основная цель - сравнить конечные результаты работы разных программ, чтобы выбрать наилучший вариант для поворота - то сравнивать надо каким-то образом эти самые конечные результаты между собой
    - угол поворота на 5 градусов - слишком большой. На таком угле при применении простых методов интерполяции типа билинейного точно будет заметное размытие контуров.  
    У меня мало опыта работы с сырыми наклонными сканами, поэтому я не могу сказать, какой диапазон углов наклона статистически оправдан для тестового набора.
    Мой склероз мне шепчет, что где-то в теме по СканТейлору Tulon говорил, что исправление наклона в СТ работает хорошо только до определённого предела - это было сделано специально для обеспечения максимальной скорости (всё-таки 2008 год) при удовлетворяющем качестве.
    - вот этот мой скан - весьма посредственного качества. Поэтому сравнивать результаты его обработки "на глазок" весьма трудно. Вы предложили интересный метод объективного инструментального сравнения по разнице между изображениями, но вот как понять, насколько эта объективная инструментальная разница будет заметна простым человеческим глазом?

    Всего записей: 1056 | Зарегистр. 04-11-2019 | Отправлено: 21:15 08-11-2025
    zvezdochiot



    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    jourmager say:
    Цитата:
    угол поворота на 5 градусов - слишком большой.

    Разумеется. Специально и нарочно сделал. Чтобы размытие было видно. А иначе на что смотреть то?

    Всего записей: 1022 | Зарегистр. 18-05-2023 | Отправлено: 21:28 08-11-2025
    jourmager

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    zvezdochiot

    Цитата:
    Специально и нарочно сделал. Чтобы размытие было видно. А иначе на что смотреть то?

    А вот тут я с вами не согласен.
    Да, размытие будет видно сильнее.
    Но если исходить из реальных углов, то сравнение получается нечестным - простые алгоритмы типа билинейного ставятся в заведомо проигрышное положение, для которого они никогда не предназначались.
    Когда я заметил Archivist, что угол 0.13 градуса слишком мал для корректного сравнения, тот ответствовал, что "На практике большинство поворотов такие." Я не буду с ним спорить, т.к. опыт не то что обработки, а даже просмотра сырых (вообще необработанных) сканов у меня очень мал - несколько сотен книг, может пару тысяч.
     
    Сорри за оффтоп
     
    TelecomUral

    Цитата:
    тормоза начинаются не столько на jpeg2000, сколько на применении масок прозрачности вместе с этим кодеком. простые фотки, врезанные рядом с текстом, прекрасно быстро листаются и пожатые как j2k

    Небольшие фотки (не на всю страницу) в jpeg2000 с небольшим dpi листаются сравнительно быстро, но не прекрасно. Время от времени попадаются журналы именно с небольшими фотками в 100-150 dpi и векторным текстом - и я их моментально отличаю по тормозам.
     
    Комбинация же jpeg2000 и jbig2, как в книгах с Internet Archive, тормозит весьма сильно.
     
    Сегодня скачал журнал, где все страницы - jpeg 300 dpi High, вот прямо сейчас рекомпрессировал все страницы с помощью PDF-XChange Editor в JPEG2000 High. Получил увеличение размера с 65 МБ до 186 МБ и тормоза, что в SumatraPDF, что в PDF-XChange Editor. Пожал плечами, пошел писать коммент. Оба варианта конечно же могу предоставить.

    Всего записей: 1056 | Зарегистр. 04-11-2019 | Отправлено: 21:42 08-11-2025 | Исправлено: jourmager, 21:51 08-11-2025
    Archivist

    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    jourmager

    Цитата:
    Не понял, к чему это?
    ЭЛТ монитор имеет кучу преимуществ по сравнению с ЖК-монитором:  
    - и т.д., и т.п. и пр., про что я уже 20 лет как забыл  

    Так я угадал? Это все объясняет. ЭЛТ облагораживает картинку и скрывает недостатки типа того же размытия. ЖК показывает все как есть. А перечисленные вами минусы устранили еще лет 15 назад. Не наблюдаю ни одного из них на стареньком качественном HP Z24i IPS. А ЭЛТ тоже есть, на даче стоит, под старые игры.
     
     
    Предлагаю простой эксперимент. Я разместил в таблице размытый по гауссу текст с шагом в 0.1. Результат поворота в ST идентичен 3й строке (r =0.3).  
       
    Какие строки выглядят размытыми?

    Всего записей: 381 | Зарегистр. 10-08-2018 | Отправлено: 22:06 08-11-2025
    jourmager

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Archivist

    Цитата:
    Так я угадал?

    Угадали что? В прошлой жизни через мои глаза и руки прошло несколько тысяч мониторов и телевизоров ЭЛТ и ЖК с полной предпродажной проверкой (тестовые таблицы, битые пиксели, мИры, вот это вот всё). Но ЭЛТ вживую я последний раз видел около 20 лет назад. И что? Зайдите в какой-нибудь супермаркет электроники и станьте под углом к ряду телевизоров и посмотрите на одинаковость изображения десятка-другого телеков или мониторов. Устранили, ага, 15 лет назад. Нифига не устранили, а кое-что просто уменьшили. И ещё дофига чего добавили. Удешевляторы-оптимизаторы фиговы. Но хватит оффтопа.
     

    Цитата:
    Какие строки выглядят размытыми?

    Все. Верхние менее размытые, нижние более размытые.
    Но я не понял. Я сравнил 3-ю строку из вашей таблицы, про которую вы сказали - "Результат поворота в ST идентичен", но ведь она нифига не идентична! Потому что строка из вашей таблицы не идентична строке из файла STA 2019.8.16.tif, который вы же прислали.
    Вы что, сделали размытие по Гауссу, на глазок на своем мониторе сравнили с результатом от СТА, решили что 3-я строка "идентична" СТА и выставили размытие по Гауссу как доказательство "мыла" на СТА? Так что ли? Ничего не понял.
     
     

    Всего записей: 1056 | Зарегистр. 04-11-2019 | Отправлено: 22:53 08-11-2025 | Исправлено: jourmager, 22:54 08-11-2025
    Archivist

    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    jourmager
    Если видите размытие в таблице, значит видите и в сравнении поворотов
     
       
     
    Или это какой-то троллинг.

    Всего записей: 381 | Зарегистр. 10-08-2018 | Отправлено: 22:56 08-11-2025
    zvezdochiot



    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Archivist say:
    Цитата:
    Или это какой-то троллинг.

    Именно. Только с вашей стороны. Каким образом буквы на скане и обработках одной величины, а на ваших "скриншотах" другой? Магия?

    Всего записей: 1022 | Зарегистр. 18-05-2023 | Отправлено: 23:05 08-11-2025 | Исправлено: zvezdochiot, 23:06 08-11-2025
    jourmager

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Archivist

    Цитата:
    Если видите размытие в таблице

    Так вы что, с помощью этой таблицы моё зрение проверяли? Троллите?

    Цитата:
    значит видите и в сравнении поворотов

    Между ST и DT? Или между оригиналом и ST? При масштабе 100%?
    Размытие по Гауссу работает по всей площади изображения - и я это вижу как усреднение яркости, т.е. темные буквы белеют и становятся серыми. Степень "серения" зависит от размера фильтра (радиуса) Гаусса, но уже при 3х3 работает на всю ширину штрихов буквы, которая составляет максимум 4-5 пикселей. А светлый фон вокруг контуров букв чернеет и тоже становится серым. При этом малоконтрастный фон тоже усредняется.
     
    Интерполяция билинейная или бикубическая или по Ланцошу (в отличие от размытия Гаусса) должна "работать" только по контурам высококонтрастных элементов (это терминологически не совсем точно, но думаю что понятно). Т.е. при ширине высококонтрастных элементов в 4 пикселя изменение контрастности будет видно на контурах, составляющих один пиксель, что гораздо менее заметно, чем размытие по Гауссу. И при интерполяции малоконтрастный фон практически не усредняется.
     
    Ширина одного пикселя у монитора 24 дюйма при разрешении ФуллХД примерно равно полторы разрешающей способности человеческого глаза - ну и много вы там размытия увидите?
     
    Полуоффтоп.
    У меня тут дурацкая идея возникла.
    ЕМНИП у СК был инструмент что-то типа Color Pixel Picker но для площадей, но где он и как им воспользоваться в данном случае для объективной оценки разницы изображений - склероз.

    Всего записей: 1056 | Зарегистр. 04-11-2019 | Отправлено: 01:15 09-11-2025 | Исправлено: jourmager, 01:18 09-11-2025
    useretail



    Gold Member
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
    jourmager

    Цитата:
    Для тех, кто ещё сомневается какой алгоритм лучше, предлагаю скриншот, полученный после поворота на 1 градус в XnView и выпрямления в Deskew Tools с использованием 3 методов: linear, cubic, lanczos, и бонусом STA 1.0.19. Выбирайте сами. Можно голосованием.

    я все страницы и до этого не читал, но сейчас просто пролистал и нашел, как я полагаю, ваш оригинальный тезис
     
    если ваш скан в формате JPEG, то при его повороте на углы, кратные 90 градусов, в пределах от 0 до 360 (то есть 90, 180 и 270) интерполяция/ресемплинг не нужны, так как поворот осуществляется без потерь
     
    а вот при повороте на иные градусы уже будут потери. поэтому для избежания таких случаеьв, поворот нужно осуществлять или в формате без потерь (например в упомянутом мною ранее JPEG 2000) или пересчётом с исходных значений пикселей
     
    т.е. тут вопрос скорее в том, как именно реализован поворот в самом софте: если кодер ленивый, то он один раз потеряет качество при повороте, и второй при сохранении результата в JPEG
     
    Добавлено:
     

    Цитата:
    посоветуйте pdf-вьювер

    любой поддерживающий PDF 1.5
    а если тормозит, то задумайтесь о покупке более мощного процессора

    Всего записей: 5209 | Зарегистр. 14-09-2007 | Отправлено: 02:08 09-11-2025 | Исправлено: useretail, 02:28 09-11-2025
    zvezdochiot



    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    jourmager say:
    Цитата:
    Интерполяция билинейная или бикубическая или по Ланцошу

    Есть одно маленькое "но"!
    В результате работы с PhotoQuick (и с кодом программы, и с кодом плагинов, и с самой работой проги), мне доподлинно известно, что в Qt не используется ни одна из перечисленных вами интерполяций.
    Как так?
    Внезапно! оказывается что разновидностей этих самых интерполяций очень много.
    Тадам!, так сказать.

    Всего записей: 1022 | Зарегистр. 18-05-2023 | Отправлено: 10:19 09-11-2025
    jourmager

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    useretail

    Цитата:
    я все страницы и до этого не читал

    А зря. Можно было только меня

    Цитата:
    а вот при повороте на иные градусы уже будут потери. поэтому для избежания таких случаеьв, поворот нужно осуществлять или в формате без потерь (например в упомянутом мною ранее JPEG 2000) или пересчётом с исходных значений пикселей

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

     
    Из картинки видно, что с одной стороны, "родной" пиксель квадрата уже не полностью занят этим квадратом, с другой стороны все 4 соседних пикселя уже не полностью белые, а немного заняты чёрным пикселем. и тут 2 варианта - или оставить 2 цвета - чёрный и белый, основываясь тупо на процентном отношении чёрный/белый (есть более продвинутые алгоритмы бинаризации, но сейчас не про них), или перевести все 5 пикселей в серый цвет с учётом того же процентного отношения чёрный/белый.
    А теперь представьте себе, что такой пиксель не один, а дофигища, и что они могут быть серо-буро-малиновыми.
     
    Задача поворота растровых изображений раскладывается на 2 подзадачи - собственно сам поворот (пересчёт координат) и интерполяция пикселей на контрастных контурах. Методы linear, bilinear, bicubic, Lanczos, B-Spline, etc - это всё методы интерполяции для сглаживания контуров контрастных деталей. И в любом случае они дадут размытие хотя бы 2 соседних пикселей относительно контрастной границы.
    Насколько это размытие будет заметно - зависит от алгоритма интерполяции, самого поворачиваемого объекта, угла поворота и чего-то ещё. В общем случае, чем более сложный алгоритм, тем более качественная картинка.  
     
    Но на практике не всё так однозначно. Тут недавно zvezdochiot пробовал объяснить недостатки Lanczos, но я расскажу своими грубыми словами, то что знаю. Lanczos в силу своей природы в некоторых случаях делает перешарп. Т.е. добавляет контрастные детали там, где их никогда не было. В результате можно получить более контрастную картинку (меньше "мыла"), но зубчатую.
     
    Нельзя забывать, что алгоритм - это одно, а его программная реализация - это другое.
     
    Проблема осложняется тем, что в случае поворота книжных страниц поворачиваются буквы, которые имеют размеры штрихов в единицы пикселей, т.е. размываться будет вся буква. Это неизбежное зло, плата за кривое сканирование. Я знаю обработчиков, которые во имя "качества" вообще отключают компенсацию поворота при малых углах. Методы исправления этого зла есть, но это уже другой разговор.
     
    zvezdochiot
    Я настолько задолбался рыться во всевозможных первоисточниках и биться головой об стенку, доказывая элементарные очевидные вещи, что быть вам достойным оппонентом я сейчас не могу. Сорри.
     
    Archivist
    Т.к. сам автор СканКромсатора не прояснил алгоритмы работы своей программы, то попробуем расслабиться и удовлетвориться вот этим:
     

    Interpolate: Для grey/color-сканов. Это Fast с билинейной интерполяцией - для предотвращения артефактов (например, "ступеньки" в строках текста). Хорош для gray и color, для b/w ничего особого не дает. На толщину повёрнутого текста влияет значение параметра convert to b/w threshold (закладка Convert). Если выбрать Interpolate и задать Сonvert = LowLight, то уширение практически исчезает, при том, что текст поворачивается так же хорошо (т.е. не деформируется ступеньками), как и при Antialias-повороте. Начиная с версии 5.9, метод Interpolate переписан на Ассемблере, поэтому работает быстрее, чем Fast.

     
    Автор: monday2000. Дата создания: 27 марта 2006 г. Изменено: 30 октября 2007 г.
     
    И ещё - вы каждые пару лет появляетесь в этой теме с претензиями к отсутствию кубика и Ланцоша у СканТейлора. Вам оппонировали U235, slava_cry, papaVlad (и другие) - без толку. Я пока тут на 5 страницах изгалялся, так сам всё понял, а вы 7 лет продолжаете гонятся за призраками.

    Всего записей: 1056 | Зарегистр. 04-11-2019 | Отправлено: 12:49 09-11-2025 | Исправлено: jourmager, 14:44 09-11-2025
    esys

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору

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

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

    Всего записей: 651 | Зарегистр. 22-06-2016 | Отправлено: 13:01 09-11-2025
    zvezdochiot



    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    jourmager say:
    Цитата:
    достойным оппонентом я сейчас не могу.

    А надо ли? И зачем?
    И я вовсе не оппонировал. Наоборот. Пытаюсь изжить из темы все эти байки и "сказки". В то время как вы тут единственный идёте путём непосредственного сравнения, а остальные невесть что плетут.
    Участникам темы: Билинейная интерполяция, говорите? А при чём тут ST и Qt, ежели в них интерполяция другая?

    Всего записей: 1022 | Зарегистр. 18-05-2023 | Отправлено: 13:07 09-11-2025
    Archivist

    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    jourmager

    Цитата:
    И ещё - вы каждые пару лет появляетесь в этой теме с претензиями к отсутствию кубика и Ланцоша у СканТейлора. Вам оппонировали U235, slava_cry, papaVlad (и другие) - без толку. Я пока тут на 5 страницах изгалялся, так сам всё понял, а вы 17 лет продолжаете гонятся за призраками.

    А, то есть примера, на котором проблема проявляется во весь рост недостаточно. Понял.

    Всего записей: 381 | Зарегистр. 10-08-2018 | Отправлено: 13:19 09-11-2025
    useretail



    Gold Member
    Редактировать | Профиль | Сообщение | ICQ | Цитировать | Сообщить модератору
    jourmager
    сорян, поздно было
     
    JPEG 2000 гарантирует, что декодирование-сохранение не изменит пиксели, если мы используем lossless-режим
    он не меняет природу растровой сетки - всё равно есть дискретная решётка пикселей
     
    любой поворот на угол, не кратный 90, означает: каждый новый пиксель после поворота должен получить значение, соответствующее смещённой позиции на исходной сетке
    эти позиции не совпадают с целыми координатами исходных пикселей, следовательно, нужно интерполировать значения (взвешенное усреднение соседей)
     
    и тут важный момент: даже если JPEG 2000 сам по себе без потерь, то операция поворота - это всё равно численно приближённая, т.е. геометрические потери возникают до сжатия!
     
    а вот где JPEG 2000 помогает, так это при минимизации накопления потерь: если вы много раз поворачиваете, обрезаете, корректируете и снова сохраняете, то в JPEG 2000 вы не теряете качество из-за повторных сохранений, потому что каждый раз пересчитывается только геометрия, но не добавляется шум компрессии
     
    в обычном JPEG такие повторные операции приводят к каскадным артефактам
     
    самим сабжем я пользовался давно - может лет 10 назад, но для других пользователей нужда в таком софте очевидна
    с тех пор многое поменялось и стало очевидным: в целях цифровой презервации печатных изданий нужно пользоваться lossless-форматами, что я с успехом и делаю

    Всего записей: 5209 | Зарегистр. 14-09-2007 | Отправлено: 13:50 09-11-2025
    jourmager

    Advanced Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    Archivist
    Наша песня хороша, начинай сначала.
    1) Вы вместо СканТейлора для поворота сканов используете СканКромсатор, мотивируя это тем, что там имеется выбор Resampling filter (bicubic, Lanzош, бла-бла)
    Да или нет?
    2) Объясните пожалуйста, почему результаты поворота в СканКромсаторе при разных Resampling filter (без upsampling) полностью одинаковы
    3) Прокомментируйте пожалуйста утверждение monday2000, которого никто не опроверг, что в СканКромсаторе используется билинейная интерполяция при повороте цветных-серых изображений (метод Interpolate)
     
    Не, ну если сейчас в тему придёт автор СканКромсатора и навешает мне на орехи, я , конечно, с понурой головой признаю свои ошибки и покаюсь. А до тех пор.
     
    Добавлено:
     


     
    useretail

    Цитата:
    в JPEG 2000 вы не теряете качество из-за повторных сохранений

    Фух. Гора с плеч. Теперь я вас понял.
    Да. Вы правы.
    Но я исходил из того, что поворот криво отсканированного скана осуществляется только один раз на этапе компенсации наклона при обычной обработке сканов.
     

    Цитата:
    в целях цифровой презервации печатных изданий нужно пользоваться lossless-форматами

    Internet Archive с вами согласен
    Но чукча не презервировщик, чукча читатель. А для читателя jpeg2000 в плане скорости - зло. И никаким апгрейдом железа тут не спасёшься. Только софт, заточенный под обработку jpeg2000 с максимальной скоростью. Только где он?

    Всего записей: 1056 | Зарегистр. 04-11-2019 | Отправлено: 13:55 09-11-2025 | Исправлено: jourmager, 14:15 09-11-2025
    Archivist

    Member
    Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
    jourmager
    Не перескакивайте с проблемы СТ на Кромсатор.
    Был выложен архив с доказательством проблемы, можно ее воспроизвести - https://disk.yandex.ru/d/xPQfvyIT-mLBrw
       
    альтернативная ссылка на картинку сравнения - https://disk.yandex.ru/i/Df7nEkOR8CwDgA
     
    Вы от этого отмахиваетесь, или результат не размытый, а отрицательно резкий?

    Всего записей: 381 | Зарегистр. 10-08-2018 | Отправлено: 14:08 09-11-2025
    Открыть новую тему     Написать ответ в эту тему

    Страницы: 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

    Компьютерный форум Ru.Board » Компьютеры » Программы » Scan Tailor (часть 3)


    Реклама на форуме Ru.Board.

    Powered by Ikonboard "v2.1.7b" © 2000 Ikonboard.com
    Modified by Ru.B0ard
    © Ru.B0ard 2000-2025

    LiteCoin: LgY72v35StJhV2xbt8CpxbQ9gFY6jwZ67r

    Рейтинг.ru