Skip to content
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

Large shifts in windowed positions #45

Open
fred3m opened this issue Jun 20, 2016 · 4 comments
Open

Large shifts in windowed positions #45

fred3m opened this issue Jun 20, 2016 · 4 comments

Comments

@fred3m
Copy link

fred3m commented Jun 20, 2016

When using windowed positions, both SExtractor and SEP can cause a sources position to drift due to the presence of nearby neighbors. This behavior is demonstrated for SEP in this notebook and SExtractor in this notebook.

It might be best to document this effect but not fix it as this is likely to be strongly dependent on the detector and image.

@kbarbary
Copy link
Owner

Nice notebook Fred. Another workaround would be to mask the neighbor's pixels and pass the mask to sep.winpos. You'd have to use a different mask for every object though, so it would be a little tedious to code.

I added a short note to the docstring of sep.winpos. See http://sep.readthedocs.io/en/latest/api/sep.winpos.html. Suggestions for rewording welcome.

@fred3m
Copy link
Author

fred3m commented Aug 26, 2016

That's a good idea to use a mask, I hadn't thought of that. It might not be as tedious as you think. Theoretically a mask could be applied to all of the sources with good windowed positions, based on their aperture, and only the windowed positions of bad positions would need to be recalculated.

This will still fail for blended sources with overlapping apertures or non-detections of neighbors but it may improve things for a sizable number of sources with bad windowed positions.

@fred3m
Copy link
Author

fred3m commented Aug 26, 2016

Where is the documentation for SEP kept, I couldn't find it on gitub. I think your note is useful but I might expand it a bit. For example:

One should be cautious about using windowed positions in crowded fields or for sources with nearby neighbors, as the iterative algorithm can fail catastrophically. It can be useful to check the difference between extracted positions and windowed positions to verify that the algorithm is behaving as expected.

While this should be obvious to an astronomer, I could see a student just blindly using the code and obtaining unphysical results. You could also point them to my ipython notebook, or for consistency, a copy or some version of the notebook included with SEP if you like.

@kbarbary
Copy link
Owner

The reference docs are built from the function docstrings. Here's the source for the note I added:

sep/sep.pyx

Lines 1679 to 1681 in 8fb49ac

**Note:** One should be cautious about using windowed positions in
crowded fields or for sources with nearby neighbors, as the iterative
algorithm can fail catastrophically.

The other docs are in the docs directory. It would be great if you add to the section "Equivalent of XWIN_IMAGE, YWIN_IMAGE in Source Extractor" in docs/apertures.rst. Perhaps just a short demo of how to check the position differences.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants