Fix Version/s: None
Team:Telescope and Site
Fix [imageCoCenter](https://github.com/lsst-ts/ts_wep/blob/40a62fd336ee7d150afa5ae4c7392b7001c6cfaf/python/lsst/ts/wep/cwfs/CompensableImage.py#L273) in `ts_wep`. In principle, the radial shift should be 0 for `paraxial` opticalModel, yet currently there is a radial shift that's only dependent on the distance from the center of the field of view (as in the attached image, illustrating the value of `radialShift` in https://github.com/lsst-ts/ts_wep/blob/40a62fd336ee7d150afa5ae4c7392b7001c6cfaf/python/lsst/ts/wep/cwfs/CompensableImage.py#L310 given offset of 1.5 mm and pixels size 1e-5 m (=10 microns)).
|Field||Original Value||New Value|
|Attachment||image-2022-10-03-11-58-32-914.png [ 63824 ]|
|Attachment||image-2022-10-03-12-04-42-484.png [ 63825 ]|
|Attachment||image-2022-10-03-13-47-00-137.png [ 63827 ]|
|Attachment||image-2022-10-03-13-48-13-480.png [ 63828 ]|
|Attachment||image-2022-10-03-13-54-23-531.png [ 63829 ]|
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.
|Status||To Do [ 10001 ]||In Progress [ 3 ]|
|Remote Link||This issue links to "Page (Confluence)" [ 34902 ]|
|Status||In Progress [ 3 ]||In Review [ 10004 ]|
Thanks for this evaluation and improvement! Great job done. Reviewed in GitHub.
|Status||In Review [ 10004 ]||Reviewed [ 10101 ]|
|Resolution||Done [ 10000 ]|
|Status||Reviewed [ 10101 ]||Done [ 10002 ]|
Currently in the code we have
so that in the end
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