2017_01_06 visualization meeting

Data Management Camera-DM Visualization
#1

Bluejeans: 107541143
UIUC people meet in Loomis

Agenda:

  • UIUC status

  • Image repository{

  • We (UIUC and IPAC) need a set of distinct images (real or simulated), to test some functionality (eg, blinking and display latest image.)

  • We want both CCD- and raft-scale images.

  • We need to choose a header format of single-extension images.

  • Displayable images, with and without overscan.

  • Draft of the Visualization Concept of Operations document. (MS Word)

Notes:

  • UIUC development code is operational. Install it from the development branch. User access is via http://lsst.cs.illinois.edu:8080/static/index.html . Please run it and comment.

  • Action: The SW version number should be displayed. Done (upper left corner of browser window).

  • To Consider: We’ll have more control over window sizes if we put each box and viewer in a separate browser tab or window.

  • SLAC status:

  • @marshall has multi-screen operation going in IR-2 (a lab at SLAC).

  • Action: @tony_johnson will get images this coming week (with and w/o overscan).

  • Action: @weiren2 will use the FITS headers to determine what region the mouse is in (including data/overscan), for display with the read_mouse command.

  • Action: @jjt, @gpdf, and @xiuqin will compare the Camera and DM OpsCon documents. The goal is to reduce redundant SW development.

  • LSST Stack:

  • The Community support category sometimes has threads for LSST stack issues. See @tatianag’s post for some other useful links.

  • People with expertise: @heather999 (Heather Kelly: installation using Conda) and @jchiang (Jim Chiang, an experienced user). Installation is complicated by environment configuration and package installation.

  • There will be a meeting at BNL in March. @tony_johnson and @marshall will install and demo the visualization SW then.

  • These meeting times may have to begin a bit earlier (or move to a different time) due to a conflict with the I&T SW meeting.

#2

##Notes from meetings with students:

2017_01_02 meeting notes:

hot_pixel does not work in the :8080 version.
It does in the default (:80) version.
I think the BE process never terminates. I am not selecting a large region (50x50).

chart understands nbins, but not the min and max parameters. (a BE issue)
Axis titles are not supported, yet.
The chart appears at the top of the window, so the X that deletes it is out of the window. I have to drag the chart to make it visible. (fixed)

Command entry from the FF toolbar works nicely. Is it possible to recall the last command (so parameters can be edited)?

read_mouse works nicely. Now, we want to be able to use the segment name as a region parameter for commands.

Short term projects:

  • Everyone:

  • Improve documentation. Make sure every command appears in the help file.

  • Improve error responses.

  • @ywang:

  • Add adjustable min,max limits to histograms, with underflow and
    overflow bins.

  • Make the second moment calculation work on any specified region.

  • @weiren2

  • Implement named regions, perhaps with this syntax: (Name ) .
    In order for an algorithm to process a region, the name
    (e.g., Segment05) needs to be turned into pixels (perhaps by converting it to (rect x1,y1,x2,y2) syntax.

  • @jbpagliuco :

  • What kinds of annotations (e.g., text) does FF let you put on a graph?

2017_01_04 meeting notes:

  • For @jbpagliuco:
    When read_mouse is enabled, the cursor position and HW region (amplifier) is displayed. We want to be able to pass the position and region to the toolbar, and to the command window, so the region name (and, perhaps, the cursor location) can be used as command parameters.

  • For @jjt and others: Understand the FF graph command options. For example, it would be good to denote underflow and overflow histogram bins by giving them a different color. Here (1, 2, 3) are some documentation links. We may need to ask Tatiana for help.

FYI: A copy of (part of) a BNL email, discussing some sensor issues we can monitor:

  • Bias drift (Paul O’Connor):
    Offsets in bias frames drift over time for several amplifiers (1,3,5,7 - so odd numbers on one half). variations in the gain may be responsible. this was causing problems for the production testing by overestimating QE. quite likely that his problem is related to a different feature of some e2v sensors when serials should be running during exposures to achieve stable performance (discussed by Pierre Antilogus in Dec) - serials are idle in bias frames.

  • Saturation on e2v device (Pierre Antilogus):
    further investigated behavior of an e2v sensor close to saturation. looked at the PTC and pixel correlations. confirmed that the two sensor halves behave differently perhaps due to how the clock phases are applied to the gates in the middle. this behavior also depends on the clock overlaps (better with overlaps). remember that long time ago we concluded that no overlaps is better for tearing so we should investigate the parameter space to optimize for both effects.