# Fix imageCoCenter and opticalModel in ts_wep

XMLWordPrintable

#### Details

• Type: Improvement
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
• Story Points:
10
• Team:
Telescope and Site

#### Description

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)).

#### Attachments

1. image-2022-09-20-14-20-17-912.png
56 kB
2. image-2022-10-03-11-58-32-914.png
650 kB
3. image-2022-10-03-12-04-42-484.png
89 kB
4. image-2022-10-03-13-47-00-137.png
205 kB
5. image-2022-10-03-13-48-13-480.png
164 kB
6. image-2022-10-03-13-54-23-531.png
116 kB

#### Activity

Hide
Krzysztof Suberlak added a comment -

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

Show
Krzysztof Suberlak added a comment - 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
Hide
Krzysztof Suberlak added a comment - - edited

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.

Show
Krzysztof Suberlak added a comment - - edited 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.
Hide
Krzysztof Suberlak added a comment -

The PR#154 has been merged on github

Show
Krzysztof Suberlak added a comment - The PR#154 has been merged on github
Hide
Te-Wei Tsai added a comment -

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

Show
Te-Wei Tsai added a comment - Thanks for this evaluation and improvement! Great job done. Reviewed in GitHub.

#### People

Assignee:
Krzysztof Suberlak
Reporter:
Krzysztof Suberlak
Reviewers:
Te-Wei Tsai
Watchers:
Bryce Kalmbach, Krzysztof Suberlak, Te-Wei Tsai