Here is the action list from last week. Please add other agenda items, as desired.
@jjt: Begin the description of typical user interactions. (starting up, specifying images, posting results, etc.) DONE
@dyue2: Improve the “region statistics” function (e.g., to show hot pixels) as a first demo of functionality we’ll want to implement. This, as well as blinking (and other image math) and keystroke command selection, and other functions, are on Paul O’Connor’s first priority wish list (URL).
@victor_ren: Understand how DS9 does region display, to see how we can do it efficiently.
Notes from the meeting:
For the next year, only go to raft scale. Focal-plane scale images present a significant challenge that we can defer.
FF can do a “grid” method to display a mosaic image. It wasn’t clear to me that his allows as versatile e user interaction as a true image mosaic does. (e.g., selecting a region that spans grid elements),
A single extension CCD image no longer has information about the amplifier boundaries. How does DS9 deal with this?
There was some discussion of image preprocessing. What image preprocessing is done before image display.?
When mosaicing is done on the server it also generates a region boundary description (JSON?), for use by the client.
The client would get this this information by a separate request, so
the description file needs to be in the same place as the image file,
with an obvious name.
At the same time, the preprocessor could,precompute DS9-style region file, so that FF can display boundaries. -
Action:@victor_ren will generate the JSON file and learn about DS9 region files.
Action:@victor_ren will also generate single-extension CCD images that include the overscan regions (images w/o overscan already exist).
##Draft Description of User Interaction
(for discussion)
Starting up:
From the command line (with an optional image identifier), or
Double-click an app icon.
What the user sees at startup:
FF image display window.
If no image was specified, display a text message, or perhaps a clickable link to the image browser or to help.
FF tool bar. Will we need another, or is FF configurable?
Command line window, with a short message (e.g., “Type ’help’ for help.”)
One “results” window ??
Windows should be resizable. Should each user have a profile, with defaults?
What the user can do after startup:
Get help. The interface should be as standard as possible.
Perhaps a downloadable or interactive tutorial?
Get an image:
° Via browser. There may be more than one image library.
° Via URL or other specifier.
° Multiple image displays, separate or overlaid, must be allowed.
Open or close “results” windows.
With an image (or two) on the display:
Manipulate the image display
Pan, zoom, contrast (transfer function). If two images, do the same to both (if desired).
Image comparison: Subtraction, blink, etc.
Masking (e.g., of known bad spots).
Live (real-time) display of pixel values and hardware regions.
Modify the pixel aggregation algorithm (to modify zoom behavior)
Select regions of interest:
Hardware regions.
User definable (e.g., circle or square selected from toolbar)
Send commands (with parameters) to the server
Examples of parameters:
The ROI
Min/max pixel values to process.
Commands must give intelligible error messages (e.g., wrong # parameters)
The user should be able to specify the output window.
Command types:
Region statistics (variance, etc.)
Pixal lists (e.g., hot/dead)
Image comparisons (ratios, differences, etc.)
Generate documentation:
Save command results to files (on server or client)
For discussion related to wcs keys and relation to viewer features:
For both raft and CCD scale image viewing we would want:
1.) orientation:
- default to columns vertical on screen
- default to WCS- coordinate (1,1) at lower left of displayed image
- should be as though one is looking into the test-stand dewar from outside as opposed to from the detector plane looking out.
2.) Views:
- CCD:
- x,y in nominal pixel units (x parallel to serial register), w/overscan region displayed and switch for on/off of overscan coords and values
proposed
- x,y in nominal pixel units with overscan removed (call this one “trimmed”)
- Raft:
- x,y in nominal pixel units (x parallel to serial register), w/overscan region displayed and switch for on/off of overscan coords and values
- x,y in nominal pixel units with overscan removed (call this one “trimmed”)
- x,y in millimeter units reflecting as-built metrology (in the lab).
3.) Viewer capabilities to include (lots of other things, just calling out a few here)
- Ability to display 2+ sets of coords at a time (eg. CCD, amp, raft)
4.) Questions:
- naming conventions are needed:
- something like WCSNAME:PRIMARY for the wcs set that represents a whole “file” at whatever size we are using.
- and then WCSNAMEa:AMPLIFIER, WCSNAMEc:CCDTRIM, WCSNAMEd:CCDw/OSC, … this needs discussion
- will need to spec “wcsname, ctype?, cunit?, cdelti, pci_j, crpix?”, are there others (and datasec, detsec?)