FAFF-REQ-001¶

Specification: The project shall provide an automated mechanism to trigger on-the-fly data analysis based on events.

Rationale: Telescope performance analysis will occur based on non-image based events (e.g. wind shake, or vibration sensor triggers).

Priority: ASAP

Current shortcomings: The only current tooling to monitor events is the Watcher. It exists to raise alarms but not to trigger processing of data that would then be displayed, or possibly trigger an alarm.

Applicable Use-cases: Automated Fault Report

Suggested Implementation to fulfil requirement: Create a “Catcher” CSC capability that holds “rules” and sends/monitors processing sent to the OCPS.

FAFF-REQ-002¶

Specification: The project shall provide a mechanism to trigger on-the-fly data analysis based on human selection.

Rationale: An analysis tool that is based on a trigger may also produce meaningful output for other use-cases. Having the ability for an operator to manually trigger the analysis+plot displays is useful for when the logic for the automated mechanism is not well captured.

Priority: ASAP

Current shortcomings: No current tooling to rapidly trigger an analysis manually. Requires the above requirement to be fulfilled.

Applicable Use-cases: Jitter (can trigger when image motion is observed or if other indicator may be present such as manually induced vibration or imbalance)

Suggested Implementation to fulfil requirement: Catcher-related analyses could be trigger manually from a LOVE based GUI.

FAFF-REQ-003¶

Specification: The project shall provide a service to perform the on-the-fly data processing associated with events and telemetry.

Rationale: For image related processing this is the OCPS. However, numerous analysis situations are not necessarily associated with images.

Priority: ASAP

Current shortcomings: In current design, can not run OCPS script without some image association, i.e., butler like (expects dataIds). This design could be modified if needed as not a fundamental technical limitation.

Applicable Use-cases: Jitter, Automated Fault Report

Suggested Implementation to fulfil requirement: Create a “Catcher” CSC that evaluates user-defined conditions and launches analysis “scripts” when the condition is met. This includes the ability that the script can command the OCPS.

FAFF-REQ-004¶

Specification: The project shall provide a mechanism to monitor the outputs of on-the-fly data processing.

Rationale: If the data-processing yields and interesting result, a “service” needs to monitor this and be able to act accordingly.

Priority: 1

Current shortcomings: This may be possible using the Watcher, but requires a more detailed look as it was not an original use-case.

Applicable Use-cases: All

Suggested Implementation to fulfil requirement: The Catcher CSC can do monitoring, but a LOVE GUI will be required to display the status.

FAFF-REQ-006¶

Specification: The project shall provide a mechanism to alert operators when a on-the-fly data-processing produces an interesting result.

Rationale: If the data-processing yields and interesting result, a “service” needs to monitor this and be able to act accordingly. Ideally, the alert should provide a link or single-click mechanism to see that result.

Priority: 1

Current shortcomings: This may be possible using the Watcher, but requires a more detailed look as it was not an original use-case.

Applicable Use-cases: Jitter

Suggested Implementation to fulfil requirement: Catcher publishes event which is seen by the Watcher, then alerts the user. Or a better solution might be to have the catcher be able to alert, like the watcher can but with increased functionality.

FAFF-REQ-007¶

Specification: The project shall provide a GUI to display information about finished and running tasks.

Rationale: The watcher in it’s current implementation only allows a user to acknowledge it and then the task/alert is complete. This is not sufficient for the “Catcher” as it needs to display results/links as well. Furthermore, that result should persist such that if a new result comes in the previous one is not over-written.

Priority: 1

Current shortcomings: N/A

Applicable Use-cases: Jitter

Suggested Implementation to fulfil requirement: Catcher GUI exists and reports the recent results of tasks.

FAFF-REQ-012¶

Specification: The display tool shall support the rapid alignment of images based on WCS and pixel coordinates.

Rationale: Suggested from DMTN-126. Useful for comparing illumination patterns, effects of offsets etc.

Priority: 2

Current shortcomings: Unsupported, image rotation is not yet supported FAFF-REQ-019 is the prerequisite

Applicable Use-cases:

Suggested implementation to fulfill requirement:

FAFF-REQ-013¶

Specification: The display tool shall report true pixel values in ADU.

Rationale: Needed for rapid identification of flux levels (e.g. flats, sky flats, etc)

Priority: ASAP

Current shortcomings: Planned but not yet implemented

Applicable Use-cases: Generic image inspection, flat fields etc

Suggested Implementation to fulfill requirement: When he mouse is moved over the image:

• Display the Raft/CCD/Amplifier segment/ and pixel coord within the segment, as well as the absolute coordinate within the focal-plane
• Display the RA/DEC corresponding to the position. This will require the image display to get the RA/DEC from the header service. The initial implementation will not apply any corrections for optical distortions or focal-plane CCD positioning anomalies, although this might be added in future if needed
• Display the (RGB) pixel value and the raw pixel value in ADU units for the selected pixel.

The first two items will be calculated within the browser, so will be very fast. Capturing the raw pixel value requires going back to the server to get the raw data at the given coordinates, so will have some lag as the mouse is moved.

FAFF-REQ-015¶

Specification: The display tool shall allow for dynamic adjustment of the image display parameters: e.g. scale and stretch.

Rationale: The display parameters are very important and vary depending on use case. In some cases, it’s important to be able to push as far into the noise as possible to see faint objects/structures. Other times it is more important to see bright or extended features in the images. It is difficult for most people to guess at the appropriate values for these parameters, therefore, it’s important to have a dynamic way for users to adjust the parameters without having a lot of user interface overhead. DS9 handles this by allowing the user to adjust by holding a mouse button and dragging the mouse in two axes. This is not a recommendation for the implementation, but an example of another implementation that has been successful at implementing this feature.

Priority: 1

Current shortcomings: First cut at scaling options now implemented, but not deployed.

Applicable Use-cases: High-contrast feature identification

Suggested Implementation to fulfill requirement: There is concern that implementation could be difficult in a client/server environment. To get a snappy experience would require some new features (if it’s even possible). We suggest a 2-phase approach for implementation, first with scale+stretch functionality then with the user-scrolling (etc).

FAFF-REQ-016¶

Specification: The display tool shall provide a mechanism to provide the information required to do a retrieval of information from a butler in another window in a rapid fashion.

Explanation: During the 2021-11-23 meeting it was agreed that many people will want to look at information for a specific image that they’ll be looking at in the display tool. This will require extracting the obsID and other information in order to do a {{butler.get}}. This requirement is to put functionality in the camera visualization tool that will essentially make that information transfer really quick (e.g. a button to copy the python syntax for the butler call directly to the clipboard)

Rationale:

Priority:

Current shortcomings: Not implemented

Applicable Use-cases:

Suggested Implementation to fulfill requirement: Create a “button” that copies the ascii string to make the python dictionary for a dataId to the clipboard.

FAFF-REQ-018¶

Specification: Ability to smooth the image using different algorithms.

Rationale: This was mentioned as a requirement in :DMTN-126` (sec. 4.9).

Priority: 2 (TBR)

Current shortcomings: Not implemented

Applicable Use-cases:

Suggested Implementation to fulfill requirement: Supply a list of supported kernels/algorithms. Should imply a constraint that the filter must be able to run in X (TBR) seconds. Examples could include boxcar smoothing. This is very fast to do for some filters if you do it in Fourier space, with the caveat, you have to ignore mask planes, etc.

FAFF-REQ-019¶

Specification: Ability to rotate image and show a compass

Rationale: This is useful for image orientation on the sky (North up, East Right is the standard).

Priority: 1 (TBR, not mission critical so could be seen as a 3)

Current shortcomings: Rotation available but not turned on. Unsure about a flip.

Applicable Use-cases:

Suggested Implementation to fulfill requirement: Provide a list of rotations (0, 90, 180, -90), then a N up, then a, “custom” option.

FAFF-REQ-027¶

Specification: Measurement between two points on images. This includes in RA/Dec, delta-angle, or in pixels.

Rationale: It is very hard to gauge scale on images because the objects in them are frequently self similar at multiple scales. Converting pixels scale (even if you know it) to distance is both tricky and error prone.

Priority: 3 (A Bokeh App would get get us most of the way there)

Current shortcomings: WCS Solutions are discontinuous, unsure how this would manifest across multiple sensors/rafts.

Applicable Use-cases:

Suggested Implementation to fulfill requirement: A tool in the menu bar that would allow the user to click a point and drag to another point on the image. The distance (configured through the menu) would be displayed along with the line on the image between the two points.

FAFF-REQ-028¶

Specification: Display the Equatorial Coordinate grid over the image (other coordinate systems could be supported). The grid should be (automatically) adaptive so that it shows about the right scale as the user zooms in and out.

Rationale: As with measurement (FAFF-REQ-028) estimation of the scale of things on images is very difficult by eye. Having a reference grid is useful in putting the distribution of sources on images in context.

Priority: 1 (ComCam)

Current shortcomings: Not implemented. FAFF-REQ-019 is a prerequisite.

Applicable Use-cases:

Suggested Implementation to fulfill requirement: Draw a grid on top of the image to represent the coordinate system. It will not be rectilinear. The grid lines should be labeled so that they can be identified both by what axis of the coordinate system they are as well as which coordinate value each line represents. Would be nice to have the ability for a user to be able to adjust this.

FAFF-REQ-029¶

Specification: Display a trace of the pixel values along a line, at arbitrary angle, specified by the user.

Rationale: Even with the ability to finely control the contrast and stretch of the color table, it is still frequently difficult to determine the detailed shape of profiles in an image. An example is that it is useful to have an estimate of the seeing (e.g. FWHM) of an image. This can be estimated from the image alone, but being able to draw a trace through the center of a bright, non-saturated star allows the user to read off the value directly from the plot. The line needs to be made at arbitrary angle to avoid other intervening objects in the image.

Priority: 3 (nice to have, covered largely by Bokeh functionality)

Current shortcomings:

Applicable Use-cases:

Suggested Implementation to fulfill requirement: A tool available in the menu would allow a user to choose one point on the image and drag a line to another point on the image. A plot window would then be populated by the pixel values of all pixels touched by the line as a function of distance along the line. The units of the pixel values should be the values in the image.

FAFF-REQ-030¶

Specification: The display tool should use a lossless image format to display pixel data

Rationale: Pixel data may not be exact using jpg due to possible losses. Suggestion is to use png, which is a lossless format.

Priority: 1

Current shortcomings: Currently the image visualization backend sends jpg images to the web browser. jpeg is not a lossless format, so we would like to try sending png images instead (which are lossless).

Applicable Use-cases:

Suggested Implementation to fulfill requirement: Already built-in to cantaloupe/open-seadragon. It is unclear whether this will have a significant visual impact, but it has been already investigated to be possible and appears easy to try.

Comments/Discussion:

FAFF-REQ-031¶

Specification: The display tool shall allow individual user logins to enable user specific preferences.

Rationale: To support user preferences (e.g. user would like to display images using the bb color scheme, or user wants to mark images as favorites so I can return to them later) and to support remote control of the image display tool (required by several other requirements on this page) it is required that individual users to be able to login.

Priority: 1

Current shortcomings: Currently the image visualization tool is purely read-only and does not require any user login.

Applicable Use-cases:

Suggested Implementation to fulfill requirement: Initially we will allow github login, since this is easy to implement and is usable by anyone with a github account. One day we may support IPA login on the summit. This has already been implemented on other CCS web applications. Once logged in users will be able to access their jwt token, which when passed to other tools will authorize them for remote control of the display.

FAFF-REQ-032¶

Specification: Add additional info to camera image database.

Rationale: Currently the camera maintains a simple image database for every image taken. This currently contains minimal information, including ObsId, Image Type, Test Type, Run Number, Exposure time, Dark time, Rafts read out, location of FITS files. There are several things which could usefully be added to this database, including: Group ID (used for summit data taking), Installed Filter(s), RA and DEC of image (needed for other requirements on this page). This information is used by the image browser, and is displayed in the header of the image visualization tool. The image database is also used for tracking which images are in the 2-day store, and will be used for tracking when DM notifies the camera that the images have been archived and are eligible for removal from the 2-day store.

Priority: 1

Current shortcomings: Not implemented.

Applicable Use-cases:

Suggested Implementation to fulfill requirement: A simple camera image database already exists. Ideally, this would be combined/coordinated with other similar databases being developed by T&S (for LOVE) and perhaps by DM (see :ref:`Other Findings and Recommendations`_)

FAFF-REQ-033¶

Specification: Image viewer shall be able to directly read data from the DAQ 2-day store.

Rationale: The lack of this is currently the limiting factor on performance with LSSTCam.

Priority: 2

Current shortcomings: Currently, the camera image visualization tool works by reading FITS files generated from the DAQ by CCS. This works fairly well for AuxTel and ComCam but is a limiting factor on performance for the full camera.

Applicable Use-cases:

Suggested Implementation to fulfill requirement: An interface has been developed which allows the data to be extracted directly from the DAQ 2-day store, without ever touching disk. This works and is fast, but has not yet been put into production due to the need to study what impact if any it has on DAQ performance.

FAFF-REQ-034¶

Specification: Camera shall send image thumbnails via SAL after each image

Rationale:

Priority: 2

Current shortcomings: Some time ago T+S site requested that the camera deliver thumbnails of images via SAL. The appropriate events were defined at the camera XML level, but have not yet been filled in.

Applicable Use-cases:

Suggested Implementation to fulfill requirement: The camera image visualization tool is already capable of delivering such thumbnails. However, the code to send them automatically after each image is currently missing.

FAFF-REQ-035¶

Specification: Camera shall support a mode that only displays the wavefront sensing sensors.

Rationale: This is for commissioning purposes

Priority: 2

Current shortcomings: Some time ago T&S site requested that the camera deliver thumbnails of images via SAL. The appropriate events were defined at the camera XML level, but have not yet been filled in.

Applicable Use-cases: Active Optics

Suggested Implementation to fulfill requirement: