[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-patch-tracker] [patch #9365] image package: new function deconvw

From: Hartmut
Subject: [Octave-patch-tracker] [patch #9365] image package: new function deconvwnr.m
Date: Wed, 19 Dec 2018 15:07:24 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0

Follow-up Comment #10, patch #9365 (project octave):

* The original reason to insist on class double for psf and k was that Matlab
says on their help page, that they insist. But since both parameters normally
have very few entries (k is scalar, and psf is a filtering matrix), there is
also not very much memory to save in those two parameters, anyways.
** (A) At first I thouhgt I would be fine with accepting class SINGLE for the
psf and k parameter. But it wouldn't really help anyone. But lateron I
realised that in Octave the multiplication of a single with a double values
gives me a single result. And since psf is multiplied (or divided) with the
input image, I think I really want psf to be of class double (not single) for
better results. (see point D)
* About the idea of casting INTEGER values of psf and k to class double: At
first this sounded more user friendly to than what Matlab does (error out, at
least according to their help page). But then I wasn't sure, because normally
float images have values between 0 and 1. And for either psf nor k it would
make any sense to have any value bigger than 1 if the image is float. So it is
probably a real user error when he supplies integer values of psf or k and at
the same time a float image, and we should error out in this case.
** (B) So if we do some silent casting of integer psf to class double, we
should only do this for integer images (and not for float images). This would
be more user friendly, but more difficult to explain what we do here.
** (C) The values of k should really always be float. 
* (D) Thinking about memory savings: The biggest chunk of memory is probably
used by the image im itself. This is currently also cast to class double for
class single input images. Strictly speaking this is not necessary in order to
get a result. But (because of the massive calculations, involving two ffts)
the results will probably be much more accurate when doing the internal
calculations always in class double. Sticking to class single for single input
images seems to respect the users choice (to save memory), but I fear that it
defeats the whole purpose of this function (to remove image blur on noisy
images as good as possible, using massive calculations). So finally I tend to
stick to the current behavior, i.e. always convert to class double for the
internal calculations. (Additionally: We currently get Matlab compatible
results of the test cases of class single, this would probably regress if we
change our calculation strategy, here.)

In short, my opinion would be
* (A: allow class single for psf or k) = better NO, also not vey helpful
* (B: cast integer psf to float) = only OK for integer images, sometimes more
use friendly, but more complex to explain
* (C: accept integer k) = NO
* (D: do internal calculations in class single for single input images) =
better NO

What do you think? Which of the above would you like to see in a new version
of this function file? I would be fine with a change in point (B), but
slightly tend to just not change anything at all.


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]