Systematic error in Coordinate i, which must be non-negative.
Random error in Coordinate i, which must be non-negative.ĬSYERi –. Some estimate of standard deviations would be useful.ĬRDERi –. LibMar, that may be a factor in this case.Īn analysis of the propagation of errors through the entire process might be a good exercise, it could guide what reasonable expectations are. The solution usually down-samples submitted images (almost certainly) losing some accuracy in the process, but processing huge images is very slow, so it makes sense to reduce their size just to process more images per minute. However does not use that catalog (at least not yet to the best of my understanding). The GAIA DR2 is an excellent reference, if you do all of your plate reductions based on it. The issues have hardly gone away in the last 35 years. Its heavy on math and a bit of a slog to read. That book is the bedrock of astrometry, and worth owning a copy. The book "Astronomy of Star Positions" by Heinrich Eichhorn (1974) goes into great detail discussing the variations of star catalogs from one to another. Posted at this stage, so maybe I will get a solution earlier? I could give a try with frames taken another nights, to see if the issue appears as well. What could be the issue, which way should I go? I may post one of FITS frames, but the forums limit me to 0.5MB files (one FITS is 13.6MB) for a comparison if one does well astrometry and could say with more confidence which RA/DEC they got and should be correct.
And, it's an 8" f/4 Newtonian with ASI1600MM-c, with TS coma corrector attached (that appears to work well). Changes would only rather increase the scatter. I don't get exactly same stars after each exposure (due to tracking, wind), but even if the shape is great and average, still datapoints show the same offset.
Not perfect circles, but ok for full FOV - attached an example. If plate solving was done, AIJ was doing centroid placements (and red datapoints show it's nicely concentrated, like correctly). but I don't think that's the usual approach. PPMXL, UCAC4, USNO A2.0/B1.0).ģ) It is not a result of proper motion by those stars - it is visible (vectors are correct) by comparing datasets, but they are all similarly shifted to my results.Ĥ) The shift is similar even for objects that are near the edge of frames (comparison star green, which seemed to be more shifted than the yellow in graph, is actually much closer to HAT-P-5).Īpparently I could simply do astrometry for like 50 nearby stars for a shift calculation and this may work. That's about half of pixel.Ģ) The offset is similar what other datasets show (eg.
Image is a full FOV that is about 45x45 in arcminutes.ġ) All frames (first and even those last ones 3 hours later) have a shift in RA by about 0.1" and DEC by about 0.5", compared to Gaia EDR3 positions using J2000 column. Except that, I added six astrometry positions of 2 objects for a reference (green C2, yellow C3). So, I opened 20 first frames and manually pasted RA/DEC positions (T1) after plate solving through, done automatically by the AstroImageJ program. The first problem is, I cannot work with several files at once, because files become corrupted (IO error: java.io.IOException: Invalid FITS Header) does anyone have this issue? It works only when I work with frames separately. With ~1.0"/px the scatter appears that the centered spot reaches <0.1" of precision in RA/DEC with a few minutes of data, but the given spot is not the right position. A massive amount of data allows to find the center, which becomes more precise. I am trying to run a dataset from HAT-P-5 b transit, so I have more than a thousand frames that are 10 seconds exposure each. I'm encountering some issues related to plate solving, when trying to work with large sets. I've been using AstroImageJ for photometry and I see this program doing well for astrometry as well. I would like to give a try in astrometry topic, especially related to stellar proper motions & eventual paralax circles, if going long-term about that.