Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-36304

Fix imageCoCenter and opticalModel in ts_wep

    XMLWordPrintable

Details

    • Improvement
    • Status: Done
    • Resolution: Done
    • None
    • ts_aos

    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
          Krzysztof Suberlak
        2. image-2022-10-03-11-58-32-914.png
          650 kB
          Krzysztof Suberlak
        3. image-2022-10-03-12-04-42-484.png
          89 kB
          Krzysztof Suberlak
        4. image-2022-10-03-13-47-00-137.png
          205 kB
          Krzysztof Suberlak
        5. image-2022-10-03-13-48-13-480.png
          164 kB
          Krzysztof Suberlak
        6. image-2022-10-03-13-54-23-531.png
          116 kB
          Krzysztof Suberlak

        Issue Links

          Activity

            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  

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

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

            The PR#154 has been merged on github

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

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

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

            People

              ksuberlak Krzysztof Suberlak
              ksuberlak Krzysztof Suberlak
              Te-Wei Tsai
              Bryce Kalmbach, Krzysztof Suberlak, Te-Wei Tsai
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Jenkins

                  No builds found.