## Re: [PyOpenGL-Users] Tricky question on shader

 Re: [PyOpenGL-Users] Tricky question on shader From: Almar Klein - 2011-09-03 20:27:25 Attachments: Message as HTML ```Hi, > I've been playing with gaussian texture filtering using shaders and I > obtained a strange "grid" effect on a completely uniform texture. Since all > fragments get the same processing and same neighbouring values,I wonder if > the grid is the result of some kind of artifact with floating points or the > way texture coordinates are interpolated. Or I missed something completely > obvious… > The Gaussian kernel is in theory infinite. Of course you need to cut it off somewhere, but you should normalize the kernel such that its sum is 1.0. I'm guessing that the fact that your kernel is asymetric does not help either. The code below fixes the pattern: vec4 filter( float x, vec4 c0, vec4 c1, vec4 c2, vec4 c3 ) { float w; w = gaussian(x+1.0); // h.x; float w_sum = w; vec4 r = c0 * w; w = gaussian(x+0.0); // h.y; w_sum += w; r += c1 * w; w = gaussian(1.0-x); // h.z; w_sum += w; r += c2 * w; w = gaussian(2.0-x); // h.w; w_sum += w; r += c3 * w; return r/w_sum; } Also a suggestion. I'm doing something similar in visvis to anti-alias 2D images. I also use a vec4 to represent the kernel, but I make use of the fact that the Gaussian kernel is symetric: kernel[0] is the center element, and kernel[1] to kernel[3] are the 3 elements on each side of the center. This way I get a kernel of effectively 7 elements. Further, I calculate (and normalize) the kernel beforehand in Python, and pass it as a uniform vec4. This way, it does not have to be calculated for each pixel. I'm not sure how significant this is for the speed, but there is a costly exp call in there ... Regards, Almar ```

 [PyOpenGL-Users] Tricky question on shader From: Nicolas Rougier - 2011-08-31 21:48:44 Attachments: filter-gaussian.py ```Hi folks, I've been playing with gaussian texture filtering using shaders and I obtained a strange "grid" effect on a completely uniform texture. Since all fragments get the same processing and same neighbouring values,I wonder if the grid is the result of some kind of artifact with floating points or the way texture coordinates are interpolated. Or I missed something completely obvious… I attached the code below. It is self-contained and you should see the grid I'm talking about. Nicolas ```
 Re: [PyOpenGL-Users] Tricky question on shader From: Ian Mallett - 2011-08-31 22:04:45 Attachments: Message as HTML ```On Wed, Aug 31, 2011 at 3:48 PM, Nicolas Rougier wrote: > > Hi folks, > > I've been playing with gaussian texture filtering using shaders and I > obtained a strange "grid" effect on a completely uniform texture. Since all > fragments get the same processing and same neighbouring values,I wonder if > the grid is the result of some kind of artifact with floating points or the > way texture coordinates are interpolated. Or I missed something completely > obvious… > > I attached the code below. It is self-contained and you should see the grid > I'm talking about. > > Nicolas It feels like the texture coordinates as you calculate them in interpolate(...), and the offsets in filter(...) are to blame. I assume you're trying to do something like a "manual" minification filter using a gauss kernel. Without knowing more about the algorithm, I can't say. My recommendation is to try gamedev.net in the OpenGL forum, as there are a large number of people there who can help. Ian ```
 Re: [PyOpenGL-Users] Tricky question on shader From: Almar Klein - 2011-09-03 20:27:25 Attachments: Message as HTML ```Hi, > I've been playing with gaussian texture filtering using shaders and I > obtained a strange "grid" effect on a completely uniform texture. Since all > fragments get the same processing and same neighbouring values,I wonder if > the grid is the result of some kind of artifact with floating points or the > way texture coordinates are interpolated. Or I missed something completely > obvious… > The Gaussian kernel is in theory infinite. Of course you need to cut it off somewhere, but you should normalize the kernel such that its sum is 1.0. I'm guessing that the fact that your kernel is asymetric does not help either. The code below fixes the pattern: vec4 filter( float x, vec4 c0, vec4 c1, vec4 c2, vec4 c3 ) { float w; w = gaussian(x+1.0); // h.x; float w_sum = w; vec4 r = c0 * w; w = gaussian(x+0.0); // h.y; w_sum += w; r += c1 * w; w = gaussian(1.0-x); // h.z; w_sum += w; r += c2 * w; w = gaussian(2.0-x); // h.w; w_sum += w; r += c3 * w; return r/w_sum; } Also a suggestion. I'm doing something similar in visvis to anti-alias 2D images. I also use a vec4 to represent the kernel, but I make use of the fact that the Gaussian kernel is symetric: kernel[0] is the center element, and kernel[1] to kernel[3] are the 3 elements on each side of the center. This way I get a kernel of effectively 7 elements. Further, I calculate (and normalize) the kernel beforehand in Python, and pass it as a uniform vec4. This way, it does not have to be calculated for each pixel. I'm not sure how significant this is for the speed, but there is a costly exp call in there ... Regards, Almar ```
 Re: [PyOpenGL-Users] Tricky question on shader From: Nicolas Rougier - 2011-09-03 21:20:15 Attachments: Message as HTML ```Thanks for the explanation. In fact, in the "real" implementation, I also used a texture lookup to store kernel values (see GPU gems 24) and read them when needed. I was trying to normalize my kernel before storing it but your code is easier to use. For visvis, you might be interested in the different weight functions (I translated those of the antigrain library that are used in matplotlib): http://code.google.com/p/glumpy/source/browse/glumpy/image/filter.py http://code.google.com/p/glumpy/source/browse/glumpy/image/filter.vert http://code.google.com/p/glumpy/source/browse/glumpy/image/filter.frag Thanks again, you made my day ! Nicolas On Sep 3, 2011, at 22:27 , Almar Klein wrote: > Hi, > > I've been playing with gaussian texture filtering using shaders and I obtained a strange "grid" effect on a completely uniform texture. Since all fragments get the same processing and same neighbouring values,I wonder if the grid is the result of some kind of artifact with floating points or the way texture coordinates are interpolated. Or I missed something completely obvious… > > The Gaussian kernel is in theory infinite. Of course you need to cut it off somewhere, but you should normalize the kernel such that its sum is 1.0. I'm guessing that the fact that your kernel is asymetric does not help either. > > The code below fixes the pattern: > > vec4 > filter( float x, vec4 c0, vec4 c1, vec4 c2, vec4 c3 ) > { > float w; > > w = gaussian(x+1.0); // h.x; > float w_sum = w; > vec4 r = c0 * w; > > w = gaussian(x+0.0); // h.y; > w_sum += w; > r += c1 * w; > > w = gaussian(1.0-x); // h.z; > w_sum += w; > r += c2 * w; > > w = gaussian(2.0-x); // h.w; > w_sum += w; > r += c3 * w; > > return r/w_sum; > } > > > Also a suggestion. I'm doing something similar in visvis to anti-alias 2D images. I also use a vec4 to represent the kernel, but I make use of the fact that the Gaussian kernel is symetric: kernel[0] is the center element, and kernel[1] to kernel[3] are the 3 elements on each side of the center. This way I get a kernel of effectively 7 elements. Further, I calculate (and normalize) the kernel beforehand in Python, and pass it as a uniform vec4. This way, it does not have to be calculated for each pixel. I'm not sure how significant this is for the speed, but there is a costly exp call in there ... > > Regards, > Almar > > ```
 Re: [PyOpenGL-Users] Tricky question on shader From: Almar Klein - 2011-09-04 11:22:30 Attachments: Message as HTML ```> > For visvis, you might be interested in the different weight functions (I > translated those of the antigrain library that are used in matplotlib): > > http://code.google.com/p/glumpy/source/browse/glumpy/image/filter.py > http://code.google.com/p/glumpy/source/browse/glumpy/image/filter.vert > http://code.google.com/p/glumpy/source/browse/glumpy/image/filter.frag > You're right, a Gaussian filter is probably not the best choice for aa. I took a look at your filters and implemented a Lanczos filter (with dynamic bandwith depending on image scale). Looks much better because it does not blur so much. Thanks! Almar ```