AlVaKo писал(а) 29.04.2021 :: 16:29:38:Слово "shear" для меня это сдвиг, может я ошибаюсь.
Да, shear, я опечатался.
AlVaKo писал(а) 29.04.2021 :: 16:29:38:Как определять угол коррекции наклона, это отдельная задачка. А потом надо крутить картинку. Там её качество естественно падает. Я имел ввиду именно проблему качества картинки после вращения.
самописный shear используется только для определения числового значения угла. Вращает изображение ST не им. Я не силен в image processing, мне кажется сейчас до меня начинает доходить...
ST не меняет изображение на каком-то этапе обработки. По сути, ST собирает информацию о том, как нужно менять изображение, и только на последнем этапе (Output) применяет её и рендерит новое изображение в output. А то, что выводится на экран в самом ST до самого последнего этапа - это просто превьюшка с контролами, позволяющая задать параметры этих преобразований.
По моему все этапы обработки до этапа Output сохраняют изменения, которые необходимо будет провернуть с изображением, в классе Qt QTransform. Он умеет crop, scale, rotate, shear и т.п. Но для него это все - изменение координатной системы, у него там матрица внутри. Т.е. просто математика. Этот класс оторван от изображения.
А вот на этапе Output ST берет изображение и делает ему transform, передав объект QTransform. И вот в этот момент происходит рендеринг. И вот только в этот момент мог бы иметь смысл bicubic, ланцош и т.п.
Т.е. говорить об их применении на каком-то конкретном этапе обработки, например deskew - бессмысленно. Разве что вот в этих служебных преобразованиях, где картинка реально рендерится для автоматического поиска угла наклона (я кстати предполагаю, что там не реальная картинка, а её downscaled версия крутится - для скорости).
А реальный рендеринг результата ST делает сильно позднее.
Так вот, Qt при рендеренге изображения.. во первых ему до лампочки, был там в QTransform rotate или scale - для него это просто преобразования из одной системы координат в другую. Во вторых, фильтра он понимает только два - нифига, либо bilinear. Никаких bicubic или чего-такого Qt не умеет.
Тут возникает вопрос, а имеет ли смысл этот фильтр, если в QTransform был только rotate и т.п. операции над системой координат, но не было scale - возможно что и нет. Но вот scale в ST вполне себе возможен, если dpi результата с исходным не совпал. Вот при scale - да, тут поиграться с bicubic мне хотелось бы. Но Qt этого не умеет.
С отсутствием bicubic я столкнулся, когда портировал DjVuImager от monday2000 на Qt. Там DjVuImager downscale'ит фоновые изображения через измененный кодек fi-c44 и запихивает их обратно в djvu документ. Т.к. я сейчас работаю над тем, чтобы делать djvu документы методом раздельных сканов (и почти доделал) прямо в ST, я столкнулся с необходимостью сделать scale с бикубиком. В fi-c44 эту операцию выполняет библиотека FreeImage. Вот она умеет штук шесть фильтров: и среди них был и бикубик и ланцош3, вроде.
Я смог выдрать код, делающий этот scale из FreeImage и подружить его с форматом представления изображения в Qt (Qt считает точку 0,0 в левом верхнем углу изображения, а FreeImage - в левом нижнем.). И он у меня даже где-то валяется. Валяется, потому что я от него отказался и оставил scale изображений кодеку fi-c44, только сделал используемый фильтр настраиваемым через командную строку. Чтобы bicubic был не захардкоден.
Это я к чему, в теории я могу запретить QTransfrm делать scale самому, а вместо этого использовать методы, выдранные из FreeImage с bicubic и пр. Но это никакого отношения к этапу deskew иметь не будет. Это будет происходить в Output. А умеет ли FreeImage делать rotate с bicubic - это еще вопрос... Хотя вот monday2000 вроде писал что умеет:
http://djvu-soft.narod.ru/bookscanlib/020.htmВ общем я запутался. Всё равно ничего делать не буду ))
Главная
Страниц: 
