Vestlused

Как, математически, делается поворот фотографии в редакторах?

Привет! Уже 2 года ломаю голову, пытался загуглить, но не вышло. Созрел, чтобы задать немного технодрочерский вопрос.Как делается поворот в графических редакторах?Картинка, поясняющая вопрос, прилеплена ниже.Если мы рассматриваем идеальный сферический попиксельный (bmp например) рисунок, это получается просто таблица со значениями в каждой графе. Если мы решаем ее повернуть на любое не кратное π/2 число, у нас начинают обрезаться графы таблицы, они же пиксели.Так вот, вопрос, по какому принципу происходит присвоение значений каждому новому пикселю после поворота? Сравниваются соседние и берется среднее в зависимости от коэффициента попадания в каждый новый пиксель? Или как-то иначе?На поворачиваемых фотографиях не видно особых дефектов, а в моем представлении они явно должны появляться при любой нарезке пикселей и фотография должна сильно терять в качестве. В моем представлении даже таблица с большим числом ячеек 6000*4000 не может дать так просто вертеть себя в разные стороны без особых потерь. Например, при таком повороте, как на скриншоте, при начальных размерах 6000*4000 мы получим 5999*3999 пикселей. Но ведь это будет совершенно другая фотография, с совершенно другими цветами в каждом отдельно взятом пикселе :)З.Ы. Понимаю, что это не совсем по адресу, но вдруг кто сталкивался с вопросом в целях собственного образования :)

  • 1 foto

Kommentaarid

Я дома с сыном математику делаю, а тут еще это:))
Судя по результату поворота маленького изображения – да, усредняются:
  • 2 foto
Просто чем больше размер файла, тем менее это влияет на качество
О, спасибо огромное! Не заметил ответ сразу.Интуитивно я понимаю, что чем больше размер, тем меньше влияет такой пересчет... но это получается из черного и белого пикселя при повороте может получиться среднесерый, а это совершенно другой цвет, блин. И ощущение, что резкость должна сильно плыть после любого поворота. А значит, чтобы сохранить резкость – надо изначально снимать с идеальным горизонтом или при хоть какой-то возможность его не исправлять.Короче, сложно быть математиком-технодрочером. :D
Сразу после этого хочется задуматься о том, когда делается 2-3-4 поворота подряд, т.е. 2-3-4 итерации пересчета пикселей и какая же дичь должна получиться.Но вроде лайтрум всегда пересчитывает все операции обработки на исходный файл, т.е. если много поворотов – он сам пересчитывает все в один поворот. 5 раз менял кларити – он посчитает сумму и наложит только ее на исходник, а не будет делать все 5 итераций)
Как это все работает при конвертации из рава?
Допустим, снятый рав повернули, кропнули и тд. Что происходит в момент нажатия на экспорт?
Мне кажется, если вы и найдете описание таких решений, то в англоязычном инете. Смотрели?
Математически – да, так и есть. Но по факту при 2000-3000 пикселях это только под микроскопом заметно. Тогда уж надо снимать сразу в нужном размере, чтобы не ресайзить лишний раз.
Причем сразу в разрешении конкретного оконечного устройства вывода (печать или экран).А вывод на экран разрешить только в масштабе 100% (так как экранный ресайт – это тоже ресайз).Ну то есть как задачка для мозга – прикольно, а на практике нереализуемо, да и не нужно.
Разные алгоритмы бывают, тут небольшой пример, а дальше уже можно по источникам копать глубже www.leptonica.org/rotat…
Во, это именно то что надо! Спасибо)Одного не понял, зачем они в статье 2/3 текста уделили rotation на 90*n градусов, когда это фактически более тривиальная задача, чем сложение 4х окружающих пикселей в RAM, для которого дана формула в одну строчку)

Logi sisse või Loo konto kommenteerimiseks