Jump to content

  • Log In with Google      Sign In   
  • Create Account


Adding up pixels in a texture


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 mv348   Members   -  Reputation: 249

Like
0Likes
Like

Posted 27 January 2013 - 02:02 PM

Let's say I have a 32x32 texture containing ints, or floats. I am trying to come up with a very fast method of adding up all the values in the texture using OpenGL.

 

I was thinking I could possibly set the texture minification filter to GL_LINEAR and render it into a texture half the size (16x16). According to the documentation:

GL_LINEAR:

Returns the weighted average of the four texture elements
                                        that are closest to the specified texture coordinates.

 

If the texture rendered into is half the size I believe the weighted average will be the same as the average. Moreover, the average of a new pixel will be (sum of 4 old pixels)/4.

 

So I'm thinking if I render from a 32x32 texture into a 16x16, and then into 8x8, 4x4, 2x2 and 1x1, and then use glReadPixel( ... ) I will get the (sum of all pixels )/4^5.

 

4^5 = 1024 so I can either pre-multiply the texture values by 1024 or divide the result by 1024. I think the former would be more appropriate for ints to avoid roundoff error. I could maybe even use bit-shifting to multiply by 1024 for added speed.

 

What do you think of this idea? Do you have a better one?


Edited by mv348, 27 January 2013 - 08:17 PM.


Sponsor:

#2 Geometrian   Crossbones+   -  Reputation: 1432

Like
0Likes
Like

Posted 28 January 2013 - 12:15 AM

I actually encountered the exact same problem in the context of a toy image compression algorithm. I tried exactly that, except I made a mipmap and then read back the one texel to the client side and multiplied by the texture's area.

 

It turned out that this did not have quite enough accuracy for my needs, since you lose accuracy with each average operation (and there are log2(max(n,m)) such operations)--though I strongly suspect it might have been acceptable had floating point textures been available.

 

Certainly, this will be the fastest way. The GPU is great as these sort of things, and texture accesses will generally be more cache coherent on the GPU than the CPU.


And a Unix user said rm -rf *.* and all was null and void...|There's no place like 127.0.0.1|The Application "Programmer" has unexpectedly quit. An error of type A.M. has occurred.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS