mapwindow functionality

[mkborregaard]

The mapwindow functionality (which overlaps with RollingFunctions for the 1-D case) is a general and common Array operation outside the context of ImageFiltering. I wonder why it lives here? Might it be more accessible for general users in a package like RollingFunctions and then imported and extended here?

[timholy]

I could rename this package "Stencils.jl"?

(The point being that almost everything in this package is of general interest.)

[mkborregaard]

OK :-)

[timholy]

Well, this is not the first time this has come up. Is it really just the name that gets in the way, or something else? EDIT: meaning, does "image processing" somehow convey some very arcane art that only a few people would be interested in, rather than "people who do stuff with arrays"?

[timholy]

Or to ask another way: is RollingFunctions somehow more discoverable? This package predated RollingFunctions and is (as you noted) more general. I wonder if it's just a "search key" problem?

[mkborregaard]

Yes I think it is mainly that - I thought of this as a specialized package for image analysis. Then I opened the docs and saw an operation on the Mandril image, looked at the fairly big REQUIRE file and thought "this is overkill for the simple moving average I want in my code". I think the existence of RollingFunctions also testifies to that, and I noticed that eg. GLVisualize and TimeSeries have also rolled their own moving_average/moving functions, so I thought that maybe having a shared common dependency for things like that would be better.

[kmsquire]

I do like the name Stensils.jl, although I'm wondering if that suggests excludes any functionality implied here...

[timholy]

See also https://github.com/emmt/LocalFilters.jl, which just got submitted for registration. It seems the name "Images" really does scare people away?

[timholy]

I guess the best option is to split out "ArrayFilters" and leave any color-specific stuff here?

[mkborregaard]

I think the name "images" may scare people away. I for one get a little cautious because ImageMagick broke Homebrew broke Pkg.update for me for a year until we finally stopped relying on it in Plots (and the Images stack broke my Pkg completely once) – this is of course grossly unfair as today the Image packages don't use ImageMagick at all.

Anyway, I think that's a nice idea!

[Keno]

Bump on this. I didn't think to look here for generic stencil array operations because of the image name.

[mkborregaard]

Bump in 2021 :-)

[rafaqz]

Adding to this, DynamicGrids.jl has a very fast mapwindow using generated functions and sliding SArray windows, so it loads data from only a single column of the parent array for each window. Often 1 cache line. It's faster for small kernel convolutions than DSP.jl - and I imagine much faster than mapwindow which if I recall uses a view into the parent array.

Currently it's written pretty specifically for our needs in DynamicGrids.jl, but moving these implementations to a shared base package would make sense.

[rafaqz]

In reply to some of the earlier discussion - it is both the name ImageFiltering and the many image specific dependencies that scare people away. I've rewritten a lot of this code in DynamicGrids.jl - partly because using stencils multiple times in a simulation allows different optimisations, but also because of the dependencies and the name. I had already written half of it before I realized how much crossover there was - knowing very little about image processing.

Changing the name to Stencils.jl or ArrayFiltering.jl would hopefully also include reassement of the dependencies - ImageFiltering.jl could remain to keep any image-specific code, and Stencils.jl could have all the general methods.