Uploaded image for project: 'Request For Comments'
  1. Request For Comments
  2. RFC-42

Refactor the image display code to remove explicit references to ds9

    Details

    • Type: RFC
    • Status: Implemented
    • Resolution: Done
    • Component/s: DM
    • Labels:
      None
    • Location:
      PR

      Description

      The current stack image display code assumes that you're talking to ds9:

      import lsst.afw.display.ds9 as ds9
       
      ds9.erase()

      As the IPAC team thinks about supporting firefly, and ginga gains traction in the scipy world, we need replace this interface with something more general.

      In the longer run we need to decide what APIs we need to support, but this is hard to do until we have more than one backend. This RFC proposes that we change the interface to something like:

      import lsst.afw.display.imdisplay as imdisplay
      imdisplay.setBackend('ds9')
       
      imdisplay.erase()

      It would be possible to hoist these methods to lsst.afw.display itself:

      import lsst.afw.display as afwDisplay
      afwDisplay.setBackend('ds9')
       
      afwDisplay.erase()

      A discussion of the pros and cons is in scope for the RFC.

      The choice of backend (in this case ds9) should be configurable either explicitly, as illustrated here, or via some deus ex machina technique (a dot file, an environment variable, ...). I put the backend choice explicitly in the examples, but I would not expect this to appear in utility code.

        Attachments

          Issue Links

            Activity

            Hide
            tjenness Tim Jenness added a comment -

            I'll note that for the "do I want this displayed" logic to work, there needs to be a way for the display system to understand what stage in the processing this product represents. Do the ExposureX objects, or whatever, know what's been done to them?

            Show
            tjenness Tim Jenness added a comment - I'll note that for the "do I want this displayed" logic to work, there needs to be a way for the display system to understand what stage in the processing this product represents. Do the ExposureX objects, or whatever, know what's been done to them?
            Hide
            frossie Frossie Economou added a comment -

            Yes, I am very keen on the design approach of (a) decoupling the code from a gui implementation and (b) giving control to the user as to how to tap into the display [Gregory Dubois-Felsmann got an earful of my opinions on the matter the other day]. It stands up to a wide range of scenarios and people are happy. You can have a default configuration for the display, but the code itself should be display agnostic.

            Show
            frossie Frossie Economou added a comment - Yes, I am very keen on the design approach of (a) decoupling the code from a gui implementation and (b) giving control to the user as to how to tap into the display [ Gregory Dubois-Felsmann got an earful of my opinions on the matter the other day]. It stands up to a wide range of scenarios and people are happy. You can have a default configuration for the display, but the code itself should be display agnostic.
            Hide
            rhl Robert Lupton added a comment -

            Re Tim Jenness's comment:

            I'll note that for the "do I want this displayed" logic to work, there needs to be a way for the display system to understand what stage in the processing this product represents. Do the ExposureX objects, or whatever, know what's been done to them?

            I think this is out of scope for this RFC, which is about display technology.

            The answer is no, they don't. We are not currently configuring debug displays this way (they are configured via the lsstDebug mechanism), although it sounds perfectly reasonable. It surely ties into the whole provenance system which doesn't exist yet.

            Show
            rhl Robert Lupton added a comment - Re Tim Jenness 's comment: I'll note that for the "do I want this displayed" logic to work, there needs to be a way for the display system to understand what stage in the processing this product represents. Do the ExposureX objects, or whatever, know what's been done to them? I think this is out of scope for this RFC, which is about display technology. The answer is no, they don't. We are not currently configuring debug displays this way (they are configured via the lsstDebug mechanism), although it sounds perfectly reasonable. It surely ties into the whole provenance system which doesn't exist yet.
            Hide
            rhl Robert Lupton added a comment -

            I've pushed a prototype to tickets/pr-42, with a notebook to illustrate the API in examples/imageDisplay.ipynb (I can't get nbviewer to display that notebook, I think because it's on a branch; for now see http://www.astro.princeton.edu/~rhl/imageDisplay.html).

            I adopted Jim's suggestion to make the interface use objects, and support "virtualDisplay" and "ds9"

            Show
            rhl Robert Lupton added a comment - I've pushed a prototype to tickets/pr-42, with a notebook to illustrate the API in examples/imageDisplay.ipynb (I can't get nbviewer to display that notebook, I think because it's on a branch; for now see http://www.astro.princeton.edu/~rhl/imageDisplay.html ). I adopted Jim's suggestion to make the interface use objects, and support "virtualDisplay" and "ds9"
            Hide
            xiuqin Xiuqin Wu [X] (Inactive) added a comment -

            SUI team at IPAC got together and discussed this RFC and Robert's new implementation. In general, Firefly will be able to support this with Python APIs. More details and questions later.

            Show
            xiuqin Xiuqin Wu [X] (Inactive) added a comment - SUI team at IPAC got together and discussed this RFC and Robert's new implementation. In general, Firefly will be able to support this with Python APIs. More details and questions later.

              People

              • Assignee:
                rhl Robert Lupton
                Reporter:
                rhl Robert Lupton
                Watchers:
                Frossie Economou, Gregory Dubois-Felsmann, Jim Bosch, John Swinbank, Michael Wood-Vasey, Robert Lupton, Russell Owen, Tim Jenness, Xiuqin Wu [X] (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                9 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Planned End:

                  Summary Panel