After running the jointcal astrometry on the HSC SXDS field using Pan-STARRS as a reference catalog I have analysed the astrometric scatter from 8 visits (7274, 7276, 7420, 7422, 14108, 14112, 38074, 38080) x 104 CCD (HSC-I filter). I purposely used visit spread over the whole observing time . In order to do so, I arbitrarily use the first visit as a reference then match all the other visits to the first one and compute the angular distance between each source and the reference using both the individual calexp WCS and the WCS updated by jointcal.
The result looks pretty good, but looking into the details of jointcal processing we can see that the fitting algorithms has removed thousands of reference stars identified as outliers. This is probably partly due to our instance of the Pan-STARRS reference catalog which contains a lot of junk sources.
The following plot shows the RA, DEC distribution of the PS reference sources:
We can see that there are strange patterns. There are also many sources with a magnitude > 23.2 which is supposed to be the limit for the PS catalog built from coadded images in the r band.
I also noticed that some fields are missing or null in our PS catalog : the error on position is 0 and the field nDetections is missing. According to @PierreAstier requiring nDetections >=2 would remove most of the spurious sources. @PierreAstier also thinks that using the error on position from the reference catalog in jointcal would improve the result.
I’m assuming nDetections>=2 is a restriction on the creation of the reference catalog, not something to be set in jointcal? One can set minMeasurements in jointcal’s config to determine the minimum number of MeasuredStars for a FittedStar to be used in the fit, but I believe you’re talking about something else here.
Also, see DM-10826 for the question of how to manage position errors. We don’t actually have position errors in most of our reference catalogs, but we should. Jointcal has been “faking” those errors so far, but we need to come up with a way to determine whether the RefCat has position errors and use them if available. Does the PS RefCat you’re using include x, y, and xy (covariance) errors?
This looks somewhat better than your previous results, and quite a bit better than we are getting with obs_mosaic using sdss-dr9-fink-v5b for reference.
I’m curious to see if it is true that the scatter is reduced by comparing against the reference catalog. We did a similar comparison with the obs_mosaic jointcal results and sdss-dr9-fink-v5b, and found that the scatter between the jointcal measured positions on individual exposures was quite a bit smaller than the scatter between those positions and the reference catalog. I assume it depends on how good the reference catalog is.
The PanStarss catalog delivers a field named “nDetections”, and it seems that requiring nDetections>2 suppresses quite a bit the strange spatial patterns. On the Cosmos field, the cut could probably be raised to higher values (5 or 10). (@parejko: you are right, this is unrelated to the minimum number of measurements associated to a “FittedStar” in jointcal). It is clear that we absolutely need position uncertainties in reference catalogs, because they (now) really depend on magnitude. At the moment, jointcal weights all reference objects equally, which is suboptimal, and compromises the outlier removal strategy. It is not even clear that the relative weight of measurements and references in the least squares minimization is roughly correct, at least for panStarss and Gaia.
The original PanStars catalog indeed delivers position uncertainties (however without the xy cross term, I think, but we can imagine that they are roughly isotropic). I have not checked if they make sense. For Gaia, the 3 elements of the covariance matrix are provided, and the errors can be heavily correlated (eg 0.98) for some objects: jointcal cannot properly use Gaia at the moment.
Regarding the implementation, I guess that jointcal should not try to guess if there are uncertainties in the reference catalog, it should just receive position uncertainties, both if those are made up or actually read. I guess that this would probably benefit as well to the single exposure (meas_astrom) WCS fit.
This will always be true: the relative astrometry/photometry will certainly be better than the absolute astrometry/photometry (when comparing with a given reference catalog), even for a perfect reference catalog.
We don’t actually have any facility for including errors in the reference catalog in our refcat schema, as documented in LoadReferenceObjectsTask. I have filed an RFC on the topic: RFC-368
I don’t understand this, with the new reference catalog system that we are using now, we can have as many field as we want, including the errors on position. Or am I wrong ?
We should standardize on how the error fields are included, so that I always can find them with one field name. At present, each catalog could provide them with a different name.
