octave-patch-tracker
[Top][All Lists]
Advanced

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

[Octave-patch-tracker] [patch #9354] image package: new function wiener2


From: Carnë Draug
Subject: [Octave-patch-tracker] [patch #9354] image package: new function wiener2.m
Date: Tue, 30 May 2017 20:21:51 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0

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

I pushed this http://hg.code.sf.net/p/octave/image/rev/7e54312e1df2 which adds
your wiener2 function to the image package.

I expanded it to work for n dimensions with this
https://bitbucket.org/carandraug/octave-image/commits/ac1f6b2e230e0f5f860d7c8a9ee2435497b124ed
 could you take a look? Even without the reason to support nd images, this
uses convn directly which will be faster.  And turns out there's no need to
use padarray because convn already does the padding with zeros.

I don't think we need to check for ndims(image)==numel(neighborhood) or to
postpad nhood, since convn can handle mixed number of dimensions on both
arrays.  I was unsure about how to handle singleton dimensions and its effect
on the default nhood.  Should a [10 10 1 4] array default to a [3 3 3 3] or a
[3 3 1 3] nhood?  I went with [3 3 3 3] because that's consistent with what
happens at the moment for 1d arrays, i.e., an image of size [10 1] still uses
a [3 3] nhood.  Or is this wrong?  Similarly, if a user specifies a nhood with
more dimensions than the image, it's their business, we shouldn't give an
error.

Also, can you confirm on recent Matlab that IM indeed cannot be logical or
empty for wiener2 (similar to the issue on mean2?)

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?9354>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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