You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As of right now, the only two options for photometric extraction are what I will call "hard" circular apertures (where a pixel is either in or out of an aperture based on the location of its center) or "subsampled" circular apertures (where a pixel is bilinearly interpolated and then a "hard" aperture is used on those sub-pixels). A potentially faster option to "subsampled" apertures is to use what I call "soft" apertures where a portion of a pixel's flux is included in the sum based on the fractional area of the pixel that lies within the aperture. Another option is non-circular apertures (e.g. box or elliptical). There is also the question of whether the aperture should move with the fitted centroid or stay stationary based on the mean centroid location. And then there is the possiblity of different background subtraction techniques - e.g. use the same 1/f subtraction method used on NIRCam photometry for MIRI photometry. Finally, there's also the possibility to use optimal photometric extraction. In summary, the things I think worth including (or at least investigating) are:
In my experience, the CircularAperture, EllipticalAperture, RectangularAperture, and CircularAnnulus functions from photutils.aperture work well, aperture_photometry from photutils offers the same "hard" aperture we currently use (called "center") as well as a "soft" aperture (called "exact"). It is also easy to implement "subsampled" apertures and moving apertures with this package. Using this external package would also significantly reduce the amount of code we need to maintain. I suggest we use these packages instead and remove the old code.
I have tried optimal extraction using flux or error weighting in a jupyter notebook and found error weighting to be the better of the two methods for MIRI photometry, but aperture photometry tends to work a tiny bit better (likely depends on the particular observation). I've yet to try the 1/f subtraction method for the MIRI photometry as it'll take some significant tweaking.
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
Instrument
NIRCam (Stages 1-3), MIRI (Stages 1-3)
What is your suggestion?
As of right now, the only two options for photometric extraction are what I will call "hard" circular apertures (where a pixel is either in or out of an aperture based on the location of its center) or "subsampled" circular apertures (where a pixel is bilinearly interpolated and then a "hard" aperture is used on those sub-pixels). A potentially faster option to "subsampled" apertures is to use what I call "soft" apertures where a portion of a pixel's flux is included in the sum based on the fractional area of the pixel that lies within the aperture. Another option is non-circular apertures (e.g. box or elliptical). There is also the question of whether the aperture should move with the fitted centroid or stay stationary based on the mean centroid location. And then there is the possiblity of different background subtraction techniques - e.g. use the same 1/f subtraction method used on NIRCam photometry for MIRI photometry. Finally, there's also the possibility to use optimal photometric extraction. In summary, the things I think worth including (or at least investigating) are:
In my experience, the
CircularAperture
,EllipticalAperture
,RectangularAperture
, andCircularAnnulus
functions fromphotutils.aperture
work well,aperture_photometry
fromphotutils
offers the same "hard" aperture we currently use (called "center") as well as a "soft" aperture (called "exact"). It is also easy to implement "subsampled" apertures and moving apertures with this package. Using this external package would also significantly reduce the amount of code we need to maintain. I suggest we use these packages instead and remove the old code.I have tried optimal extraction using flux or error weighting in a jupyter notebook and found error weighting to be the better of the two methods for MIRI photometry, but aperture photometry tends to work a tiny bit better (likely depends on the particular observation). I've yet to try the 1/f subtraction method for the MIRI photometry as it'll take some significant tweaking.
Code of Conduct
The text was updated successfully, but these errors were encountered: