A discussion ensued whether this step is necessary. The amount of shift introduced in this step is so small (<6 px), that the "recenter" shift during the image compensation step entirely corrects for any offset that existed between the image and the template based on the reported 'fieldX', 'fieldY' position. This has been tested by turning the "ImageCoCenter" on and off for each donut pair, with varying degrees of vignetting (as in the attached image)
We find that the resulting Zernikes are bitwise-identical. We show an illustration for one of the donut pairs. Other donut pairs show similarly no difference
This means that the amount of cocenter shift needed to change the result (from not using cocenter at all) is greater than 6px.
To find at which point cocenter starts to matter, we artificially increase the cocenter offset (applied always at 0th iteration of the algorithm) by a multiplicative factor from 1 to 10, increasing the radial offset. For instance, for intra donut "0", it increases the cocenter offset from 5.22 px (original) to 52.22 px (maximum). The following figure illustrates the dependence of the RMS difference between the Zernikes estimated for the as-calculated amount of cocenter radial offset and the Zernikes estimated with the additional radial offset.
Without getting into details about the shape of that function, we focus on the radial shift in the range under 10 pixels. We check how large can that offset be before we record any change in the estimated Zernikes checking a smaller range of multiplicative factors:
This shows that adding up to approximately 9 px of coCenter shift makes absolutely no difference to the retrieved Zernikes (between no Cocenter at all). This suggests that the algorithm would not suffer by removing the cocenter offset, given that its amount was defined to be less than 6 px.