18 December meeting

Data Management Camera-DM Visualization
#1

Agenda::

Two discussion topics so far:

Client commands to the server
I hope that @victor_ren will have a draft specification to discuss. The command needs to specify

  • Verb
  • Image ID
  • Region(s)
  • Other parameters (verb-dependent).

Image Masking:

The image mask consists of an auxiliary image that matches, pixel by pixel, the primary image. Each mask pixel consists of a set of bits, each bit denoting a mask criterion that determines whether that pixel should participate in image display and image processing functions. That is, if criterion n is enabled, and if bit n of a particular pixel’s mask is set, then that pixel is disabled (or enabled?). More than one criterion can be enabled.

Questions:

  • It seems that some masking should be done by the display server (and command processor), but some should be done by the client. For example, when the display is zoomed in/out, the appropriate pixels should be masked. I doubt that we want a client/server transaction every time the user zooms the image. This raises a question, which is particularly pertinent for HW diagnostics:
    • When zoomed out, each display pixel corresponds to a set image pixels. Which mask pixel should control the display? I think the answer will depend on the information that the user wants to obtain. For example, when looking for hot or dead pixels, even one hot/dead pixel in a set should probably trigger the mask.
  • Is there any reason to consider an analog mask (ie, not simply enabling and disabling pixels)? Offhand, I can’t think of any use cases.

Comments:

  • We’ll need to maintain a list of mask criteria, available for enabling/disabling on the fly (by drop-down menu and/or command line).
  • If we want masks to be either enabling or disabling, we’ll need another data structure to control that. Use case: We may want sometimes to see the hot pixels and sometimes to suppress them.

Minutes:

Action: @victor_ren should move the command documentation to the visualization GitHub. Done. Documentation is here.
Comment: The JSON should be lists, not maps (to allow multiple keyword instances).

Action: @victor_ren and @jjt will verify correctness of JSON region file.

Action: @jjt will move his FITS images to FTP.

Action: @tatianag will discuss FF masking with colleagues. See her comment below.

Action: @tony_johnson will think about the image catalog interface.

Action: @marshall will make his FITS header utility accessible.

#2

Here is more information on how mask is displayed by Firefly.

Every mask bit is handled by a separate transparent image plane with color pixels representing the mask bit on. Those planes are overlaid on the original image.

Indeed, if you zoom out enough, a hot pixel can be “lost”. It will become visible again when you zoom in.

Trey has suggested a simple way to preserve a particular mask bit pixels on zoom-out. We can re-stretch/re-bin mask image on zoom, so that every mask pixel becomes n times bigger when we zoom image to 1/n of its original size. It should not be too hard to implement this behavior in Firefly.

To reiterate, we will do our best to support your use case. If you are loosing the data during visualization, we’ll sit together and figure out how to make it work.

#3

I think that we need to get the sensor testing folks involved in this discussion. I am not certain enough of the validity of my use case to know that it is worth the (probably nontrivial) Firefly effort to achieve the behavior that I am advocating.