There are two pull requests: One in https://github.com/lsst/pipe_tasks/pull/372 that shifts some preparatory calculations into DcrAssembleCoaddTask that is needed in order to actually use PSF-matched warps. The second is the notebook with the analysis, in https://github.com/lsst-dm/ap_pipe-notebooks/pull/28 . The notebook is the focus of this ticket.

Thanks for sending this. I'm trying to get up to speed on what DCR is. Is https://dmtn-037.lsst.io/ the right place to start?

Yes, that's the technote that describes a bit of the background and my algorithm for calculating a DCR model and corrected templates. https://dmtn-017.lsst.io has even more background on the topic, so that might make a better place to start, though you probably don't need to read it in detail.

Okay, I've given it a full read-through, and think I'm ready to ask a bunch of questions.

What does "direct warp" mean in the sense used in the notebook? It's images that have been warped, but not PSF-matched?

I'm not sure what to be expecting from the "Look at RGB images" section. The text says "the quasars do appear to be more blue than the rest of the bright stars," but what I'm not sure what the significance of this is. There's also a line, "This suggests that there is a systematic position offset between the two, similar to how DCR-induced astrometric calibration errors show up as a shift in the spectral slope of detected objects." I don't follow this, possibly because I'm not familiar with the spectral shope shift effect you're referencing.

I don't understand why DCR + PSF matching would avoid the detector edge effects that plague the PSF-matched CompareWarp 2014 run (described in the text just above `In[51]`). Why would that be the case?

How are the `nDiaSources` values calculated? The plots for them at the end of the notebook look really important for your overall conclusions.

Toward the end of the notebook, I can't tell whether reducing the total number of DIA Sources is a good thing, or a bad thing. I'm not sure how to interpret the graphs towards the end - what would a really good graph look like, for a hypothetical ideal algorithm?

What does "direct warp" mean in the sense used in the notebook? It's images that have been warped, but not PSF-matched?

Yes, "direct warps" are images that have been registered to a common astrometric frame (warped), but have not otherwise been convolved with anything. This means that every direct warp will have a different PSF.

I'm not sure what to be expecting from the "Look at RGB images" section. The text says "the quasars do appear to be more blue than the rest of the bright stars," but what I'm not sure what the significance of this is. There's also a line, "This suggests that there is a systematic position offset between the two, similar to how DCR-induced astrometric calibration errors show up as a shift in the spectral slope of detected objects." I don't follow this, possibly because I'm not familiar with the spectral shope shift effect you're referencing.

The significance of the quasars looking more blue than the bright stars is just that they look different, which is what we expect if the DCR algorithm is working properly. The quasars have a different spectrum in g band than the stars, so if the model is picking up real color differences then we should at least expect them to look different. As for the comment about astrometric errors, I was referencing work I've shown in talks, but don't have published anywhere so there isn't any way you could have known about it. In summary, if I introduce astrometric calibration errors in simulations, that shows up as a overall shift in color between the average recovered spectrum (measured from the sub-band images) and the true spectrum that went in to the simulation. If calibration is perfect (which is easy in simulations: you just skip astrometric calibration!), then the measured color matches the true color on average.

I don't understand why DCR + PSF matching would avoid the detector edge effects that plague the PSF-matched CompareWarp 2014 run (described in the text just above `In[51]`). Why would that be the case?

I don't actually know why the artifacts are different between the two cases, unless the artifacts are all within a couple pixels of the edge. I pointed out the difference mostly to emphasize the errors in the 5 sigma detections, and motivate using the higher 20 sigma detection threshold for this comparison. This difference might also be related to a known issue: DM-22825.

How are the `nDiaSources` values calculated? The plots for them at the end of the notebook look really important for your overall conclusions.

DIA stands for difference image analysis. The number of DIA sources is the number of detected sources above a given threshold in the residual images after image differencing. Very generally, image differencing consists of warping a template to match the WCS of the science image, convolving (or deconvolving) the template with an Alard-Lupton matching kernel, and detecting peaks in "good" regions of the image.

Toward the end of the notebook, I can't tell whether reducing the total number of DIA Sources is a good thing, or a bad thing. I'm not sure how to interpret the graphs towards the end - what would a really good graph look like, for a hypothetical ideal algorithm?

The ideal case would look like results run on simulations, from https://dmtn-121.lsst.io . The most relevant plot there is Figure 3, though the information is displayed differently. It shows a ~80% reduction in false detections using the DCR matched template, and since we believe that most of the detections with our current pipeline on Decam HiTS are false positives, I would like to see a decrease in DIA sources of ~50%.

Thanks for the explanations. This makes sense - or at least, I completely agree with your conclusion that "results are mixed."

If you are done with your review, please also mark both of the pull requests as "reviewed" on GitHub.