Do we need a big FITS header for FF visualization? We can use @weiren2’s draft JSON file as a starting point.
Discuss “blink” functionality. Can we execute image functions in full-screen mode?
Functions associated with read_mouse (e.g., defining a circular region).
Notes:
We should investigate the possibility of putting displays (e.g., images, command entry, and plots/graphs) in separate browser windows. This will allow better use of space, especially on multiple displays.
Visualization is almost working at SLAC. There is some problem with JS-Python communication.
The PO for the “BNL-like” machines has been placed. Will be used for raft-scale images for now, but can support the full focal plane. The BNL HW exists.
@tony_johnson’s ingest code exists in a separate branch. It uses lots of I/O. The speed is OK if it’s in memory or SSD.
@jjt’s suggestion for the segment descriptors (if we need them) in the single-extension FITS header:
We have two constraints:
Header keywords can only contain eight characters
The header is a flat structure - every keyword must be unique.
I propose: ABCDscrr, where:
ABCD is the 4-character text that describes the keyword (e.g., “WDTH”).
s is one character that numbers the segment in the CCD (hexadecimal: 0-F).
c is one character that numbers the CCD in the raft (0-8).
rr is two characters that number the row/column of the raft (0-4 each).
I hope that four characters is sufficient to describe the keywords.
Alternatively:
There are 16921 = 3024 amplifiers in the focal plane. We could get away with encoding the amplifier identifier with a single 3-digit hexadecimal number (0-BCF). That would allow five text characters.
Here is my suggestion for FITS headers (written before reading Jon’s post). Note that using the HIERARCH keyword allows us to workaround the 8 character limit for FITS file keywords. Given that the visualization server will already have the image (and header) in memory, and already has a restful interface, it may make sense for it to also be able to generate the JSON required by the client.
Note also that a new branch exists within the visualization server where the code for sending and receiving images has been put. The new code is currently not linked to the code which notifies FireFly about availability of new images, but that is the next thing on my to do list.
Suggested FITS keywords for the FITS files generated for FireFly
DETSIZE: [1:12308, 1,12032] Total size of image, including any gaps between CCDs/Rafts
RAFTS: R99 Names of all rafts in images, in increasing X, Y order
HIERARCH R99.SENSORS: S00 S10 S20 S10 S11 S12 S20 S21 S22
HIERARCH R99.TYPE: E2V
HIERARCH R99.S00.ID: SR-CCD-001
HIERARCH R99.S00.REBID: SR-REB-002
<repeated for each sensor in raft>
HIEARCH E2V.SEGMENT: 16
HIEARCH E2V.SEGMENT00_DETSEC:
HIEARCH E2V.SEGMENT01 DATASEC:
<repeated for each segment within CCD>
[ had forgotten about HIERARCH. That allows this syntax (similar to @tony_johnson’s suggestion):
HIERARCH Any text Sij Ckl Rmn = value,
where:
i = 0-1 and j = 0-7 (row & column of the segment in the CCD)
k = 0-2 and l = 0-2 (row and column of the CCD in the raft)
l = 0-4 and m = 0-4 (row and column of the raft in the focal plane)
I don’t have a strong opinion. If the image server will generate the single-extension file, with complete headers, we (the visualization back-end) only need to create the JSON from it.
What is the constraint on mixing sensor types? Is each raft guaranteed to contain a single type? Given the electronics layout, I can imagine that the constraint will be only by row in the raft (each row is controlled by one acquisition board).
Each (science) raft will contain sensors of a single type. I think there are physical constraints (to do with spacers) which make it likely this constraint will not be violated – although people are always more creative than expected – but for now I think it is safe to assume that each raft will contain a single sensor type.