- Сообщения
- 1 337
- Реакции
- 485
Ответ: Обидный глюк
Неа, в миллиметрах ((
На пикселях начало появляться, но очень редко, где-то 1:20
Что самое интересное, при интерполляции методом Nearest Neighbor в преференсах, всегда всё делает правильно, ни разу не глюкануло.
Думаю, данная болезнь связан с "неправильной" привязкой выделения к пиксельной разметки файла. Я когда-то писал о методах интерполляции и привязкой к пиксельной разметки, -- о смешивание пикселей, и формуле по которой идёт это смешивание, или появление прозрачности при повороте прямой линии.
Мысли пока такие: при попытке увязать N заданных пикселей при кропе, к получаемой генерируемой картинке мы получем дробь -- соотношение значений кропа к желаемому(выделенному вручную) куске изображения.
Так как установка Nearest Neighbor подразумевает отсечение дроби(огругление), то программа отстраивает нам изображение и в алгоритме участвуют только целые числа.
!имееться в виду расположение новоиспечённых пикселей X,Y которые просто "мигрируют" на своё новое место вычисляемое исходя из угла наклона нашего кропа. По такому же алгоритму выстраиваються прямые углы желаемого изображения, усё строго.
В случаи с бикубическими перобразованиями идёт смешивание пикселей (по цвету или прозрачности), и в формуле пересчёта присутствуют дроби, которые вносят "смуту" (возможно не правильно округляються) в отстройку прямых углов нашего получаемого растра.
Именно, как я считаю, из-за неправильного определения программой прямого угла у нас происходит искажение изображение, так как-будто две его паралельные стороны стянули(на подобе Transform>Distort) на определённый угол -- угол который вычислен с погрешностью.
Почему глючит именно со значеними заданных в пикселях? Наверное потому что при просчёте изображения mm или in переводяться на пиксели, которые имеют дробь (странно, вы скажете пиксель с дробью не бывает, но это только для алгоритма -- на выходе целые числа). И именно эта дробь, определяющая -ТОЧНОЕ- значение длин играет в нашу пользу -- погрешность очень маленькая.
А в случаи с пикселями, попытке связать целые значения с целыми, появляеться (наверное в алгоритме сбой) погрешность и как следствие не правильное "понимание" программой углов.
Может еще рано кричать, но кажись Это ГЛЮК!
Нужно еще поразбираться, и возможно будет что написать Адобовцам
Кстати кто-нить может проверить на более ранних версиях с разными настройками интерполляции и написать в этот топик о соих результатах.
Еще есть мысль, но пока надо проверить...
(понимание программы что значени кропа, отношение введённых X к Y он воспринимает правильно, а не приводить к ближайшему значению в алгоритме)
sander сказал(а):to NecroZoider
А Crop у тебя в пикселях выставлен ? Покажи чего там ?
Я сдаюсь ! (мож какие-нить региональные настройки повлияли)
Неа, в миллиметрах ((
На пикселях начало появляться, но очень редко, где-то 1:20
Что самое интересное, при интерполляции методом Nearest Neighbor в преференсах, всегда всё делает правильно, ни разу не глюкануло.
Думаю, данная болезнь связан с "неправильной" привязкой выделения к пиксельной разметки файла. Я когда-то писал о методах интерполляции и привязкой к пиксельной разметки, -- о смешивание пикселей, и формуле по которой идёт это смешивание, или появление прозрачности при повороте прямой линии.
Мысли пока такие: при попытке увязать N заданных пикселей при кропе, к получаемой генерируемой картинке мы получем дробь -- соотношение значений кропа к желаемому(выделенному вручную) куске изображения.
Так как установка Nearest Neighbor подразумевает отсечение дроби(огругление), то программа отстраивает нам изображение и в алгоритме участвуют только целые числа.
!имееться в виду расположение новоиспечённых пикселей X,Y которые просто "мигрируют" на своё новое место вычисляемое исходя из угла наклона нашего кропа. По такому же алгоритму выстраиваються прямые углы желаемого изображения, усё строго.
В случаи с бикубическими перобразованиями идёт смешивание пикселей (по цвету или прозрачности), и в формуле пересчёта присутствуют дроби, которые вносят "смуту" (возможно не правильно округляються) в отстройку прямых углов нашего получаемого растра.
Именно, как я считаю, из-за неправильного определения программой прямого угла у нас происходит искажение изображение, так как-будто две его паралельные стороны стянули(на подобе Transform>Distort) на определённый угол -- угол который вычислен с погрешностью.
Почему глючит именно со значеними заданных в пикселях? Наверное потому что при просчёте изображения mm или in переводяться на пиксели, которые имеют дробь (странно, вы скажете пиксель с дробью не бывает, но это только для алгоритма -- на выходе целые числа). И именно эта дробь, определяющая -ТОЧНОЕ- значение длин играет в нашу пользу -- погрешность очень маленькая.
А в случаи с пикселями, попытке связать целые значения с целыми, появляеться (наверное в алгоритме сбой) погрешность и как следствие не правильное "понимание" программой углов.
Может еще рано кричать, но кажись Это ГЛЮК!
Нужно еще поразбираться, и возможно будет что написать Адобовцам
Кстати кто-нить может проверить на более ранних версиях с разными настройками интерполляции и написать в этот топик о соих результатах.
Еще есть мысль, но пока надо проверить...
(понимание программы что значени кропа, отношение введённых X к Y он воспринимает правильно, а не приводить к ближайшему значению в алгоритме)