From: Ian Scott <ian.scott@st...>  20031208 20:12:54

> Original Message > From: Matt Leotta [mailto:mleotta@...] > 1) Most functions in vil_gauss_filter are specialized for 5 element > kernels except for vil_gauss_filter_gen_ntap. Is there a reason why > this exist, but there are no functions to directly use a > gaussian filter > of n elements? I've written a simple helper function (added to > vil_gauss_filter.txx) that creates a kernel using > vil_gauss_filter_gen_ntap and applies it to an image view in both > directions with vil_convolve_1d. Is there any reason for me not to > commit this addition to vil_gauss_filter? The main reason why it wasn't written is that it is a trivial piece of code. The 5tap gaussian filter is a rather specialised piece of code designed to do variable scale smoothing for building Gaussian pyramids with scale step between 1 and 2. (See contrib/mul/vimt.) It does it efficiently, especially with regards to edge effects, which are important in a pyramid. > 2) The elements of the gaussian kernel are computed using the vnl_erf > function. When compared to a normalized kernel computed with > vcl_exp((x*x)/(2.0*sigma*sigma)) (same size and sigma) the values are > slightly different. For some reason subtracting ~0.05 from any sigma > value before creating the kernel with vil_gauss_filter_5tap_params or > vil_gauss_fiter_gen_ntap gives me better results. It does > not make much > difference for a single convolution, but when iterated many times (to > produce the effect of smoothing with a large sigma) the error becomes > more significant. Is there a reason why vnl_erf is used instead of > vcl_exp, and is there an error in the vnl_erf evaluation of > the gaussian > or is there some other reason why these results would be different? AFAIK The choice between using erf and exp(x*x) to calculate a Gaussian kernel for image convolution, mainly derives from whether you believe your image is sampled at points, or over an area. If you are trying to estimate the continuous Gaussian convolution of the underlying continuous image, and your pixels are really a set of point samples of the underlying image, then exp(x*x) is more correct. If your pixels are really a integral of the image function over the rectangular pixel, then the erf is more appropriate. Note that if your are really trying to do accurate smoothing, then I believe that sinc(x) is the ideal kernel. If you have found a bug in the implementation of vnl_erf, you should be able to detect that explicitly, and fix vnl_erf. If it is a problem with vil_gauss_fiter_gen_ntap, you'll need to define "better results" and "smaller error", in order to decide if there is a problem. Ian. 