Actually, I measured the coefficients from a bright star – much more dynamic range. My notes say

np.array([1.00000000e+00, 4.41695363e-03, 1.26907573e-03, 6.37238677e-04, 3.99808286e-04])

After some discussion, we decided that this should be done in 2-D.  One way would be to add these terms to the fibre profiles; another would be to not include them in the fibre profiles but to run a per-row correction just before writing the pfsArm files.

In fact, of course, the cross-talk is 2-D, but we are planning to handle that by PFS subtraction in 2-D, including the far wings of the PSF, for lines that are bright enough to be a problem.   We do, naturally, have to be careful that we correct once and only once.

Exactly what do the above coefficients represent, and how were they measured?

I've an implementation that appears to work. I'd love to check it out on the original data used to measure the coefficients. rhl, do you have the visit number handy?

Sorry, I should have included that information.  visit, arm = 78454, 'r'; fiberId = 586

Changes in code look fine with me. Minor comment on parameter doc. See pull request https://github.com/Subaru-PFS/drp_stella/pull/286.

The below plots show the spectra around fiberId=586 before (dotted lines) and after (solid lines) the optical crosstalk correction. The first shows the full dynamic range. Note that the flux in the bright fiber is barely affected by the correction. The second shows a zoom around zero flux, where it can be seen the flux before correction is non-zero (especially for the two fibers closest to the bright one, blue and cyan), and that after correction it is much closer to zero.

The "bright" fibre shouldn't be affected at all, should it, if there's no real flux in the neighbouring fibres?  How much is it modified?

The bright fiber is barely modified (the difference is 0.05 +/- 0.11 counts).

Merged to master.

OK, now that "barely" means "not significantly" I'm happy.  I took it to mean a small but real shift (as e.g. you'd see if we did a naïve "1-loop" correction not a full matrix inversion.

Oh, I should note a couple of things:

1. The crosstalk correction needs to be activated explicitly (extractSpectra.doCrosstalk=True).
2. The overwhelming lack of reference points on visit=78454 (which contains three traces and no emission lines) makes me wonder if the detectorMap adjustment in the spectral extraction used to measure the original crosstalk coefficients was reasonable. I have added a doForceTraces parameter to reduceExposure.py that forces use of traces (not just emission lines) when doing the detectorMap adjustment; this also needs to be activated explicitly.