Tweaking performance can be very difficult and there's no plan to investigate this issue. Running profiler gives me two suspicious performance hotspot

1. ImageFiltering.freqkernel: https://github.com/johnnychen94/ImageSmooth.jl/blob/1cb03e8949585e3431095e5869e706175df8e103/src/algorithms/l0_smooth.jl#L117-L118
2. fft! on complex number: https://github.com/johnnychen94/ImageSmooth.jl/blob/1cb03e8949585e3431095e5869e706175df8e103/src/algorithms/l0_smooth.jl#L159-L163

We haven't make sure it passes the OffsetArray test in #1

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

If you'd like for me to do this for you, comment TagBot fix on this issue.
I'll open a PR within a few hours, please be patient!

This algorithm can be expected to run 10x-100x faster if implemented in GPU.

I'm quite excited to see this package, nice work @JKay0327 and @johnnychen94.

I'm curious about the right way to handle the comparison to smoothing operations like Gaussian blur. There seem to be at least two options:

• add a LinearBlur(σ...) algorithm here that is just a convenience method to imfilter with a KernelFactors.gaussian kernel
• declare that this package focuses on nonlinear methods, and link to ImageFilter for linear methods

I'd be happy to make a PR at some point, but I thought it would be best to hear which of these you think makes more sense. I'd be happy with either outcome.

JuliaImages/ImageBase.jl#11

#1 (comment)

There exists a series of nice work on smoothing filters that I think we can easily bring to Julia:

• https://github.com/wliusjtu/Generalized-Smoothing-Framework
• https://github.com/wliusjtu/Real-time-Image-Smoothing-via-Iterative-Least-Squares
• https://github.com/wliusjtu/Embedding-Bilateral-Filter-in-Least-Squares-for-Efficient-Edge-preserving-Image-Smoothing

cc: @wliusjtu