Currently in the code we have

radialShift = fov * (offset / 1e-3) * (10e-6 / pixelSize)    l.306

fieldDist = self._getFieldDistFromOrigin()

radialShift = radialShift * (fieldDist / (fov / 2))   l.310

so that in the end 

radialShift = (offset / 1e-3) * (10e-6 / pixelSize) * fieldDist * 2

i.e. independent of fov. This means that  although "fov" in l.306 stands for the reference shift in pixels,  and in l.310 for the size of the field of view in degrees, their identical value means that in the end "radialShift" is entirely independent of the "fov". Need to investigate why the reference value of distortion  in pixels ("fov" in l.306) is exactly the same numerically as the size of the field of view in degrees  

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. 

The PR#154 has been merged on github

Thanks for this evaluation and improvement! Great job done. Reviewed in GitHub.