Билинейная интерполяция от C до неона
Я пытаюсь уменьшить изображение с помощью Neon. Поэтому я попытался использовать неон, написав функцию, которая вычитает два изображения с использованием неона, и у меня все получилось.
Теперь я вернулся, чтобы написать билинейную интерполяцию, используя неоновые свойства.
Сейчас у меня две проблемы: получить 4 пикселя из одной строки и одного столбца, а также вычислить интерполированное значение (серое) из 4 пикселей или, если это возможно, из 8 пикселей из одной строки и одного столбца. Я пытался думать об этом, но я думаю, что алгоритм должен быть переписан вообще?
void resizeBilinearNeon( uint8_t *src, uint8_t *dest, float srcWidth, float srcHeight, float destWidth, float destHeight)
{
int A, B, C, D, x, y, index;
float x_ratio = ((float)(srcWidth-1))/destWidth ;
float y_ratio = ((float)(srcHeight-1))/destHeight ;
float x_diff, y_diff;
for (int i=0;i<destHeight;i++) {
for (int j=0;j<destWidth;j++) {
x = (int)(x_ratio * j) ;
y = (int)(y_ratio * i) ;
x_diff = (x_ratio * j) - x ;
y_diff = (y_ratio * i) - y ;
index = y*srcWidth+x ;
uint8x8_t pixels_r = vld1_u8 (src[index]);
uint8x8_t pixels_c = vld1_u8 (src[index+srcWidth]);
// Y = A(1-w)(1-h) + B(w)(1-h) + C(h)(1-w) + Dwh
gray = (int)(
pixels_r[0]*(1-x_diff)*(1-y_diff) + pixels_r[1]*(x_diff)*(1-y_diff) +
pixels_c[0]*(y_diff)*(1-x_diff) + pixels_c[1]*(x_diff*y_diff)
) ;
dest[i*w2 + j] = gray ;
}
}
Решение
@MarkRansom неверен в отношении ближайшего соседа по сравнению с билинейной интерполяцией 2×2; Билинейное использование 4 пикселей даст лучший результат, чем у ближайшего соседа. Он прав, что усреднение соответствующего количества пикселей (больше 4, если масштабирование> 2: 1) все равно даст лучший результат. Однако NEON не поможет с понижением частоты дискретизации изображения, если масштабирование не выполняется целочисленным соотношением.
Максимальное преимущество NEON и других наборов команд SIMD — возможность обрабатывать 8 или 16 пикселей одновременно, используя одни и те же операции. Получая доступ к отдельным элементам таким, какой вы есть, вы теряете все преимущества SIMD. Другая проблема заключается в том, что перемещение данных из NEON в регистры ARM является медленной операцией. Изображения с понижающей дискретизацией лучше всего выполнять с помощью графического процессора или оптимизированных инструкций ARM.
Другие решения
Неон определенно поможет с понижающей дискретизацией в произвольном соотношении, используя билинейную фильтрацию. Ключ является умным использованием инструкции vtbl.8, которая способна выполнить параллельную таблицу соответствия для 8 последовательных пикселей назначения из предварительно загруженного массива:
d0 = a [b] c [d] e [f] g h, d1 = i j k l m n o p
d2 = q r s t u v [w] x, d3 = [y] z [A] B [C][D] E F ...
d4 = G H I J K L M N, d5 = O P Q R S T U V ...
Можно легко вычислить дробные позиции для пикселей в скобках:
[b] [d] [f] [w] [y] [A] [C] [D], accessed with vtbl.8 d6, {d0,d1,d2,d3}
The row below would be accessed with vtbl.8 d7, {d2,d3,d4,d5}
Увеличение вадд.8 д6, д30; с d30 = [1 1 1 1 1 … 1] дает индексы поиска для пикселей справа от начала координат и т. д.
Нет никакой причины получать пиксели из двух строк, кроме иллюстрации того, что это возможно, и что этот метод может быть использован для реализации небольших искажений, если это необходимо.
В приложениях реального времени, например, с использованием из lanzcos может быть немного излишним, но все же возможно с использованием NEON. Понижение дискретизации по более крупным факторам требует, конечно, (тяжелой) фильтрации, но ее можно легко достичь с помощью итеративного усреднения и децимации 2: 1 и только в конце, используя дробную выборку.
Для записи любых 8 последовательных пикселей можно рассчитать вектор
x_positions = (X + [0 1 2 3 4 5 6 7]) * source_width / target_width;
y_positions = (Y + [0 0 0 0 0 0 0 0]) * source_height / target_height;
ptr = to_int(x_positions) + y_positions * stride;
x_position += (ptr & 7); // this pointer arithmetic goes only for 8-bit planar
ptr &= ~7; // this is to adjust read pointer to qword alignment
vld1.8 {d0,d1}, [r0]
vld1.8 {d2,d3], [r0], r2 // wasn't this possible? (use r2==stride)
d4 = int_part_of (x_positions);
d5 = d4 + 1;
d6 = fract_part_of (x_positions);
d7 = fract_part_of (y_positions);
vtbl.8 d8,d4,{d0,d1} // read top row
vtbl.8 d9,d5,{d0,d1} // read top row +1
MIX(d8,d9,d6) // horizontal mix of ptr[] & ptr[1]
vtbl.8 d10,d4,{d2,d3} // read bottom row
vtbl.8 d11,d5,{d2,d3} // read bottom row
MIX(d10,d11,d6) // horizontal mix of ptr[1024] & ptr[1025]
MIX(d8,d10,d7)
// MIX (dst, src, fract) is a macro that somehow does linear blending
// should be doable with ~3-4 instructions
Для вычисления целых частей достаточно использовать разрешение 8,8 бит (на самом деле не нужно вычислять 666+ [0 1 2 3 .. 7]) и сохранять все промежуточные результаты в регистре simd.
Отказ от ответственности — это концептуальный псевдо-с / векторный код. В SIMD необходимо оптимизировать две параллельные задачи: каков минимальный объем арифметических операций и как минимизировать ненужное перетасовывание / копирование данных. В этом отношении также NEON с подходом с тремя регистрами намного лучше подходит для серьезного DSP, чем для SSE. Второе отношение — это количество инструкций умножения, а третье преимущество — команды перемежения.