jourmager
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
Цитата:| Вы очень любите сравнивать не пойми что |
Просто риторические замечания на тему поворота в СканТейлоре и прочих программах
Недавно в этой теме возник вопрос:
"Как Тейлор поворачивает? В других редакторах есть настройки метода поворота изображений: дольше и качественнее - Lanczos, Bicubic, Antialias и т.д. В Тейлоре этих настроек нет - стало быть на этапе "Компенсация наклона" качество изображений ухудшается?"
На что последовал корректный ответ от zvezdochiot, который мог бы и закрыть эту тему. Но. Вдруг как гром с ясного неба "для выравнивания, например, журнальных сканов в 300dpi ST не годится"
Для начала повторю и немного расширю ответ zvezdochiot-а. Насколько мне известно, нет никаких официальных утверждений о том, какой именно математический аппарат используется для поворота изображений в ScanTailor и Qt. Но, опять же насколько мне известно, ScanTailor использует Qt для поворота изображений. А сам Qt для поворота изображений использует аффиново преобразование. Говорить о том, что в какой-либо программе именно для поворота используется bilinear или bicubic или Lanczos - это просто безграмотно. Чушь собачья. Бред сивой кобылы. Фигня полная. Потому что это методы интерполяции. А интерполяция - это нахождение промежуточных неизвестных значений между уже известными значениями. Что к самому процессу поворота не имеет отношение от слова совсем. Наиболее известное применение интерполяции, и соответственно bilinear или bicubic или Lanczos - ресамплинг, апсамплинг, даунсамплинг - т.е. изменение количества пикселей в изображении в большую или меньшую сторону. Те. имело изображение по какой-то стороне 1000 пикселей, а захотелось 2000 пикселей. Вот и надо вставлять дополнительные пиксели между уже существующими, применяя эти самые bilinear или bicubic или Lanczos. Естественно, при выполнении самого поворота происходит простое синхронное перемещение пикселей и ничего никуда вставлять не надо, т.к. попросту некуда. Именно поэтому в СканКромсаторе для версии 7.04 для ресамплинга имеем:
Главное меню -> File -> Options -> Processing -> Resample filter (Linear, FastLinear, Lanczos3 (default), bilinear, bicubic, Mitchel)
и для поворота:
Deskew method -> Auto(shear) (default), Fast, Antialias, Interpolate, Shear, Auto(a/alias)
Но есть одна маленькая фигня - при повороте изображений с малым количеством пикселей начинают искажаться контуры контрастных изображений - появляется "лесенка" там, где её не было. И вот как раз для уменьшения видимости этой самой лесенки и применяются в данном случае bilinear или bicubic или Lanczos. Ещё раз - они используются для сглаживания контуров, но никак не для самого поворота. В Qt, а значит и в СканТейлоре, после поворота с помощью аффинового преобразования применяется ЕМНИП билинейная интерполяция - самый простой и быстрый метод, о чем уже писал zvezdochiot. Потому что Qt - это фреймворк для построения GUI, т.е. интерфейса пользователя, для программ на С++. А для GUI в первую очередь важно быстродействие. Кстати, в СканТейлоре поворот просчитывают две функции - одна очень быстрая без всякой интерполяции и с низким качеством как раз для интерфейса пользователя типа панели миниатюр, и вторая качественная с билинейной интерполяцией для физического расчёта на последнем 6-м этапе, про что вообще-то тоже упоминал zvezdochiot.
Какой метод сглаживания контуров при повороте применяется в СканКромсаторе и применяется ли он там вообще - надо спрашивать в соответствующей теме у автора программы. Кстати, как мог заметить внимательный читатель, в качестве метода по умолчанию для Deskew method предлагается Auto(shear), а метод Antialias не рекомендуется автором СканКромсатора ЕМНИП с 2008 года, причём Antialias вообще предназначался для b/w сканов, но никак не для полноцветных журнальных страниц. Также, в качестве метода Resample filter по умолчанию предлагается Lanczos3, как имеющий наилучшее качество при интерполировании, лучшее чем bicubic.
Ну и конечно же я для своих экспериментов использовал настройки по умолчанию - Auto(shear), который в данном случае вызывал Interpolate, и Lanczos3, т.е. претензии к неправильным настройкам СканКромсатора попросту несостоятельны.
Кстати. Вообще-то говоря, говорить о применимости или неприменимости СканТейлора в тех или иных случаях можно только при указании конкретного форка и даже конкретной версии этого форка. Потому что, например, любимый мною STA не может исправлять геометрические искажения, что могут делать STexp и STEX. Т.е. мне надо было бы сделать ещё сравнительные тесты разных хотя бы форков типа STA, STU, STexp, STEX. Особенно учитывая то, что они могут использовать разные версии Qt, который собственно и отвечает за поворот. Т.е. существует ненулевая вероятность того, что претензии к СканТейлору основаны на использовании давно забытой версии 15-летней давности - особенно с учётом использования устаревшей версии СканКромсатора и давно устаревших рекомендаций для него.
И ещё раз - ухудшение качества растрового изображения при повороте из-за размытия контуров будет происходить всегда и везде, другой вопрос - насколько это будет заметно. Опять же - никто не озвучил условия оценивания качества картинки.
И ещё - мыльное изображение - это когда размывается изображение по всей плоскости. Никакие интерполяции контуров не могут размыть то, что находится где-то глубоко внутри или снаружи этих самых контуров. Т.е. применение билинейной интерполяции вызвать мыло, т.е. размытие всей плоскости изображения, не может. Что и видно на всех моих скриншотах. Да, толщина символов может быть в несколько пикселей, т.е. размытие контуров может захватить и внутренности символов, но, как я уже писал, это неизбежное зло, которое вообще-то можно и нужно оценить, но, как оказалось - некому. Зато это мыло очень хорошо видно на кропе из журнала с применением ранней версии Deskew Tools. Но с теми кропами вообще непонятка.
Для начала - сравнивается кроп после Deskew Tools и кроп после Фотошопа неизвестной версии, обнаруживается мыло на кропе от Deskew Tools и на основе этого делается заключение о недопустимости применения СканТейлора для поворота изображений. Это вообще как? Мылит Deskew Tools, а виноват СканТейлор?! Далее - якобы исходное изображение, которое якобы поворачивали. на самом деле ровное. Про что писали ещё 3 года назад. Поэтому мне и пришлось его вертеть два раза для 4-го эксперимента. Ну и в моем 4-м эксперименте видно, что ни у Deskew Tools на linear, ни у STA, нет никакого мыла, которое было на кропе 3-летней давности. Кстати, Deskew Tools ещё имеет метод Nearest, но тот давал очень хорошо заметные изломы на буквах, так что я его откинул как полностью непригодный. И ещё - в Deskew Tools GUI я не нашел выбора метода интерполяции, так что пришлось командной строкой.
И ещё - скриншот я выставил на масштабе 100%, но для себя я сравнивал аж до 1600%.
И ещё - за те пару дней, что тут обсуждалось призрачная недопустимость использования СканТейлора для поворота практически никто не высказался о том а куда смотреть, что сравнивать, в каких режимах и т.д. Ну разве что TelecomUral предложил длинную прямую линию и миру. Но это ИМХО синтетический бенчмарк, имеющий мало общего с реальной жизнью.
И никто не попробовал сам покрутить свои собственные сканы. Хотя 3 года назад чего-то там пробовали, но вообще-то походу просто забили на обвинения в адрес СканТейлора как на не стоящие внимания. Чего и вам желаю. |
Предыдущие части: 
