An efficient compute-shaded image filter would be emitted with (screenX / [kernel width], screenY / [kernel height], 1) groups and one kernel in each group, allowing texels to pass into groupshared memory and reducing the total number of samples at each pixel. But it seems like this will only apply the filter within the patches defined by each thread-group and create aliasing between them. Why doesn't this happen? If it does happen, how is it mitigated?

  • 1
    $\begingroup$ It's been a long while I've done any image processing but f I understand correctly you are talking about the convolution operation applied to images with a kernel matrix? In that case the kernel is applied on every pixel. Your local workgroup size is (kernel width, kernel height,1). If you apply the operation to every pixel in this group, then it'd equal to just looping every pixel in the entire image and applying the kernel. Why would there be aliasing? $\endgroup$ – gallickgunner Feb 18 '19 at 4:09
  • 2
    $\begingroup$ Ah if you are thinking it like that sure. I had a different picture in mind. You don't necessarily need to share information. If you pass the image as image2D you could just calculate the indices for the pixels required by the edge pixel in a group. Although half of those will lie in the other groups, you can still read from the image at those pixels assuming you are not reading and writing from the same image. You can't anyway i think there should be 2 images, one for reading and other for the filtered one. $\endgroup$ – gallickgunner Feb 18 '19 at 4:28
  • 1
    $\begingroup$ @PaulFerris I have an issue with your definition of aliasing (it means something entirely different in image processing than what you have in mind). As far as the fourier domain goes, it will let you convolve your image efficiently with large filters by simply multiplying two fourier transformed images. There's a tradeoff obviously of going to the fourier domain and back. This can be done through FFT though which is $O(n\log n)$. So it really depends on your kernel size whether it's better/more efficient. $\endgroup$ – lightxbulb Feb 18 '19 at 19:10
  • 2
    $\begingroup$ @PaulFerris Not really, 5x5 is small enough for you to do it directly, just use a texture for input and a texture for output. The other thing that you can look into (for more specialized cases) is summed area tables/integral images, which let you perform arbitrary region box filtering in constant time. There's generalizations to other filters foo, but it does require preprocessing of the image (can be done in parallel though). $\endgroup$ – lightxbulb Feb 18 '19 at 20:00
  • 1
    $\begingroup$ @PaulFerris I don't think it would make sense for what you want to do. Just do it normally, I don't think you can get rid of the fact that for each pixel you have to sample a different subset of the image. Just implement it and profile. $\endgroup$ – lightxbulb Feb 19 '19 at 10:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.