[DRUID3 0]

Кажется ясно изложу:

 

Есть 4 отсчета: 1 2 3 4

а нужно получить 3

 

4*3 = 12

 

111 222 333 444

 

(1+1+1)/3 = 1

 

1112 2233 3444

 

1.25 2.5 3.75

 

Правда пользуюсь таким при изменении масштаба одномерных графиков...

 

А оно Вам надо? Сплайны, интерполяция,... А в результате все резкие границы будут размыты.

Может быть проще выкусывать лишние строчки/столбцы? (каждый 9-й столбец и каждую 6-ю строчку). И соответственно добавлять в случае увеличения разрешения (сами посчитайте сколько) :)

Очень дилетанский подход... по сути то что Вы предложили децимация со всеми вытекающими... Самые высокочастотные данные будут просто уничтожены и не внесут свой вклад в картинку. Так раньше масштабировала XnView и в сравнении с ACDSee - разница была просто разительной, а масштабированная прореживанием картинка - ужасной...

[YuryL 0]

Есть замечательная програмка VirtualDub для преобразования видео

форматов включая ресемплинг по различным алгоритмам. Кроме всего

прочего это открытый проект, можно посмотреть исходники.

 

http://www.virtualdub.org/index

[torik 0]

Ну в общем-то, алгоритмы действительно довольно четко изложены в документации на соответствующие компоненты SOPC Builder...

Сейчас пытаюсь запустить scaler альтеровский, с входным изображением 32*32, а выходным 640*480 и простейшим алгоритмом работы ("ближайший пиксель") - что-то нифига не получается... Видно, что-то похожее на должный результат, но изображение дергается.

 

Компонент длеаю визардом, не в сопц. Непонятно, как ему определять начало кадра/строки. Потому кадровый импульс завожу на reset. Кто пользовался, поделитесь опытом применения/тестирования средствами квартуса...

[torik 0]

Ну, вот, значит... опробовал scaler альтеровский в деле - все заработало. Единственное, надо его со всех сторон фифами окружать))). Но использую не в SOPC, а просто через мегавизард и вручную прикручиваю...

Синхронизация, как и говорил - сбросом...

[AlexZabr 0]

Ну в общем-то, алгоритмы действительно довольно четко изложены в документации на соответствующие компоненты SOPC Builder...

Сейчас пытаюсь запустить scaler альтеровский, с входным изображением 32*32, а выходным 640*480 и простейшим алгоритмом работы ("ближайший пиксель") - что-то нифига не получается... Видно, что-то похожее на должный результат, но изображение дергается.

 

Компонент длеаю визардом, не в сопц. Непонятно, как ему определять начало кадра/строки. Потому кадровый импульс завожу на reset. Кто пользовался, поделитесь опытом применения/тестирования средствами квартуса...

 

Извините, не совсем понял...вы берете 32х32 пикселя и раздуваете на 640х480 ? Т.е. scale-up в 300 раз (по площади) ??? :cranky:

Методом nearest ?

[torik 0]

Ну да, сперва так и делал для простоты, чтобы отбросить работу с динамической памятью и прочим. А в результате сплющиваю 720*576 до 640*480. Использую линейную интреполяцию - она вроде и ресурсов не так много требует и по качеству вполне приемлема.

[AlexZabr 0]

Ну да, сперва так и делал для простоты, чтобы отбросить работу с динамической памятью и прочим. А в результате сплющиваю 720*576 до 640*480. Использую линейную интреполяцию - она вроде и ресурсов не так много требует и по качеству вполне приемлема.

 

Понял, спасибо.

А как насчет искажений aspect ratio ? или было приемлимо под конкреное задание ?

Если не секрет, как распределились ресусрсы ? (сколко памяти например ?)

[torik 0]

Качество приемлемое. Ухудшений по сравнению с первоначальной картинкой вообще не заметил...

Линейная интерполяция съела 1260 LC, 34 кбит памяти, 12 умножителей...

Это не считая ФИФО вокруг с логикой...

[denisys 0]

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

xscale.vhd

[AlexZabr 0]

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

 

Спасибо, тоже полезная инфа.

В моем случае тоже будет черно-белое изображение (растр) с наложенным цветом (векторное, менюшки и т.д.)

Нужно будет проработать инфу данную в ветке, думаю попробую наброски нескольких алгоитмов в Матлабе на клипах, а там посмотрим...

[AlexZabr 0]

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

 

Кстати, вопрос в догонку...

Сама идея scalingа сходна фактически decimation/interpolation понятиями в DSP. А там подразумевается LPF до/после операций decimation/interpolation соответственно в целях anti-aliasing/anti-imaging.

 

Тогда, IMHO и в плане image processing (а scaling картинки и есть image processing) по идее после операции интерполяции нужно применить соотв. LPF (только двухмерное, ессно..). Предусмотрено ли это и в преложенных стандартных алгоритмах Альтеры и им подобных ? Или оно не обязательно по каким-либо причинам ? (почему ?)

[denisys 0]

Тогда, IMHO и в плане image processing (а scaling картинки и есть image processing) по идее после операции интерполяции нужно применить соотв. LPF (только двухмерное, ессно..). Предусмотрено ли это и в преложенных стандартных алгоритмах Альтеры и им подобных ? Или оно не обязательно по каким-либо причинам ? (почему ?)

 

При интерполяции вначале между исходными отсчетами вставляют нулевые, а затем ФНЧ. При прореживании вначале ФНЧ, затем выбирают требуемые отсчеты. Все это относится к изменению частоты выборок в целое число раз. Для дробного коэффициента масштабирования в идеале пришлось бы делать вначале интерполяцию, ФНЧ, затем прореживание. В моем случае выполняется апроксимация всего выше сказанного более простой функцией, следовательно, ФНЧ не нужен. Не могу сказать на сколько результат далек от идеала, но для данного применения результат меня удовлетворил.

 

В альтеровском примере, который я взял за отправную точку ФНЧ не было.

Edited June 16, 2008 by denisys

[dmitry-tomsk 1]

Кстати, вопрос в догонку...

Сама идея scalingа сходна фактически decimation/interpolation понятиями в DSP. А там подразумевается LPF до/после операций decimation/interpolation соответственно в целях anti-aliasing/anti-imaging.

 

Тогда, IMHO и в плане image processing (а scaling картинки и есть image processing) по идее после операции интерполяции нужно применить соотв. LPF (только двухмерное, ессно..). Предусмотрено ли это и в преложенных стандартных алгоритмах Альтеры и им подобных ? Или оно не обязательно по каким-либо причинам ? (почему ?)

 

Фильтрация есть в варианте с Lanczos. Алгоритм основан на ФНЧ, симметричная весовая функция центрируется в нужном дробной координате и вычисляется интерполированное значение. Для увеличения разрешения это только интерполяция, а для уменьшения это и интерполяция по нецелочисленной сетке и фильтрация для устранения элайзинга. Для проверки качества итересны изображения типа zoneplate (выглядит как вложенные окружности), которые содержать весь спектр пространственных частот и при прореживании в случае некачественной фильтрации на изображении появляюся чёткие дополнительные окружности.

[EvgY 0]

Добрый день.

Думаю при Ваших коэффициентах масштабирования изображения Вам вполне будет достаточно в качестве алгоритма масштабирования линейной интерполяции. Более продвинутые алгоритиы сильный прирост качества изображения Вам не дадут, а вот количество ресурсов и сложность алгоритмов повысят сильно.

Фильтрация для устранения алиасинга в Вашем случае тоже не нужна, так как ее следует применять при коэффициенте уменьшения изображения больше 2 (так как при больших коэффициентах вы начнете терять информацию об исходных пикселах при прореживании), да и при 2 эффект алиасинга не очень заметен.

Следует учитывать, что для устранения алиасинга обычно ставят размывающий фильтр на входе, что повлечет за собой размытие изображения, которое в ряде применений не допустимо. Да и при фильтрации вам понадобится дополнительная внутренняя память для буферизации при вертикальной фильтрации.

Для расчета коэффициентов линейной интерполяции могу предложить алгоритм Брезенхема (коротко):

 

 

Допустим, у нас есть пять исходных точек с номерами 0..4 и нам надо выбрать из них четыре, так, чтобы первая выбранная точка (ее номер 0) совпала с первой (номер 0) исходной и последняя выбранная (номер 3) совпала с последней исходной (номер 4).

Точки подаются последовательно в виде пар (текущая, следующая = текущая+1).

Шаг перемещения равен 1+1/3 (числа записываются либо в десятичной системе счисления, либо как целая_часть+дробная_часть). Шаг определяется как кол-во точек до масштабирования - 1 разделить на кол-во точек после масштабирования -1. Таким образом при увеличении целая часть = 0, а при уменьшении 1 и более.

Алгоритм Брезенхема использует текущую сумму (изначально равна шагу перемещения). Если целая часть равна нулю, то на выход мы выдаем текущую дробную часть в качестве веса интерполяции и обновляем сумму прибавлением полного шага. Если целая часть не равна нулю, то мы выдаем запрос на передвижение входной пары и отнимаем от целой части 1, обновляя сумму.

 

Получается универсальный алгоритм, работающий при любых коэффициентах масштабирования, однако, если у Вас фиксированные разрешения, то можно также фиксированно и сделать

[AlexZabr 0]

При интерполяции вначале между исходными отсчетами вставляют нулевые, а затем ФНЧ. При прореживании вначале ФНЧ, затем выбирают требуемые отсчеты. Все это относится к изменению частоты выборок в целое число раз. Для дробного коэффициента масштабирования в идеале пришлось бы делать вначале интерполяцию, ФНЧ, затем прореживание. В моем случае выполняется апроксимация всего выше сказанного более простой функцией, следовательно, ФНЧ не нужен. Не могу сказать на сколько результат далек от идеала, но для данного применения результат меня удовлетворил.

 

В альтеровском примере, который я взял за отправную точку ФНЧ не было.

 

Да, это десимация подразумевает antialiasing LPF до, а интерполяция anti-imaging LPF после, это понятно.

Полное rate conversion, если память мен не изменяет составляет цепочку интерполятора, дециматора с их соотв. фильтрами, как и упомянули, и наш случай видимо как раз подходит под такое определение.

Апроксимация этого имеется ввиду что ими предложенный алгоритм (Альтерой), ввиду того что он не вставляет нули а взвешенные значения, обходит надобность в LPF по выходу ?