0

What I want is (basically) the same as "sum all the pixels of an image". However it seems that this can not be achieved by shader (I think that is why I'm asking ;-)):

I want to pass the image + a parameter "treeshold" and check for each pixel of the image if that pixel(R,G,B) IS IN the treshold (R+/-,G+/-,B+/-).

The IS IN operation is ok, nothing complicated.

The thing is I need the SUM of all pixel (the count) that accomplished this in the image.

The idea of using shader is minimize this calculation because in CPU is very expensive (besides, we have to repeat this caculation several times).

One Idea is to put as an output a vector (0,0,0) if the pixel not achieves and a (1,0,0) if the pixel achieves, then in software summ all the first channel.

Even when this is faster that using only software, we are still traveling an NXM image for the sum.

Another way (not so accuracy) is to do this for (for example) 10 neighbor pixels (and omitting the calculation if "im a neighbor"). Then we only will sum array each 10 position. We make 10 times faster, however, we still have O(N*M).

Also, i believe we can use something like this, but i quite do not understand how to use this in pixel bender Efficient pixel shader sum of all pixels

Thanks in advance for any other solution.

Community
  • 1
  • 1
voskyc
  • 127
  • 3
  • 14
  • This is easier to do with a compute shader where you can operate on image blocks and then combine results using atomics. What platform / hardware are you targeting? – mattnewport Oct 09 '13 at 03:35
  • hi, I do not understand your answer. We are working over Flash (pxiel bender), Flas has several importan limitation voer pixel bender, in particular you do not have loops or any other control structure beyond "if" and "else", if we have, I coud just calculate this with a simple for and askinf for "nearest" pixels. Thanks. – voskyc Oct 09 '13 at 13:55

1 Answers1

0

You might want to consider a divide and conquer approach, running the filter multiple times.

One possibility is to write a filter that writes out the sum of the 10x10 area starting at [(coord.x * 10.0), (coord.y * 10.0)]

Each pass, this filter will reduce the area you care about to 1/10th.

So, the largest possible image dimension in Flash being 8192 pixels, you'd have to run this filter four times to get your answer in the top left pixel.

You can optimize it a couple of ways. First is that each run after the first, you can just pass it the top-left tenth of the preceding output image,so it only has to process 1% of the pixels each run; second is that you can pass in a Float2 parameter containing 1/10th the image's width and height, and have your code skip the summing and just set the output pixel to 0 if coord.x or coord.y is outside that.

With these optimizations, your first pass will read in each pixel; the second will read 1% of the pixels; the third will read 0.01%; and the final will read 0.0001%. So all passes after the first shouldn't add anything much to your processing time.

This all assumes that you're using a checksum algorithm which CAN have the answer compacted down to a single pixel, and where zero doesn't affect the results. Bitwise XOR would be ideal, but bitwise operators don't exist in PB. :(

Dewi Morgan
  • 1,143
  • 20
  • 31