Edge treatment for GaussSmooth2D

[MatthewWhiting]

I want to add a better handling of the edges of the array when smoothing with the 2D Gaussian. Currently, the convolution goes right to the edge of the image, and either treats all pixels equally or scales them down by the coverage.

An alternative would be to simply truncate the convolution around the edge where the kernel does not fit. So, say the half-width of the convolution kernel was 10, the 10 pixels around the edge of the image should be set to BLANK.

This could be done by replacing the bool scaleByCoverage parameter with an ENUM with a range of possible alternatives.

It may also be worthwhile allowing the specification of the half-width in the define statement (or via a separate class function). It could give a warning if the requested width is less than the width we currently calculate, but that would allow us to do the overlaps etc in the ASKAPsoft functions without needing to know what the width will be a priori (as it depends on MAXFLOAT, which presumably can vary from system to system).

[MatthewWhiting]

Done in [682] and [683] - pretty much as specified in the above description.

Want to improve the templatedness - use .tcc files instead to make the code a bit cleaner?

[MatthewWhiting]

Moved GaussSmooth2D.cc to a .tcc file, which is included by the .hh file. [684]

Also had to remove the .o file from the Makefile [685]

[MatthewWhiting]

May want to add possiblity of selecting different edge modes in the input parameters? Defer this to next release though.

[MatthewWhiting]

Add this to the 1.3.1 release, for consideration alongside #186.

[MatthewWhiting]

Didn't mean to close that...

[MatthewWhiting]

Actually, leave 1.3.1 as just a bug-fix release - move back to 2.0 but can reassign to a (as-yet undefined) earlier release.

[MatthewWhiting]

Yes, will implement this in 1.5. Couple of things here:

1. Parameter to choose the edge method - allow 'equal' (default), 'truncate' or 'scale'
2. Allow the specification of the cutoff value in calculating the kernel size. Currently we use 1./MAXVAL (about 1./3e38 on the mac), but for a 5pix FWHM this leads to a kernel 59pix across. If we make it, say, 1.e-10, then the kernel shrinks to 31pix across - 1/4 the size.

[MatthewWhiting]

Done and done. And even documented.

Closing ticket.