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

Document Camera Geometry for the SWUG

    Details

    • Team:
      SQuaRE

      Description

      Develop a chapter for the LSST SWUG on camera geometry, with a high-level introduction to how the geometry is represented in software. Describe the high-level steps that are necessary to support a new camera in LSST software. Another page (probably in the DM Developer Guide) would provide a step-by-step "how-to" of building software for a new camera; this task is to provide the background and context necessary to understand the concept of camera geometry as used in LSST software.

        Attachments

          Activity

          Hide
          shaw Richard Shaw [X] (Inactive) added a comment -

          I think the page on Representation of a Camera is at last ready for review.

          Show
          shaw Richard Shaw [X] (Inactive) added a comment - I think the page on Representation of a Camera is at last ready for review.
          Hide
          krughoff Simon Krughoff added a comment -

          Review comments. Hopefully they are useful:
          LSST Stack is bold, but is not linked.
          Frequently words are in bold but not linked, are you linking them only the first time they are mentioned?

          • "populated with an array of sensors" – I think this implies that the sensors are in a grid. That is not necessarily the case, they can be anywhere (even overlapping).
          • I believe the science pixels are 509x2000 per amp (not 512x2000).
          • The diameter of the nominal field of view is 3.5 deg. The radius is 1.75 deg. I couldn't tell which you meant in the text.
          • I may have missed it, but I did not see a link to the Doxy documentation. It' probably worth putting in a pointer.
          • It would be good to mention that any coordinate system can be defined, but the four you mention are the default ones.
          • When referring to the camera object, I think it should be {\tt Camera}

            , not

            {\it \bf camera}

            .

          • In Camera Attributes, I believe we try to keep things in terms of mm (not micrometers). The device type is intended to name the use of the detector (SCIENCE, GUIDING, etc.) not the technology.
          • "support most known FPAs" – I don't know of any that aren't supported. I'd be interested to know if you know any that aren't. The wavelength dependence is not explicitly handled, but I don't see why it couldn't be added to the transformMap.
          • obs_cfht – I'd actually use the obs_cfht in the stack. I believe that's the one Dominique has been using.
          • create astrometry.net indexes – Unfortunately these are also currently needed for photometric calibration.
          • "concept of time-dependent calibration files" – I think K-T would argue that the Butler can handle it, but that no one has used it yet.
          • Create a custom mapper – You may also have to create a subclass of CameraMapper (most instruments do this now).
          • Exercise the Software – Is it worth pointing to an example of how to do this (dm stack demo maybe), so the reader can at least execute processCcd.py even if it does not give the correct answers right away?
          Show
          krughoff Simon Krughoff added a comment - Review comments. Hopefully they are useful: LSST Stack is bold, but is not linked. Frequently words are in bold but not linked, are you linking them only the first time they are mentioned? "populated with an array of sensors" – I think this implies that the sensors are in a grid. That is not necessarily the case, they can be anywhere (even overlapping). I believe the science pixels are 509x2000 per amp (not 512x2000). The diameter of the nominal field of view is 3.5 deg. The radius is 1.75 deg. I couldn't tell which you meant in the text. I may have missed it, but I did not see a link to the Doxy documentation. It' probably worth putting in a pointer. It would be good to mention that any coordinate system can be defined, but the four you mention are the default ones. When referring to the camera object, I think it should be {\tt Camera} , not {\it \bf camera} . In Camera Attributes, I believe we try to keep things in terms of mm (not micrometers). The device type is intended to name the use of the detector (SCIENCE, GUIDING, etc.) not the technology. "support most known FPAs" – I don't know of any that aren't supported. I'd be interested to know if you know any that aren't. The wavelength dependence is not explicitly handled, but I don't see why it couldn't be added to the transformMap. obs_cfht – I'd actually use the obs_cfht in the stack. I believe that's the one Dominique has been using. create astrometry.net indexes – Unfortunately these are also currently needed for photometric calibration. "concept of time-dependent calibration files" – I think K-T would argue that the Butler can handle it, but that no one has used it yet. Create a custom mapper – You may also have to create a subclass of CameraMapper (most instruments do this now). Exercise the Software – Is it worth pointing to an example of how to do this (dm stack demo maybe), so the reader can at least execute processCcd.py even if it does not give the correct answers right away?
          Hide
          shaw Richard Shaw [X] (Inactive) added a comment -

          Simon: thanks for the review. I adopted all of your suggested changes, except the last I don't understand. How would pointing the user to the stack demo illuminate how to roll your own camera? Maybe I'm missing something. I would be glad to add additional links if it helps.

          One last question: if this page had been available to Dominique before he started his work on obs_cfht, do you think it would have helped?

          Show
          shaw Richard Shaw [X] (Inactive) added a comment - Simon: thanks for the review. I adopted all of your suggested changes, except the last I don't understand. How would pointing the user to the stack demo illuminate how to roll your own camera? Maybe I'm missing something. I would be glad to add additional links if it helps. One last question: if this page had been available to Dominique before he started his work on obs_cfht, do you think it would have helped?
          Hide
          krughoff Simon Krughoff added a comment -

          I was just saying that you have a bunch of bullets that the user could do after they have a camera, but there's no link telling them how to do the things you suggest. I'm not sure what that link is. I'm sorry that I don't have a more complete answer.

          Having something like this would definitely have helped him understand the how the cameras are handled in the pipelines.

          Show
          krughoff Simon Krughoff added a comment - I was just saying that you have a bunch of bullets that the user could do after they have a camera, but there's no link telling them how to do the things you suggest. I'm not sure what that link is. I'm sorry that I don't have a more complete answer. Having something like this would definitely have helped him understand the how the cameras are handled in the pipelines.

            People

            • Assignee:
              shaw Richard Shaw [X] (Inactive)
              Reporter:
              shaw Richard Shaw [X] (Inactive)
              Reviewers:
              Simon Krughoff
              Watchers:
              Mario Juric, Richard Shaw [X] (Inactive), Simon Krughoff
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Summary Panel