juliaastro/photometry.jl

Utilities for characterizing sources in astronomical images.

photometry.jl's Issues

Redundant calling of bbox for circular aperture

Photometry.jl/src/Aperture/circular.jl

Line 44 in 46d4a6c

box = bbox(c)

Line number 43: creating bounds by calling edges, and edges call bbox internally.
Line number 44: creating a bounding box by calling bbox
Line number 45: getting size, size calls bbox internally
Line number 46: calling circular_overlap but there is no use of the variable created in line 44, because it is not being passed as an argument.

Similarly at

Photometry.jl/src/Aperture/circular.jl

Line 90 in 46d4a6c

box = bbox(c)

Register v0.2

@JuliaRegistrator register

IDW Interpolator

It would be nice to have an implementation of the Shepard inverse distance weighting interpolation scheme. Astropy has a version here and there's a wikipedia entry, too.

Sigma clipping

This involves implementing some basic statistical functions using standard sigma-clipping

sigma_clip(data, sigma_low, sigma_high; center=median, std=std)
sigma_clip(data, sigma; kwargs...) = sigma_clip(data, sigma, sigma; kwargs...)

data is the input data
sigma is the number of sigma to clip with
sigma_low,sigma_high allow asymmetric clipping
center is a function for computing the central value (usually mean or median)
std is a function for computing the spread (usually std)

The function will return the original data with the clipped values imputed with the appropriate max (ie if the original is greater than sigma_high * std + mean then it is replaced with sigma_high * std + mean)

Switch to a geometry backend

After spending many hours trying to patch together some code for doing exact overlaps of rectangular apertures, I've decided there has to be a better way. I think there is.

I think there is a way to substantially cut down on the code required for calculating overlaps for aperture photometry by leveraging the code from some JuliaGeometry packages.

The general problems

• Area of overlap of an arbitrary ellipse (position, semi-major axis, semi-minor axis, position angle) with an axis-aligned rectangle
  This includes the special case of a circle

• Area of overlap of an arbitrary polygon (points) with an axis-aligned rectangle
  This includes the special case of an arbitrary rectangle (position, width, height, position angle)

Current Implementation

Currently, we only support circular and elliptical overlap, but I'd like to support rectangles and polygons, too. The method for circular and elliptical is some modified version of the Sutherland-Hodgman algorithm. For the circular version, its simple enough to find intersections with the circle and compose the area using triangles and chords.

For the elliptical, we use the transform for the ellipse into the unit circle and apply that to the rectangle's points. This creates a parallelogram (not axis-aligned) which we break into two triangles. These triangles are then fed through a modified Sutherland-Hodgman for their overlap with the unit circle.

Call for help

Performance is important, but I'm more considered about usability and coverage of different geometric types. This is why I think this can be made better using another package, but I don't really know how to use them for this purpose. The point between where we do calculations and transforming our data into geometry types for outsourcing the calculations is also not clear to me (e.g. is it better/faster to calculate area overlap of two triangles and unit-circle or a polygon and unit-circle?)

If there is anyone who can help me find a way to achieve this, I would greatly appreciate it.

Register

@JuliaRegistrator register

TagBot trigger issue

This issue is used to trigger TagBot; feel free to unsubscribe.

If you haven't already, you should update your TagBot.yml to include issue comment triggers.
Please see this post on Discourse for instructions and more details.

Simple Stats Background Estimation

Following #11 I'd like to get all of the simple statistics background estimation methods implemented and push v0.3.0.

Methods

• Mean
• Median (#15)
• Mode - (#16) https://photutils.readthedocs.io/en/stable/api/photutils.background.ModeEstimatorBackground.html#photutils.background.ModeEstimatorBackground
• MMM (#18) - https://photutils.readthedocs.io/en/stable/api/photutils.background.MMMBackground.html#photutils.background.MMMBackground
• SourceExtractor (#19) - https://photutils.readthedocs.io/en/stable/api/photutils.background.SExtractorBackground.html#photutils.background.SExtractorBackground
• Biweight (#23) - https://photutils.readthedocs.io/en/stable/api/photutils.background.BiweightLocationBackground.html#photutils.background.BiweightLocationBackground

Note:
You will see that SourceExtractor is commonly abbreviated to SExtractor. Part of the astronomy community, including myself, finds this name inappropriate for various reasons and I would like to always refer to it as SourceExtractor.

RectangularAperture of size 1 gives weights of 0

Hello,

I was trying to use Photometry.jl to generate an aperture around a single pixel, so that it would just extract the value from that one pixel. (I know this is redundant since I could just index that one pixel, but for the sake of consistency I wanted to be able to do this as well). However, it seems like there is a bug in Photometry.jl where trying to generate a rectangular aperture with a width/height of exactly 1 causes all of the weights to be 0:

julia> using Photometry

julia> ap = RectangularAperture(10,10,1.,1.,0.)
2×2 RectangularAperture{Float64} with indices 9:10×9:10:
 0.0  0.0
 0.0  0.0

I would expect it to just give an aperture with indices of 10:10x10:10 with a weight of 1.0. And if I change the width/height to a value slightly above 1, it seems to work as expected:

julia> ap = RectangularAperture(10,10,1+eps(),1+eps(),0.)
2×2 RectangularAperture{Float64} with indices 9:10×9:10:
 0.0  0.0
 0.0  1.0

possible test failure in upcoming Julia version 1.5

A PkgEval run for a PR which changes the generated numbers for randn! indicates that the tests of this package might fail in Julia 1.5 (and on Julia current master). Apologies if this is a false positive.
cf. https://github.com/JuliaCI/NanosoldierReports/blob/7de24e455342298cbef56826b5827f0d7640d2c1/pkgeval/by_hash/b89e35c_vs_098ef24/logs/Photometry/1.5.0-DEV-71a4a114c2.log