30 October meeting

Data Management Camera-DM Visualization
#1

Put agenda, discussion, minutes, and action items here.
Meeting will be at 2 PM CDT, on BlueJeans:

Minutes of the meeting:

We discussed real-time user interactions. One issue is to avoid excessive communication.

@gpdf lists three 3 scenarios:

  • When mouse is moving. Example: coordinate readout in realtime

  • When mouse is paused: Evaluate pixel value (from server). This is a
    bit more expensive.

  • Select a region: Invoke an action by clicking.

We need use cases.
Do we want, for example recompute a histogram in real-time as a line is dragged by the mouse (during mouse moving), rather than on mouse pause?

When is additional “zoom level” image data sent? This would enable more client side functionality for previously specified algorithms (eg, aperture photometry, or noise, or pixel min/max). FF enhancements of this sort are not likely before January, because they are busy refactoring FF to use more modern libraries (get rid of some Google code?).

Action:
a) @tatianag, or other FF people: Document the FF algorithm that generates the browser image.
An upgrade suggestion: Let the user select the algorithm. (eg, min or max pixel).
b) @tatianag: Find out if FF can do this.

Action: @marshall and @tony_johnson will work on specify the desired header keywords. @tony_johnson has begun this (a note in the community). None of us knows what the on-disk format will be, and what is the best way to preserve (for example) the amplifier locations in a single-extension mosaic-ed image. One possibility: Do the mosaic-ing (at browser level) during DAQ at BNL. Clicking on a spot pulls up the appropriate sensor-level image at full resolution.

Action: @victor_ren (and others) Find out how DS9 knows which extension the current mouse position is in. @victor_ren and the FF team will sit in on a demo by @marshall (and @tony_johnson).
What does DS9 do with overscans? We think that DS9 will reserve screen space, but the display can be suppressed - shown as black. Is that right?

Action: @dyue2: Is FF an adequate server, or do we need another? It will be instructive for the FF folks to know what functionality is desired.

Actions:
a) @JJT: Sketch some typical user activities How do they get started, find out where the data is, etc? How much is menu driven, how much is cmd line? Eg, should they browse a list of image files? What other UI features will the users want? Ask Heather and Homer for user input.
b) @tatianag: Show FF image browsing to Heather and Homer. Tatiana will send a pointer to a demo.

#2

Some items for the meeting:

  • @dyue2 is comparing the use of the Firefly communication channel with the third party one that he has been using for client-server communication. Discuss ± of each.
  • @dyue2 also receives an odd browser error. See: this post.
  • @victor_ren has created a focal-plane-scale FITS image (14 GB, uncompressed). I put it on Dropbox here. The header is very minimal - we should discuss the desired header information.
#3

Dingcheng, Victor, and all,

The new firefly release is available at github.

This week we found and fixed a major memory leak, which hopefully should fix the issues with Firefly running out of memory. Still I found that for working with 500MB files, it is best to use -Xms1g -Xmx4g options when starting Firefly with embedded Tomcat.

I am not sure you want to do server call on every mouse readout callback, but it is reasonable to do it on mouse pause.

Trey has modified the result data from XY mouse readout. Since the call to get the flux at mouse stop position is asynchronous, usually you would get two callbacks: one when the mouse is paused and the other when the flux value is retrieved. If you are only interested in the coordinates of the point where mouse has paused, use

if (data.pause) {
…
}

If you are interested in flux value, use

if (data.flux) {
…
}

I realized that on region selection and mouse readout we don’t pass a path to the fits file, just plot id. If the file was not rotated or cropped, it should be the same as the original file. In future we might want to get a way to get the whole plot state with the path to the image.

I’ve tested the timing for the python launcher, which uses astropy library to read the original fits (500mB raft image) on mouse pause and to return the flux at the mouse readout. It takes less that 300-500ms on my computer, which I think is acceptable for now.

The whole reason we wrote python task launcher is to allow you to extend firefly back end without having to maintain your own server. However if you do want to go with your own server, that’s fine too. Still you should aim for making your server stateless. And we should think how to make sure we are using the same file: Firefly does not expose its internals and always passes the encrypted paths to the client.

About setting your python environment. I am using conda (miniconda) to manage my python environment. LSST is using Anaconda, I believe.

As for violation of origin domain policy, make sure your static page comes from the same server for your remote calls. This policy is the reason why Firefly does all external service calls from the back end.

Tatiana

#4

I think it would be good if the mouse position was reported in terms of raft/ccd/amplifier coordinates as it moves, but this could be done using a single call back to the server to get the image geometry, and then doing all the on the fly computations entirely in the (javascript) client. This would require some thought, but I think would not be impossible to do.

I think we should really try to use the firefly provided communication path, because in the long run this will make installing and maintaining the server easier. Otherwise we will have to set up both firefly servers and separate python servers where ever we need to use firefly.

I am however concerned long-term about the statelessness of the python server, I think if we look at the use cases it will be hard to implement them all without any state preserved on the server side.

#5

Tony is right about maintaining multiple servers. However, I think the number might be three. Usually in with this type of multi-server deployment you end up putting an apache server in front. This protects from cross-site issues and gives more security control. It is not unusual to have multiple servers running but to the user it appears to be only one apache server.

We should consider this design decision carefully since we will be going from one server to three.

#6

I will not be able to make the meeting today since I will be heading back from the DESC meeting at Argonne. Last week I agreed to work with Stuart to make a raft level set of images in the format which they will come out from the CCS controlled test stands. Some work has been done on this, and can be found here:

The complete complete fits files are not yet ready, but they should be done early next week.

#7

Yes I agree, at SLAC we are switching to using nginx rather than Apache as a front-end to the tomcat servers. But I still would prefer to avoid proliferating too many different types of server for each camera firefly installation. We are likely to have several installations (at Brookhaven, in the clean room at SLAC, etc) so keeping things reasonably standard would be beneficial.