As @eteq said he would.

Whenever it is available under Anaconda, we have to make sure it works under both Qt4 and Qt5.

Move away from Qt-specific codes by using Ginga's toolkit-agnostic widgets. Then, we can stop requiring stginga to only work with Qt toolkit.

Like ejeschke/ginga#268 but for ChangeHistory. For this case, only resize first column, as it is impractical to fit all description (second column) into view. And perhaps, only resize it once to a constant width at GUI initialization, since timestamp length will be always the same.

Also see ejeschke/ginga#263 for related discussions.

@bhilbert4 can elaborate further or correct me here.

1. Mark each DQ value in different color. But where do we draw the line, as there are only so many colors you can overlay before overcrowding the display? How to handle pixels with multiple DQ flags?
2. For a given DQ value, plot number of affected pixels across the ramps. See #40.

In redo(), add

    image = fitsimage_blah_blah
    if image is None:
        return True

• Get them under
• Resizable with handles
• Redo zoom when resized
• Show/hide the postage stamps on plugin start/stop

• Find how to get to plugins
• Check if MultiImage is active and hook
• Provide the common region to both, with WCS.

Context-dependent operations on the stamps:

• Identify (#3)
• Remove
• Make primary (#16)

• WCS or pixel space
• Region modes: Edit, Move, Delete
• Instructions (again)
• Administration buttons (close, etc.)

imexam (https://github.com/spacetelescope/imexam/) can use Ginga viewer. Does it make sense for stginga to somehow also enable users to access imexam?

Was spacetelescope/imexam#41.

Since MultiImage is basically a clone of Pick, much of the code reads as Pick code. Rename things properly.

'Tis a silly thing, but necessary...

This is in conjunction with ejeschke/ginga#223. Also see ejeschke/ginga#215.

Add a "Load" button to load parameters from previously saved JSON file. However, it does not make sense to load image path nor background value, which should be re-determined based on currently active image.

@eteq , RTD build has been failing since the past week. The latest log (https://readthedocs.org/projects/stginga/builds/3596379/) suggests it might have something to do with your IPython notebook documentation. Could you please look into this? Thank you!

@stscieisenhamer, please confirm you have the permission you need.

As suggested by @eteq . It is currently hosted by SSB and needs SSB group access to update.

As per #32, will change the workflow as follows:

• MultiImage becomes a global plugin, and is started at any point
• To add an image, an explicit keystroke is needed.
  • Option to add automatically.
• Where the image comes from is irrelevant
• To cycle through the images, a different set of keystrokes, or overload of the arrow keys, will cycle through the JUST the images added to MultiDim, as long as that plugin has focus. Again, the cycling would cross channels if necessary.
• Make images removable.
• The image in the main viewer does not actually have to be part of the stamps. <- Need to think about that.

Steps for implementation

• Make plugin global (#96)
• Add manual addition
• Override arrow keys for cycling.
• Implement #30

DQInspect saves the current X and Y positions in self.xcen and self.ycen. Given that Ginga can concurrently display images of different sizes, the coordinates may be invalid when user switches to another (possibly smaller) image. When this happens, the following traceback will appear:

2015-11-24 15:43:05,497 | E | GwMain.py:74 (update_pending) | gui error: index 1903 is out of bounds for axis 0 with size 800
2015-11-24 15:43:05,499 | E | GwMain.py:78 (update_pending) | Traceback:
  File ".../ginga/gw/GwMain.py", line 69, in update_pending
    res = future.thaw(suppress_exception=False)
  File ".../ginga/misc/Future.py", line 36, in thaw
    res = self.method(*self.args, **self.kwdargs)
  File ".../stginga/plugins/DQInspect.py", line 332, in redo
    pixval = data[int(self.ycen), int(self.xcen)]

This can be recreated by opening two images with different dimensions (say, one fullframe and one subarray). Start the plugin. Set X and Y positions to a place on the fullframe that would be out of range for the subarray. Switch display to subarray.

This can also be recreated by just selecting X and Y positions that are out of range on the same image.

Suggested solution 1: Automatically set the offending coordinate to max allowed value based on the size of the newly selected image. (What if user is angry at losing the existing values?)

Suggested solution 2: Issue an error a warning message in the log and do nothing.

Everything is doubled.

stginga script breaks with ejeschke/ginga#230. Whether a fix is really needed depends on if the Ginga PR is accepted or not.

Move BadPixCorr plugin from QUIP to stginga. Basically, user select an area of interest to fix and fix it.

Ideas: http://stackoverflow.com/questions/1616228/pyqt-gui-testing

Currently it is "alabaster". Ginga uses "sphinx_rtd_theme". What should we use?

http://sphinx-doc.org/theming.html#builtin-themes

Right now MIPick is a copy of Pick with some minor changes. I would suggest subclassing Pick instead. I noticed while testing MIPick the other day that it is already missing some of the enhancements and updates to Pick, like the radial plot curve fit.

We subclass a lot of the standard plugins here at Subaru in order to customize them for our specific observation workflow. It works pretty well. Occasionally we need to modify the "core" plugin to add a callback or to expose a structure so that it can enable some functionality in the subclass. Generally this can be done in a pretty non-invasive way. Very occasionally the subclass has such radical changes that it becomes better to disentangle them by copying the relevant parts of the core plugin and skipping the subclassing, but I would say that in the current form MIPick isn't fundamentally different.

This is not particularly critical because things are currently working fine... But we might want to consider switch to the affiliated package template for stginga - it makes it easier to manage a variety of things like tests/doc improvements/etc.

Ensure this works in both Python 2 and 3.

It looks like there is a half finished "Correct WCS" function in Pick. Is this something that started in MPick?

In gingawrapper.py, gmain.default_layout is re-defined to accommodate MultiImage plugin. I believe this only works if user starts Ginga use stginga command directly. What if user uses our plugins in the two other ways that we said they could (see http://stginga.readthedocs.org/en/latest/run.html)?

Pending discussions with ginga core itself, provide option to lock the main viewer to a particular region, not necessarily the postage stamp region.

There is a need to document how to use our plugins and how to customize them (if applicable).

This is only relevant if ejeschke/ginga#270 is accepted and merged.

This effectively moves the ChangeHistory plugin to Ginga core distribution. Hence, we should delete the version currently in stginga and use the one from Ginga instead. Our setup codes also need to be updated as well.

Continued from related discussions in ejeschke/ginga#162. c/c @mcara

Populate docs/source/ipynb.rst with contents of the Sprint demo after #55 is merged.

Issue reading WCS coordinates

This is a follow-up of #72.

• Turn minimum SBR limit into user preference (currently hardcoded at zero, which is pretty useless). Enable updating and logging it within redo(). Some thoughts need to go into this, as the limits can be quite operation/instrument specific.
• Add option to only calculate using good pixels, both as user perference and GUI checkbox (like #38).
• Add buttons to save/load parameter values (like #37).
• Figure out whether ejeschke/ginga#266 is really an issue for this plugin or not (probably not if user can save parameters to JSON files).
• Update example config file.
• Add usage info and screenshot to plugins.rst

In MultiImage, MIPick, or Pick, the box cannot be interacted with. The main image is always in pan mode. The one way I have found is to hit the 'd' key. This should bring up the distribution algorithm choosing, but instead allows moving and editing of the box.

It doesn't matter what mode is chosen: move, draw, or edit.

Notes

• With latest master of ginga (23Nov2015)
• OS X with trackpad

We might or might not need this. See https://trello.com/b/X5pIiZzj/dadf-sprint-psf-and-psf-kernel-tools for related discussions.

Move SurfBgRatio plugin from QUIP to stginga. Probably will also rename it to something more sensible like SNRCalc. Basically it calculates simple signal-to-noise ratio (SCI / ERR) and surface-background ratio (as defined by Ball), with the option to write the results to image header as keyword-value pairs.

When I load an image and draw an annulus, the X and Y values update, but not the Radius or Annulus Width boxes. Also, the Background Value box does not seem to change (not calculated). The log does not show any errors. The Subtract button remains grey throughout.

This may be user error, if I am not understanding the plugin operation correctly. I am using stginga commit 05e0777 with ginga commit 91b05b0a9e39f0fa9c3ac9f1589bc4640d91c15f.

Currently, the image data has been used as key. But, apparently image data is cache data and can disappear. This causes duplicates to appear. Need to key off something else...and learn about the cache system.

Comments @ejeschke?

Background value should be calculated only from good pixels (i.e., pixels marked as "good" in the associated DQ extension). If no good pixels found, set to zero.

To be more flexible, this should be configurable via ~/.ginga/plugin_BackgroundSub.cfg file, with default set to True. Maybe something like:

ignore_bad_pixels = True

Extend LineProfile local plugin (by subclassing) to also accept some kind of aperture (e.g., quadrant, circle, box, etc.). Some kind of statistics (e.g., mean) is to be performed for all pixels within the aperture for a given extension. And then the results are plotting across the ramps (i.e., time).

For the quadrant and time tags to work, JWST-specific assumptions are needed. Can probably make those configurable as well.

Originally brought up by @bhilbert4 #35.

Also see ejeschke/ginga#259.