Open JeffFessler opened 3 years ago
but I've been hunting and cannot find that decision point in the code. Any hints?
Looks like you can try this API:
Thanks! I was looking for size
and couldn't find anything relevant...
So the docstring is not quite accurate then: https://github.com/JuliaImages/ImageFiltering.jl/blob/6f0dbc40637a763d6deff071056c8998bdb7a8b5/src/imfilter.jl#L508 because the choice is based solely on the kernel size, not on the image size. I might submit a PR to tweak the docstring.
@johnnychen94 it's not quite clear to me how to reuse an fft plan (the 2nd part of the OP).
Basically, I have a bunch of same size images I want to filter with the same kernel, and I want to avoid each imfilter!
calling FFTW.plan_rfft
because it has a lock because FFTW planning isn't threadsafe. That way we can multithread via julia.
cc. @octogonapus
https://github.com/HolyLab/RegisterMismatch.jl/blob/8bf6c7f597802fbac8b5de4dfcfe1f8bcfbb218b/src/RegisterMismatch.jl#L75-L95 might serve as an example? I haven't tested it recently though.
Thanks. Though I'm looking for a way to do so through imfilter!
If it's not currently possible we can try to look into adding that option, but I wanted to check first.
The
imfilter
docstring implies that the choice of FFT or FIR algorithm "will be chosen based on the size of the image and kernel" https://github.com/JuliaImages/ImageFiltering.jl/blob/6f0dbc40637a763d6deff071056c8998bdb7a8b5/src/imfilter.jl#L507 but I've been hunting and cannot find that decision point in the code. Any hints?Now on to the "plan" question. I need to apply filters of the same size to many images and my filter is big enough (e.g., 27 by 27) that I suspect that it will end up using the FFT algorithm. FFTW supports use of a plan to optimize performance: https://juliamath.github.io/AbstractFFTs.jl/stable/api/#AbstractFFTs.plan_fft It might be natural then for
imfilter
to have something akin to a "plan" mode where one initially provides the image size and filter size and the decisions about FFT and FIR are made in advance, along with the FFT plan if relevant and desired. Then subsequentimfilter!
calls with that plan are as efficient as possible.Any thoughts about this? I might be willing to try it if it sounds useful, but first I need to a pointer to the code that decides FFT vs FIR...