polyphot aperture area calculation wrong?
mboquien wrote on Mar 06, 2010
Hello,
I have noticed that the area calculated by the polyphot task gives a result which is different than what is computed manually. For instance for this polygon IRAF gives 125.4778 and computing manually i get 123.969.
741.34 747.41
748.38 748.87
753.12 745.62
754.12 740.12
750.83 738.05
749.82 737.76
748.00 736.95
747.92 735.26
748.12 733.62
742.38 734.88
740.37 741.62
745.84 742.30
746.30 744.08
741.34 747.41
It worries me as i use world coordinates to calculate the flux in different images and the area for the same aperture can vary up to ~25% (once converted to arcsec²) between an image with ~0.3 arcsec pixels and one with ~6 arcsec pixels. Needless to precise that it affects the science as it affects the total background flux and any calculation of surface brightness. Please tell me i am just getting something wrong, i would hate that it is a real bug. :(
Thanks a lot!
I have noticed that the area calculated by the polyphot task gives a result which is different than what is computed manually. For instance for this polygon IRAF gives 125.4778 and computing manually i get 123.969.
741.34 747.41
748.38 748.87
753.12 745.62
754.12 740.12
750.83 738.05
749.82 737.76
748.00 736.95
747.92 735.26
748.12 733.62
742.38 734.88
740.37 741.62
745.84 742.30
746.30 744.08
741.34 747.41
It worries me as i use world coordinates to calculate the flux in different images and the area for the same aperture can vary up to ~25% (once converted to arcsec²) between an image with ~0.3 arcsec pixels and one with ~6 arcsec pixels. Needless to precise that it affects the science as it affects the total background flux and any calculation of surface brightness. Please tell me i am just getting something wrong, i would hate that it is a real bug. :(
Thanks a lot!
Mike Fitzpatrick wrote on Mar 06, 2010
Below is a script you can use to calculate the exact area of a polygon, for the vertices you list I get a different number still, 123.8726.
The thing to remember is that the area used by POLYPHOT is just an approximation based on some estimate of the overlap of the polygon with a particular pixel (which is used to compute the fraction of flux contributed by that pixel). I believe (but haven't verified) that this is done in pixel space so the fraction computed will be the same regardless of the plate scale. Although the POLYPHOT value is higher, I'm not sure this approximation is what could be called a bug. Unfortunately the programmer who wrote the task is no longer with us so it will take some digging to get into the algorithm to understand if it really is a problem, or what might be done to improve the value.
Cheers,
-Mike
The thing to remember is that the area used by POLYPHOT is just an approximation based on some estimate of the overlap of the polygon with a particular pixel (which is used to compute the fraction of flux contributed by that pixel). I believe (but haven't verified) that this is done in pixel space so the fraction computed will be the same regardless of the plate scale. Although the POLYPHOT value is higher, I'm not sure this approximation is what could be called a bug. Unfortunately the programmer who wrote the task is no longer with us so it will take some digging to get into the algorithm to understand if it really is a problem, or what might be done to improve the value.
Cheers,
-Mike
#{ POLYAREA -- Compute the area of a polygon given an input list of
# vertex points.
#
# Usage: cl> task $polyarea = /path/polyarea.cl
# cl> polyarea < vertex.txt
#
# Where 'vertext.txt' is a text file containing one (x,y) vertext point
# per line.
procedure polyarea ()
begin
real a, b, c, d, sum
sum = 0.0
j = scan (a, b)
i = 1
while (scan (c, d) != EOF) {
sum = sum + (a * d - c * b)
a = c
b = d
i = i + 1
}
printf ("Area = %.5f Nvertices = %d\n", abs(sum / 2.0), i)
end
Last post on Mar 06, 2010