# Refactor the image display code to remove explicit references to ds9

XMLWordPrintable

#### Details

• Type: RFC
• Status: Implemented
• Resolution: Done
• Component/s:
• 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.

#### Activity

Hide
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
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 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 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
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
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
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
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 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 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:
Robert Lupton
Reporter:
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)
0 Vote for this issue
Watchers:
9 Start watching this issue

#### Dates

Created:
Updated:
Resolved:
Planned End:

#### Jenkins

No builds found.