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
- Image ID
- Other parameters (verb-dependent).
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.
- 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.
- 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.
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.