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
- is triggering
-
- Done
Activity
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.
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.
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"
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.
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?