-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Specify a tuple of padding styles #94
Comments
Are you still interested in doing this? I think it is quite a bit of effort. |
For separable kernels you'd just filter one dimension at a time. Do you have non-separable kernels where this is desired? |
The reason I ask for this is because currently imfilter! allocates an amount of memory equivalent to the filtered array for every call (related to #76) , so for example:
So this call allocated a lot, even when calling the in-place function with a preallocated buffer. If I call it once again using a different kernel for the other direction (with different padding option), It will do the allocation once more. When the array size increases to GiB, this calls become a huge bottleneck, altough I don't know if this because of the allocations exclusively, it is to be expected because of the nature of the operation, or it is an example of deficient usage of the functions. |
Small comment, your example doesn't run; I built Julia with JuliaLang/julia#31915 and ran the following:
Notice that the big allocations all come in integer multiples of ImageFiltering.jl/src/imfilter.jl Lines 830 to 844 in 0ae7df1
If you instead profile for performance, these do not show up as hotspots, and the amount of time in the gc is not a large fraction of the total time. So I don't think there's an actual performance problem here. |
Hi Tim: Thanks for the comment, cleaning to get a MWE sometimes goes wrong. For some reason I failt to get the performance of the code being used here before (it was a Matlab code). While all the other parts run faster, the filtering par overhead in my version is slower enough to make the overall program slower (this is the most expensive part). I was mistakenly thinking this was due to GC from this case. Thanks for the thorough explanation. |
Well, there may be other bottlenecks, I was just addressing your direct question. If you're only filtering along 2 dimensions, why not just have the kernel comprised of those two? kern = kernel4d(smooth_x)
imfilter!(buf,U,kern[1:2],"circular") because only the first two do anything. To make it faster:
|
Thanks a lot. Closing this and sorry for the noise. |
Hi:
It would be nice to have the possibility to specify a tuple of padding styles in the call to imfilter:
I am thinking, for example, where the array to be filtered has dimensions with different physical meanings.
The particular use case I have in mind is one where the first two dimensions are periodic boundaries, so "circular" works fine, but for the 3rd dimension (temporal) is more suited for "replicate", or another style.
I'm thinking something like:
This can be worked around by calling twice imfilter with different kernels, each with it's own border style, so it is by no means an urgent matter.
Additionally, with some orientation, I think I would be able to dig into this.
The text was updated successfully, but these errors were encountered: