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.