Vectorized version of nlfilter

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Vectorized version of nlfilter

Tony Richardson-4
I've been working on a vectorized version of nlfilter (which can be used for non-linear filtering of pixel neighborhoods).  My version is attached (along with a driver).  Depending on the type of processing I've found it to be 10 - 1000 times faster than nlfilter.  It gets the speed boost at the cost of using more memory.  It is not completely compatible with nlfilter.  The processing function is different.  For processing an image/matrix with P elements over an (m x n) neighborhood, the nlfilter function must accept an argument of size (m x n).  The function is called P times by nlfilter.  The processing function used by nlfilter2 must accept an argument with (m x n) rows and P columns.  It is only called once.  Each column is a neighborhood of a pixel in left-to-right, top-to-bottom order.

It is not as robust or general as nlfilter, but I expect it can be made so.  I have a different version of this function which allows you to perform neighborhood processing only over selected pixels (selected by a logical index matrix).  It also allows for other types of padding (both nlfilter and nlfilter2 only use zero-padding).  Let me know if you are interested.  It is currently even in rougher form than nlfilter2 though.

Anyway, I hope someone finds this useful.  I'd appreciate (constructive) feedback.

Tony



nlfilter2.m (4K) Download Attachment
nlf_test.m (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Vectorized version of nlfilter

Nicklas Karlsson
> I've been working on a vectorized version of nlfilter (which can be used
> for non-linear filtering of pixel neighborhoods).  My version is attached
> (along with a driver).  Depending on the type of processing I've found it
> to be 10 - 1000 times faster than nlfilter.  It gets the speed boost at the
> cost of using more memory.  It is not completely compatible with nlfilter.
> The processing function is different.  For processing an image/matrix with
> P elements over an (m x n) neighborhood, the nlfilter function must accept
> an argument of size (m x n).  The function is called P times by nlfilter.
> The processing function used by nlfilter2 must accept an argument with (m x
> n) rows and P columns.  It is only called once.  Each column is a
> neighborhood of a pixel in left-to-right, top-to-bottom order.

Faster algorithm must always be appreciated, we must be grateful for the work.

Guess it could be added to ordinary nlfilter(...) function, either as a special case which is used automatically then input allow or an extra option to chose algorithm. Or?

> It is not as robust or general as nlfilter, but I expect it can be made
> so.  I have a different version of this function which allows you to
> perform neighborhood processing only over selected pixels (selected by a
> logical index matrix).  It also allows for other types of padding (both
> nlfilter and nlfilter2 only use zero-padding).  Let me know if you are
> interested.  It is currently even in rougher form than nlfilter2 though.

I can't add files to the official repository.

> Anyway, I hope someone finds this useful.  I'd appreciate (constructive)
> feedback.
>
> Tony


Reply | Threaded
Open this post in threaded view
|

Re: Vectorized version of nlfilter

Tony Richardson-4
Well it looks as if my nlfilter2 is essentially the same as colfilt (and is not any faster).  I should have read the nlfilter documentation (which points the user to colfilt) more carefully.  

I haven't found an equivalent for my more general function that allows you to process only selected pixels and allows you to select neighbors by their row and column offsets (instead of  using a rectangular region).  I believe it is a generalization of colfilt.  I'll clean it up a bit and post it here in case anyone is interested.

Tony

Tony

On Sat, Jul 18, 2020 at 3:19 AM Nicklas SB Karlsson <[hidden email]> wrote:
> I've been working on a vectorized version of nlfilter (which can be used
> for non-linear filtering of pixel neighborhoods).  My version is attached
> (along with a driver).  Depending on the type of processing I've found it
> to be 10 - 1000 times faster than nlfilter.  It gets the speed boost at the
> cost of using more memory.  It is not completely compatible with nlfilter.
> The processing function is different.  For processing an image/matrix with
> P elements over an (m x n) neighborhood, the nlfilter function must accept
> an argument of size (m x n).  The function is called P times by nlfilter.
> The processing function used by nlfilter2 must accept an argument with (m x
> n) rows and P columns.  It is only called once.  Each column is a
> neighborhood of a pixel in left-to-right, top-to-bottom order.

Faster algorithm must always be appreciated, we must be grateful for the work.

Guess it could be added to ordinary nlfilter(...) function, either as a special case which is used automatically then input allow or an extra option to chose algorithm. Or?

> It is not as robust or general as nlfilter, but I expect it can be made
> so.  I have a different version of this function which allows you to
> perform neighborhood processing only over selected pixels (selected by a
> logical index matrix).  It also allows for other types of padding (both
> nlfilter and nlfilter2 only use zero-padding).  Let me know if you are
> interested.  It is currently even in rougher form than nlfilter2 though.

I can't add files to the official repository.

> Anyway, I hope someone finds this useful.  I'd appreciate (constructive)
> feedback.
>
> Tony


Reply | Threaded
Open this post in threaded view
|

Re: Vectorized version of nlfilter

Tony Richardson-4
OK.  I've cleaned up my alternate version of colfilt a bit.  It allows for neighborhood processing of only selected pixels instead of all pixels.  Neighbors can be specified by row and column offsets instead of using all neighbors in a rectangular region.  (This can result in less memory usage than colfilt if only a few neighbors of a percentage of the pixels in an image are to be processed.)  I would guess that it could be faster too (although probably not significantly so), but I haven't tried to measure that.

Tony

On Sat, Jul 18, 2020 at 12:01 PM Tony Richardson <[hidden email]> wrote:
Well it looks as if my nlfilter2 is essentially the same as colfilt (and is not any faster).  I should have read the nlfilter documentation (which points the user to colfilt) more carefully.  

I haven't found an equivalent for my more general function that allows you to process only selected pixels and allows you to select neighbors by their row and column offsets (instead of  using a rectangular region).  I believe it is a generalization of colfilt.  I'll clean it up a bit and post it here in case anyone is interested.

Tony

Tony

On Sat, Jul 18, 2020 at 3:19 AM Nicklas SB Karlsson <[hidden email]> wrote:
> I've been working on a vectorized version of nlfilter (which can be used
> for non-linear filtering of pixel neighborhoods).  My version is attached
> (along with a driver).  Depending on the type of processing I've found it
> to be 10 - 1000 times faster than nlfilter.  It gets the speed boost at the
> cost of using more memory.  It is not completely compatible with nlfilter.
> The processing function is different.  For processing an image/matrix with
> P elements over an (m x n) neighborhood, the nlfilter function must accept
> an argument of size (m x n).  The function is called P times by nlfilter.
> The processing function used by nlfilter2 must accept an argument with (m x
> n) rows and P columns.  It is only called once.  Each column is a
> neighborhood of a pixel in left-to-right, top-to-bottom order.

Faster algorithm must always be appreciated, we must be grateful for the work.

Guess it could be added to ordinary nlfilter(...) function, either as a special case which is used automatically then input allow or an extra option to chose algorithm. Or?

> It is not as robust or general as nlfilter, but I expect it can be made
> so.  I have a different version of this function which allows you to
> perform neighborhood processing only over selected pixels (selected by a
> logical index matrix).  It also allows for other types of padding (both
> nlfilter and nlfilter2 only use zero-padding).  Let me know if you are
> interested.  It is currently even in rougher form than nlfilter2 though.

I can't add files to the official repository.

> Anyway, I hope someone finds this useful.  I'd appreciate (constructive)
> feedback.
>
> Tony



col2_test.m (1K) Download Attachment
colfilt2.m (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Vectorized version of nlfilter

siko1056
On 7/19/20 3:31 AM, Tony Richardson wrote:

> OK.  I've cleaned up my alternate version of colfilt a bit.  It allows
> for neighborhood processing of only selected pixels instead of all
> pixels.  Neighbors can be specified by row and column offsets instead of
> using all neighbors in a rectangular region.  (This can result in less
> memory usage than colfilt if only a few neighbors of a percentage of the
> pixels in an image are to be processed.)  I would guess that it could be
> faster too (although probably not significantly so), but I haven't tried
> to measure that.
>
> Tony

Thank you Tony, for your image package [1] contribution.  This
mailing-list is intended for users of Octave to get help.  Code
contributions are better suited for the patch tracker [2] and are easily
forgotten on the mailing list.  Was it possible to upload your file there?

Kai

[1] https://octave.sourceforge.io/list_functions.php?q=nlfilter&sort=package
[2] https://savannah.gnu.org/patch/?func=additem&group=octave


Reply | Threaded
Open this post in threaded view
|

Re: Vectorized version of nlfilter

Tony Richardson-4


On Sat, Jul 18, 2020, 10:57 PM Kai Torben Ohlhus <[hidden email]> wrote:
On 7/19/20 3:31 AM, Tony Richardson wrote:
> OK.  I've cleaned up my alternate version of colfilt a bit.  It allows
> for neighborhood processing of only selected pixels instead of all
> pixels.  Neighbors can be specified by row and column offsets instead of
> using all neighbors in a rectangular region.  (This can result in less
> memory usage than colfilt if only a few neighbors of a percentage of the
> pixels in an image are to be processed.)  I would guess that it could be
> faster too (although probably not significantly so), but I haven't tried
> to measure that.
>
> Tony

Thank you Tony, for your image package [1] contribution.  This
mailing-list is intended for users of Octave to get help.  Code
contributions are better suited for the patch tracker [2] and are easily
forgotten on the mailing list.  Was it possible to upload your file there?

Kai

[1] https://octave.sourceforge.io/list_functions.php?q=nlfilter&sort=package
[2] https://savannah.gnu.org/patch/?func=additem&group=octave

Yes, I'll do that.
Tony