Re: Photometry with AIP4win Dear Dr. Berry, > We would be happy to examine the data set that is > giving you problems. You could copy the raw dataset > to a CDROM (I assume it is ~100MB or so of data) > we would examine it to determine why you report > seeing unexpectedly large errors. Please include > a description of the AIP tool and the settings you are > using with it. Since I don't personally have AIP4Win, the reported findings were primarily based on observer's own analysis. So, those who have contributed to actual testing, please send the data to Dr. Berry for confirmation. [The data are (often unpublished) scientific data, so please don't use them other than in testing the program]. > However, several important conditions must be met to produce good > aperture photometry. Many of these conditions are not absolutely necessary for professional photometry packages. So, these points would be avoided in future version of AIP4Win, unless the software intends to be a "degraded version" of a professional tool (I don't think so). > 1.) Star images must be properly sampled. We have > found that undersampled star images give poor > results with front-side illuminated CCDs because > the starlight must pass through the gate structures > on the chip, and these acts as a geometrically > variable filter. This effect is clearly visible when the stellar FWHM is close to the pixel size (or smaller). However, most of amateur instruments usually give larger FWHMs. I haven't particularly seen this effect other than wide-field telephoto imaging with a CCD having large intrapixel variation of the sensitivity. I don't think this is the main reason of the reported errors with our "faint object" photometry. > 2.) Presence of a faint companion star between the > diaphragm and sky annulus. If the star moves in and > out of the diaphragm and annulus during a sequence, > the signal will be less good and constant than would > be desireable. While AIP normally deals well with > background stars, in certain locations they can be > troublesome. This is known sometimes occur. However, it is less likely to occur if constant V-C offset option is employed. And the existence of such troublesome companions is not very frequent. Trouble seem to have occurred in much solitary objects. > 3.) Poor seeing coupled with a small star diaphragm. > This results in varying amounts of starlight falling inside > the aperture, resulting in larger than desirable scatter > in the photometry. Yes, this needs to be properly adjusted by the observer. This effect is most prominently seen in random errors, but is usually less prominent in systematic errors. The existence of observations with a low scatter and a large systematic error probably can not be explained by this effect. > 4.) Small star images having low amplitude. AIP's > centroid algorithm requires at least three pixels to > be above a threshold that is ~2 sigma above the > sky noise. If there are fewer than three illuminated > pixels, the star images are considered undersampled > and will not give good results in any case. This description seems to suggest the star extraction algorithm of AIP4Win. From this description, it reminds me of Sextractor -- the algorithm is the most freqeuntly the first step implementation by a non-photometrist (since this algorithm is very well known in computer engineering). This algorithm is known to produce less consistent photometric results than in convolution method (as in daofind). Sextractor is indeed used by professional astronomers, but most of this application is not precise photometry but automatic detection of randomly shaped objects. Users of Sextractor often need to correct the systematic problems by applying to simulated images or by treating the data with statistical analysis. I presume that the problem PIXY (only in former versions?) suffers has the similar origin (the PIXY source code is publicly available, and one can easily confirm how it extracts objects). If this is the case for AIP4Win, this is clearly the first point to improve to produce more reliable photometry. > 5.) Incorrect dark-frame subtraction and flat-fielding > can also create unexpected error amplitudes. All comparisons were done with the same dark-fram subtraction and flat-fielding processes, and this should appear common to the software packages compared. Regards, Taichi Kato
Return to the Powerful Daisaku Nogami
vsnet-adm@kusastro.kyoto-u.ac.jp