Вычисление Pixel Bender по всем пикселам

Question

Что я хочу (в основном) так же, как «суммировать все пиксели изображения». Однако кажется, что это невозможно достичь с помощью шейдера (я думаю, именно поэтому я прошу ;-)):

Я хочу передать изображение + параметр «деревья» и проверить каждый пиксель изображение, если этот пиксель (R, G, B) IS находится в позиции (R +/-, G +/-, B +/-).

Операция IS IN в порядке, ничего сложного.

Дело в том, что мне нужен SUM всего пикселя (счет), который сделал это на изображении.

Идея использования шейдеров сводит к минимуму этот расчет, потому что в CPU очень дорого (кроме того, мы должны повторять эту какуляцию несколько раз).

Одна идея состоит в том, чтобы выставить вектор (0,0,0), если пиксель не достигнет и (1,0,0), если пиксель достигнет, а затем в программном обеспечении суммирует весь первый канал.

Даже если это происходит быстрее, используя только программное обеспечение, мы по-прежнему перемещаем изображение NXM для суммы.

Другой способ (не так точно) - сделать это для (например) 10 соседних пикселей (и опускать вычисление, если «im сосед»). . Затем мы будем суммировать массив каждые 10 позиций. Мы делаем 10 раз быстрее, однако у нас все еще есть O (N * M).

Кроме того, я считаю, что мы можем использовать что-то вроде этого, но я совершенно не понимаю, как использовать это в Pixel Bender Efficient pixel shader sum of all pixels

Спасибо заранее для любого другого решения.

Answer 1

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

Одна возможность состоит в том, чтобы написать фильтр, который выписывает на сумму площади 10х10, начиная с [(coord.x * 10.0), (coord.y * 10.0)]

Каждый удар, этот фильтр будет уменьшить площадь, вы заботитесь о том, чтобы 1/10.

Таким образом, наибольший размер изображения во Flash составляет 8192 пикселя, вам нужно будет запустить этот фильтр четыре раза, чтобы получить ответ в верхнем левом пикселе.

Вы можете оптимизировать его несколькими способами. Во-первых, каждый из них запускается после первого, вы можете просто передать ему верхнюю левую десятую предыдущего выходного изображения, поэтому ему нужно обработать только 1% пикселей каждого прогона; во-вторых, вы можете передать параметр Float2, содержащий 1/10-ю ширину и высоту изображения, и попросите код пропустить суммирование и просто установите выходной пиксель на 0, если coord.x или coord.y находится за пределами этого.

С помощью этих оптимизаций ваш первый проход будет считываться в каждом пикселе; второй будет читать 1% пикселей; третий будет читать 0,01%; а в финале будет 0.0001%. Таким образом, все проходит после того, как первое не должно ничего добавить к вашему времени обработки.

Все это предполагает, что вы используете алгоритм контрольной суммы, который может иметь ответ, уплотненный до одного пикселя, и где ноль не влияет на результаты. Побитовое XOR было бы идеальным, но побитовые операторы не существовали бы в PB.:(