13 November meeting


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).
  • @marshall and @tony_johnson: Finish the MEF header definition.
  • @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.?

@gpdf suggests:

  • 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).

Action: @marshall and @tony_johnson will work on the header format.

In the longer term, we need to think about a hierarchical image format.

##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)
    • Write annotations.
    • Save image files (eg, jpeg).

Sorry I am going to miss the meeting again as I have parent-teacher conferences today. I will chat with Stuart later to get an update on the meeting.


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
- 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?)

See this confluence page for background:

I don’t have access to that confluence page. FITS-WCS does allow you to specify multiple WCS systems in a single header.

Do you have a SLAC Confluence account at all?

That’s exactly what Stuart is proposing… to have the different flavors of mosaicing mapped to the different “lettered” WCSes.

Nope. Didn’t know that it existed.