Return to Home Page
Re: problems with AIP4win This is my follow-up comment to Bos' analysis. === > Part of the > problem could be that AIW4Win dose not allow one to set a value for the > inner sky annulus, so effectively you could be including some of the > stars light in the sky back ground subtraction. Also, how dose the > software deal with fractions of pixels, hot pixels and stars in the sky > annulus. Although I am not an actual user of AIP4WIN, your analysis seems reasonable, but the "queer" behavior of the data doesn't seem to be explained by contamination of other star light or hot pixels. In any case, the correct determination of the sky level is a key to the accuracy of photometry software, and you must have guessed one of the right points. May I forward your analysis to the lists so that AIP4WIN users and developpers can check this effect? From my experience with handling the data, Munipack 2 seems to have a subtle problem (possibly related to the AIP4WIN ones, but user's parameter choice may be responsible -- I know how complex DAOPHOT is, and I even read the "extremely complex" source code of DAOPHOT -- a modern software engineering would have resulted a much simpler solution...). In some reports using Munipack 2, I noticed that eclipses of CVs are systematically recorded fainter (this is common to AIP4WIN). In a few cases, the software failed to measure the object correctly at low light levels, and would produce a systematic bias if these "failed" measurements are simply rejected. I don't know the exact cause, though. Regards, Taichi Kato
Return to the Powerful Daisaku
vsnet-adm@kusastro.kyoto-u.ac.jp
