Wed 18 Feb 2015 08:35:57 GMT, comment #3:

>> I don't want to end up with 6 deconvolution functions
>> that are very similar but not quite.
>>
>
> I had thought that the problem currently is not that there are too many deconvolution function in Octave, but that there is none at all.

Yes, that is true now. But adding then now to have them removed one day when we get a Matlab compatible version, that will create problems.

> If you have a matlab compatible deconvolution implementation however, I agree that this should be included instead, even though it does not support regularization for Richardson-Lucy deconvolution, AFAIK.
>
> It might be best to provide our deconvolution routines not as part of the image package, but as a separate optional addon, because they are complementary to what matlab has built in, and are thus also useful for matlab users. Is there any other repository for octave contributions?

If there are something these implementations can do, I will try to merge them into Matlab compatible versions. Kinda like graythresh has an extra option to select different algorithms.

> Concerning the dimension, I wonder whether there is a way to avoid the discrimination of two cases, because Octave has different convolution functions for one and two dimensionc ([fft]conv versus [fft]conv2).

It also has convn which you can use when you want to support N dimensions. The image package also now has a corresponding fftconvn.

I am unsure of accepting this patch since Matlab has equivalent functions and you are already telling us that your functions behave different. I don't want to end up with 6 deconvolution functions that are very similar but not quite.  Even if you are not able to implement all the options, can you at least make it Matlab compatible?

Also, a few comments about the coding before being accepted:

1. when checking input, do not simply disp a message and then return, use error(). If there is an error, we want an error to be throw. Simply calling return will allow the computation to continue (and then misteriously fail later)

2. use the postpad, prepad, or padarray functions (you probably want the padarray function). Do not do these things yourself since they are a pain to read and therefore maintain:

  padimage = zeros (max_size);
  padpsf = zeros (max_size);
  ## ...
  padimage((1+d(1)):(max_size(1)-d(1)), (1+d(2)):(max_size(2)-d(2))) = image;
  padpsf((1+dp(1)):(max_size(1)-dp(1)), (1+dp(2)):(max_size(2)-dp(2))) = psf;

3. do not have separate code for 1 and 2 dimensions, we want to support an arbitrary number of dimensions. This is the same operation, it does not matter the number of dimensions.

4. do not compute the otf yourself from the psf. The functions psf2otf and otf2psf are now part of the image package (development version).

5. I will need an email address for both Fabian Schmitt as well since he's also claiming copyright ownership of the deconvWiener and deconvRL functions