[track] image cutouts not showing correct part of sky

[mtbannister]

Some cutouts, apparently at random(?), will no longer show the piece of sky they are predicted to be showing.

Tests on object TA (nice and bright, so can't be mistaken) showed that the ds9 cutout is displaying a cutout with the wrong position by about ~half an arcminute or more for 06-25, 06-26, 07-24, compared to what @ijiraq measured in the truncated file. Have not measured those three days. Other overlapping days of 07-23 and 07-27 match exactly what @ijiraq had, and the image cutout looks exactly as it should. 08-28 showed up just fine too.

Loading TA without --skip-previous showed this random empty-piece-of-sky cutout effect to hit about one in ten of the already measured lines, i.e. the measurement that used to show a perfectly good source now shows empty sky.

I don't think it was commit 330523107a2a02f56c44efb2aa5985d461b433d2 - the effect shows up if I pull an earlier commit and run that instead.

[mtbannister]

Further comparison has shown that R8's measurements match exactly between @ijiraq and mine. SH's also match except for a 14" difference in Dec on 07-23 (RA matches exactly); the cutout is correct on that one, and it's SH, confirmed by loading a comparison image. Curious.

SH is showing this effect of cutout not matching previously-measured position as well when all images are loaded. Noticeable on 2013 08 05.48926 , for example.

[mtbannister]

My conclusions from debugging so far:

• the existing dbaseclone data should be fine. the previously accepted lines currently showing the wrong spot of sky have to be valid: a) no issues with residuals b) actual measurement of photons are recorded.
• if this does turn out to be an actual bug and not some odd thing in the display tool, based on how often it has shown up in inspecting three objects each of ~40 lines, it will have at worst affected a tiny portion of submitted lines in what must be only the recent submissions: only a subset of those that have been rejected due to source not visible. These can be figured out, once the bug is found, in my next astrometric pass by running the measurement pass without using --skip-previous.

[jmpetit]

Hi there,

Have you checked the headers of the files, as they are read at the time you see this bad cutout effect ? Am I right that in the "database", the images are separated from the headers ? I think that's what JJ said a long tiem ago, but I may be mistaken. Anyhow, could it be that for some reason, the WCS header in some file is not the accurate one, but rather the original, off by several arcsec one ?

Cheers, Jean-Marc

On Wed, 17 Sep 2014, Michele Bannister wrote:

Further comparison has shown that R8's measurements match exactly between @ijiraq and mine. SH's also match except for a 14" difference in Dec on 07-23 (RA matches exactly); the cutout is correct on that one, and it's SH, confirmed by loading a comparison image. Curious.

SH is showing this effect of cutout not matching previously-measured position as well when all images are loaded. Noticeable on 2013 08 05.48926 , for example.

---

Reply to this email directly or view it on GitHub: https://github.com/OSSOS/MOP/issues/332#issuecomment-55934886

---

[ Jean-Marc Petit ] [ ----- ] [ Institut UTINAM - UMR CNRS 6213 * tel: (33) [0]381 666 929 .../ ] [ Observatoire de Besancon * fax: (33) [0]381 666 944 ./ ] [ 41 bis Avenue de l'Observatoire * email: /.\ ] [ BP 1615 * petit_at_obs-besancon.fr / . \ ] [ F-25010 Besancon cedex * ----- ]

---

[mtbannister]

@ijiraq and I have diagnosed this as being satisfactorily closed by 0d5fe2ad7f5d56373c1f16047feeea3464b027b0 . Turns out the default behaviour of astropy.wcs.WCS doesn't take into account the PV keywords, and they weren't being propagated to the header being used for display. So yes @jmpetit, it was behaving as though the Gwyn header wasn't applied, though it definitely was... Applying a mandatory deepcopy to the header propagates those keywords. Hurrah.