6 November meeting

Data Management Camera-DM Visualization
#1

Agenda: Discussion of action items:

  • @tatianag, or other FF people: Document the FF algorithm that generates the browser image. Done
  • @tatianag: Find out if FF can do this. Done (I think)
  • @marshall and @tony_johnson specify the desired header keywords. Begun
  • @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).
  • @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.
  • @JJT: Sketch some typical user activities.
  • @tatianag: Show FF image browsing to Heather and Homer. Tatiana will send a pointer to a demo. Done

Minutes:

  • As @tatianag previously posted, FF supports blinking in “expanded mode”. One can select “WCS match” and “Auto play” from the menu. She showed a demo.
  • @victor_ren has just begun to look at the DS9 code. The images that @tony_johnson pointed to (also in @jjt’s Dropbox) do not have WCS headers, so we cannot yet study DS9’s behavior. With the proper headers (especially DATASEC) one can turn display of the overscan pixels on and off with the “Use DATASEC” true or false option.
  • Definition of the desired “Mosaic’ed” image header format requires one more meeting between @marshall and @tony_johnson. @gpdf is waiting for this, so he can give the format to the image simulation team. We want at least three WCS coordinate systems:
    ° Integer pixel coordinates, including and inter-device gaps, for engineering work, both with and without space for the overscan pixels.
    ° True x-y (i.e., with metrology) coordinates.
  • @GPDF suggests using the background image to show labeled HW region boundaries, as a visual aid for the user.

Action list:

  • @jjt: Begin the description of typical user interactions. (starting up, specifying images, posting results, etc.)
  • @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.
#2

Here is the link to the demo page. You can use the same technique to browse your raft images. (Except raft images in the dropbox do not have sky coordinates for coverage plot.)

#3

There are certain advantage of using firefly server internal communication. If we are using the server, we would not need to worry about the deployment in the end. Though I am not sure if it is the case that whether we are going to have multiple instances (or machine).

Currently I do not have concrete example of FF should behave like a server. However, I have some primitive thoughts.

  1. better information parsing scheme. Currently the information extraction is verbose and redundant. I hope there will be better method we could do for this. For one process to complete, we have to specify the input and output and we have to deal with the filesystem for both the input and output, and also parsing the input and output.

  2. state preservation. Each time the process is completely new so that we could not preserve information for the repetitive computation or (if possible) a continuation of series of commands (This is just my pure guess since I am not sure if there is a concrete case. The case I could think about is that if we are looking at the some anomaly of selected region, and we computed some data, and get the results back, the user might want to do some further computation on that data).

However, currently I feel the communication will be verbose and error prone. And since we haven’t settled the use case prototype, I think I might wait until all the needs settled and then move to firefly communication channel.

For this week, I was trying to implement with blinking functionality.
blink <box name> <im1_id> <im2_id> <interval ms> <blink times>
to initialise a blink
It could also do the following
blink <box name> <times> blink more times
And
blink <box name> stop to stop blinking.
The demo is on
http://lsst.cs.illinois.edu/static/index.html

19 February meeting
#4

About blink. Firefly supports blink functionality. As an example you can try to blink images from this wise search result. Use the diagonal errors at the upper right corner of an image viewer to bring the expanded view and then check “Auto Play” button.

As for the communication protocol, it will change. In my opinion for now we should be using existing communication channel to define some useful tasks on various selections (image, line, or point) and implement them in python (using astropy fits library to begin with). For example, one task could be finding all hot pixels (those with max flux) in the selected area and circle them. Or do a histogram on line selection. We can start with simple but useful tasks and then move to more complex.

Firefly does provide area statistics, which includes showing max flux pixel, but it is the first pixel it finds. If several pixels have flux=100000DN as in you sample raft images, it would show just one. You could show all of them, using regions.

I am sure when you do implement these tasks you’ll find things that you’d want to change or improve. This will make both of our teams move forward.

#5

Stuart (@marshall),

The image files that @tony_johnson pointed to do not have WCS coordinates. They are in my Dropbox, in a folder named “Tony Johnson’s images”. Do you have an MEF that includes a WCS in the header?

Jon