Allow magnitude filtering for tweakreg

[stscijgbot-jp]

Issue JP-2818 was created on JIRA by David Law:

Filing this as a Jira ticket to track the discussion better than on slack.

As discussed recently on slack, the MIRI imaging tweakreg seems to fail periodically to achieve a good solution against Gaia.  On digging into it a little, this seems to be in large part because there is no magnitude filtering being applied to the Gaia source catalog.I f that’s the case, it’s not surprising that it’s having problems with the MIRI data since the Gaia and MIRI imaging are are radically different wavelengths.

Whether or not a Gaia source is detectable in MIRI will depend strongly on the spectral type, but generally speaking anything fainter than 18th in Gaia isn’t reliably going to be seen in MIRI.  Below 17th mag you start having more misses.  In my by-hand alignments, I've generally only used Gaia sources brighter than 18.

Plot attached shows rough source counts as a function of Gaia magnitude for Misty's example program 1171.

Karl Gordon Mattia Libralato Misty Cracraft and Mihai Cara should weigh in with opinions, but I'd suggest having tweakreg ignore stuff fainter than Gaia magnitude 18 when running tweakreg.  Performance in this case seems much improved when I hack that in.

[stscijgbot-jp]

Comment by Misty Cracraft on JIRA:

That seems a better option than trying to figure out which parameters to set for each dataset. I'm just starting to look into optimizing parameters based on filter, but I'm choosing random crowded fields from commissioning data that I can find and I have concerns about how well the parameters found for one data set can be generalized for most taken in each filter. If we can do some filtering and use that to cut down on source matching problems, I'm on board with that suggestion.

 

[stscijgbot-jp]

Comment by Karl Gordon on JIRA:

I full support this. Filtering by gaia mag makes great sense!

[stscijgbot-jp]

Comment by Howard Bushouse on JIRA:

If the fainter objects are not detected in the MIRI images, how is that throwing off the alignment calculations? They should not be part of the solution at all. Or are they ending up with false positives (at bogus positions) or just unreliable positions in the MIRI images?

[stscijgbot-jp]

Comment by David Law on JIRA:

I'm not certain how tweakreg works, but at least in my own non-pipeline tool I found false positives were a problem.  Looking at the entire 2d image it can be clear that things are simply shifted 0.3'' up and to the left for instance, but there are so many 19-20th mag Gaia object that some happen to be closer to the uncorrected MIRI source positions than the real 16th mag source.

My guess is that tweakreg is having similar issues, as hacking in a magnitude cut improved performance in program 1171.

[stscijgbot-jp]

Comment by Jeff Valenti on JIRA:

Jay Anderson - You've written software to match catalogs for the purpose of improving the WCS. Any thoughts on algorithm?

[stscijgbot-jp]

Comment by Alicia Canipe on JIRA:

Reassigning to Anton Koekemoer /CalWG for algorithm updates 

[stscijgbot-jp]

Comment by Mattia Libralato on JIRA:

The large wavelength difference between Gaia and MIRI doesn't help for sure. Adding an option for the magnitude would help, but will not solve the problem when the only stars in common with Gaia are faint in MIRI. But why isn't the 'snr' option not enough to ensure only the brightest sources in MIRI are considered in the match?

The tweakreg algorithm used in the pipeline is based on proximity and, as such, it is not going to work properly in crowded fields where most of the sources in common are faint, at the limit of what you can consider a real star or just junk. Gaia is not the issue in my opinion because at G~20 the positional error is ~0.5 mas, or 0.005 MIRI pixels. If I remember correctly, the pipeline first computes an histogram to find the first-guess offset, assuming that both the stars found in Gaia and in the MIRI catalog are more or less the same. These could be the reasons of the fail: there is not a check to ensure the "who is who" step worked besides proximity.

Also, I'm not sure if the tweakreg routines allow for the same star in one catalog to be crossmatched to multiple stars in another catalog. This can result in an additional problem.

To find who is who in two lists, there are multiple ways, probably the most famous (used also by the DAOPhot utils) way is the similar triangle technique (http://ned.ipac.caltech.edu/level5/Stetson/Stetson5_2.html).

I don't know which specific Jay's software you are referring to, but the Jay's software I've been using in the last 10+ years works with coordinates on a tangent plane and takes advantage of linear transformations (2 offsets, scale, rotation, 2 skews) to transform both sets of coordinates onto the same reference system (usually one of the two sets is selected as a reference). The 'who is who' part is taken care in many ways. Once in the same reference system, if the astrometry (=geometric distortion correction) is good enough, one can check whether the crossmatches are legit or not by looking at the positional residuals, as well as reject mismatches. If the match is wrong, the positional residuals can tell you that, and one can adjust the software arguments to make it work.

The big tweakreg package has an option in "xyxymatch" that would allow something like what I described (algorithm='triangle' instead of 'tolerance'). It takes two sets of coordinates in two tangent planes (like the V2V3 space), find the transformations, check similar triangles, and so on. However, it is heavy and slow (I haven't been able to make it work yet, not even with a simple case).

[stscijgbot-jp]

Comment by Jay Anderson on JIRA:

In most situations, I think the engineering data and knowledge of the plate scale can help us restrict the parameters needed in the match to two or maybe three: the boresite error (dx, dy) and perhaps a small amount of orientation error. I would think, though, that one can ignore the rotation error in source identification, perhaps including it later when trying to effect the best possible transformations.

With HST, and so far with JWST, I am finding that it's useful to realize that stars that GAIA measures well are often not the best measured stars in HST/JWST, and stars that HST/JWST measure well are often too faint for the GAIA catalog. But, absent better engineering data and V2V3 calibration, HST/JWST have a hard time getting high-precision astrometric registration, so they depend on GAIA. So... you don't really need the general case of 6-order transformations, though if there's breathing and such, you may want to use 6 for the final WCS determination.

I usually do image registration in two steps: differential and absolute. You can do either step first or second. I think it is easiest to start with the local JWST-JWST comparisons.

Let's say we have 4 dithered images at the same orientation that you want to align. You make a star-list in each one and then use, say, a histogram method* to do the cross-identification. If you use a PSF to measure the star positions (even a crude PSF will do; it would be easy to come up with such a PSF for each filter; this can be included as data in the star-measuring algorithm, not treated as a separate reference file), you automatically have a sense of which objects are stellar and which are resolved, and you can focus on the stellar sources. This will also throw out stars that have nearby blends that will affect the position quality. The PSF fitting can also give you a sense of the the error in each star's position. You can (dx,dy) align images 2, 3, and 4 to image 1. You can then combine all four measurement to get a more precise position in Frame#⁠1 (or the distortion-corrected version of frame#⁠1), along with an RMS sense of how precise each position is measured. Distortion correction can be made, but when the dithers and distortion is small, this isn't always critical.

Once you have a refined list of distortion-corrected positions and position errors in Frame#⁠1, you can cross-match with GAIA. Depending on how many GAIA cross matches you have, you can improve the CRVAL1 and CRVAL2 numbers, and maybe even tweak the rotation in the CD matrix... or maybe even the scale and skew, if that is found to vary over time.

The benefit of this approach is that it allows the inter-images offsets to be specified with the high-precision of the JWST measurements, using stars that JWST can measure well, but that may not even be in the GAIA catalog... and then it uses the GAIA catalog only for the final astrometric zeropoint calibration, which JWST doesn't know well.

• The 2-d histogram method for matching N stars in list 1 (x1_n, y1_n) and M stars in list2 (x2_m, y2_m) is that you create a temporary image hist_ij that is (say) 201x201 pixels initialized to zero (if you assume that the error in offset cannot be more than 100 pixels). You then do: do n = 1, N { do m = 1, M { i = int(x1_n-x2_m+101.5) j = int(y1_n-y2_m+101.5) if ( 2 > i > 200 && 2 > j > 202) { do ii = i-1, i+1 { do jj = j-1, j+1 {
  hist_ij(ii,jj) = hist_ij(ii,jj) + 1 } } } } }

  The maximum value of hist_ij is at the location of the offset between image N and image M. You can then cross identify the stars and sigma-clip average the (dx,dy) values to arrive at the offset (and error). This is pretty robust and works even for small numbers of stars.

[stscijgbot-jp]

Comment by Mattia Libralato on JIRA:

[From a discussion in a MIRI Imager WG meeting.] The magnitude threshold to set for Gaia (and for the JWST image, in our case MIRI image) would depend on the wavelength. We could use part of what the pipeline already has to set an automatic threshold by predicting the MIRI magnitude of a source in Gaia given its G magnitude, transforming it in flux, and finally applying the same threshold used for the MIRI source catalog in tweakreg (given by the option 'snr') to get rid of faint stars that we already know are not present in the MIRI image.

[stscijgbot-jp]

Comment by David Law on JIRA:

Anton Koekemoer Mattia Libralato This ticket has been open with no progress for over a year, and I have a feeling tweakreg for imaging mode has probably moved on at this point.  If no longer relevant, perhaps this can be closed?

[stscijgbot-jp]

Comment by Mattia Libralato on JIRA:

Hi, we can close it in my opinion. We have now various options that we can play with to find a proper match with Gaia.

[stscijgbot-jp]

Comment by Anton Koekemoer on JIRA:

thanks David Law  and Mattia Libralato  -- the "INS team criticality" for this ticket is MIRI/medium, and since we follow the instrument branch priorities for working on tickets (and lacking numbers for the "impact" / "urgency" rating for this ticket) it has remained below all the higher priority tickets that continue being worked on.

If, as original reporter of this ticket, you're proposing to withdraw it then that can be accommodated, so I've now set its status to 'withdrawn'.

If the MIRI team (or others) would like to re-open it at any time in future please feel free to do so (along with updated "INS team criticality" ratings, if appropriate).