1

Is anyone else having any problems when the kernel size > 255?

The error I'm getting looks like the color channels are overloading...but only when kernel size is > 255. The documentation says nothing about the limits of the kernel size. And vImage is not returning an error.

BTW, I'm using vImageBoxConvolve_ARGB8888. It happens on any image, and specifically in the white areas.

Here's an output: enter image description here

That multicolor mess in the top left is really just a bright background.

Seems odd that with all the blurring going on these days that no one else would be getting this.

Thanks.

pizzafilms
  • 3,829
  • 4
  • 24
  • 39
  • 1
    Are you sure you want to use a convolution with a width greater than 255? That's an awful lot of computations to perform per pixel. For blurs, a downsampling followed by an upsample, coupled with a few other optimizations, can cut that down dramatically: http://www.sunsetlakesoftware.com/2013/10/21/optimizing-gaussian-blurs-mobile-gpu . I'm not surprised you're seeing artifacts when doing a convolution this large with a non-float type, due to issues with dynamic range. – Brad Larson Nov 25 '13 at 23:29
  • I'm having a similar issue: http://stackoverflow.com/questions/32677548/uiimageeffects-white-image-when-gaussian-radius-above-280-vimageboxconvolve-ar – Archagon Sep 20 '15 at 09:36
  • Having such a high kernel size is useful when you're trying to (for example) normalize a Gaussian blur across different resolutions. If you want to have the same amount of blur for height 1024 as, say, height 8000, you're gonna have to crank that kernel size up quite a bit. – Archagon Sep 20 '15 at 09:38
  • Brad, vImage uses a (mostly) constant cost algorithm for box and tent. The kernel radius doesn't affect performance much. That is why people use it for large blurs. – Ian Ollmann Oct 07 '15 at 21:56

1 Answers1

1

Box convolve has (roughly) constant cost regardless of kernel size, so it and tent are the filters to use for large convolve. I am surprised that a 255*255 kernel is enough to overflow. We should be using a 32-bit signed accumulator here. Maybe tent might overflow at that size. I suggest filing a bug with a reproducible example.

http://bugreporter.apple.com

Ian Ollmann
  • 11
  • 1