-
-
Notifications
You must be signed in to change notification settings - Fork 35
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
WIP: Modify median filters to handle edges better #38
base: main
Are you sure you want to change the base?
Conversation
…in IRAF, extending the window using nearest edge pixel values, rather than just leaving them unfiltered (which led to CR residuals at edges compared with IRAF).
astroscrappy/utils/medutils.c
Outdated
else if (j+k >= ny) nxk = nx * (ny-j-1); | ||
else nxk = nx * k; | ||
for (l = -2; l < 3; l++) { | ||
ipl = i+l; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, EMACS put some tabs in. I'll get rid of them in the next version.
As a quick performance check, |
…ock, avoiding repeated setup.
…d median). This seems about 8% slower than the 5x5-specific version, probably because the compiler can't optimize the loops (as per the existing comment), but the more general NxN version may be useful anyway.
Here's a version that reimplements the 5x5 median filter using an NxN median filter. From a quick check, it seems to be about 8% slower, presumably because the compiler can't optimize the inner loops as per your comment in the existing code -- but maybe it's useful to have an NxN filter anyway and I'll push it so you can have a look. Would you rather keep the triplicated cut-and-paste versions for performance? It's probably going to be quite fiddly to abstract them without some run-time penalty (eg. using the pre-processor or generated code?). |
… file. Hmmm, all this Python & IRAF has made my C rather rusty...
…licate edge pixels instead of not filtering them.
…ke up the median window.
This last update made similar changes to Edge pixels are also being ignored in the Laplace and dilation/growth filtering, but those don't seem to make such a difference to the end result when changed. I think the current Laplace filter is arguably incorrect at the edges of the array, because the central value of 4 should be adjusted to 3 or 2 to account for the number of pixels being subtracted from it, otherwise the gradient measurement is dominated by superimposed signal in those rows/columns. As I say, however, it's the median filtering and cleaning that seem to make most of the difference to CR residuals at edges. |
As per #12, here's a version of
PyMedFilt5
that avoids edge residuals, behaving the same as IRAF'smedian
with its defaultboundary="nearest"
andndimage.median_filter
with the equivalent option.It would be far cleaner to factor this into its own function that each median filter can call, but I notice that you haven't done that elsewhere, presumably for optimization reasons? It would save quite a lot of repetition here though -- what do you think? Also, would you prefer the edge filtering to be optional, since you say you have encountered artifacts associated with filtering at the edges? I'd suggest giving this method a try first, since I don't see obvious problems with it (even if the theory is a bit questionable).
I should perhaps move all the for loops into a single block and avoid re-allocating
medarr
...