Agenda:
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.