ImageFiltering.jl
ImageFiltering.jl copied to clipboard
JuliaImages
mapwindow functionality
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?
I could rename this package "Stencils.jl"?
(The point being that almost everything in this package is of general interest.)
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"?
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?
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.
I do like the name Stensils.jl, although I'm wondering if that suggests excludes any functionality implied here...
See also https://github.com/emmt/LocalFilters.jl, which just got submitted for registration. It seems the name "Images" really does scare people away?
I guess the best option is to split out "ArrayFilters" and leave any color-specific stuff here?
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!
Bump on this. I didn't think to look here for generic stencil array operations because of the image name.
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.
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.