24 November meeting

Because @jjt could not attend the Nov. 20 meeting, he and @tony_johnson, @marshall, and @gpdf met on Nov. 24. We didn’t want to have a two week gap.

Agenda: (taken from the Nov. 20 action items)

@jjt: I’d also like to discuss the implementation schedule. We have lots of parts, but we need to begin putting them together into a coherent whole. Perhaps my draft description of the user interaction from last week can serve as a starting point.

@jjt’s notes. Please edit as necessary.

At startup:

  • Tony J says: In test stands, one needs to get, by default, the last
    image taken. We need to know where to look for it.
    ° Perhaps the test stand sends a message with the newest image.
    ° The visualization tool needs to be able to see a list of images as well.
    ° Do we want an automatic display update mode? Pull or push? (we’ll probably want both)

  • What metadata is shown with the image table? (time takenn, CCD ID, etc.)

  • What back-end functionality does the FF browser provide? Tatiana says that there is a defined interface.
    a: One can write a search processor in JAVA and
    incorporate it into FF. Or,
    b: There is an interface that lets us launch a process that writes a table file, interpretable by FF. The search processor only knows what exists when it’s started up.

  • We need a standard location for the visualization GitHub repository. @tony_johnson will set something up. Perhaps in the existing data handling area. We’ll probably want an LSST/Camera area , but it doesn’t yet exist. Then /Visualization under that. Only two levels are allowed.

  • We should tiscuss this with Prossie Economu (sp?) (DM’s head of developer support at Tucson).

  • The students need to put working code in Github, so that Tony, et al., can look at, and run, it.

Action: (high priority): Have @dyue2 put the code in an accessible GitHub location (after Tony specifies it).

Discussion of other items from @jjt’s Draft Description of User Interaction:

  • Pixel masking is under development in FF: A bit mask plane that controls which pixels to display.

  • Live pixel display is done on mouse pause.

  • Resampling (pixel aggregation) is supported, but it’s a list of predefined functions. They can expose control, but it might be complicated to write new ones.

Action: Put the schedule, etc. as issues on GitHub.

  • Is there an accessible SUI schedule & roadmap? Yes, but probably not quite what we want. We should take @jjt’s list and prioritize the items.

  • FF has some predefined region shapes. A circle selector isn’t one, but it could be implemented by the client, using point selection and a user specified radius…

  • Control room displays: LSST is having difficulty architecting mountain/base/remote interactions and communications.

  • DAQ will not deliver a full interface at first, but enough to read data.

  • FF prefers to deal with files, but can accept streaming data, using the cache.