cloomis, this is a pretty close start to what we want, but a couple of points:

• the data is used both during observation to monitor the guiding, and evaluate the sky level, etc. We absolutely want to get raw data, not a zeroed out background. 
• data is updated periodically in a display gui, but can also be saved as a "VGW" prefixed file by the SA or Operator dynamically. This all happens on the Gen2 side, so apart from sending the data at a periodic interval there are should be no impact to PFS side file operations.  VGW files are archived, and can be used for engineering purposes, troubleshooting, understanding guiding problems during observation at specific points, etc.
• a table HDU attached for metadata would be really useful, and we should itemize in this ticket what kinds of interesting metadata that could be attached, but we should not hold up the periodic transfer of the images waiting for particular items like final focus to be decided; I'm assuming that will also be available as a status item in gen2 as well, since that will be the preferred method for transmitting it in a telescope command for setting the Z position. VGW files can also collect status items when writing out files, so things can be added later from status items in Gen2 as needed.  

Each image is 1024 * 1024 * 2, correct?

Ideally, you would not need to actually write out these FITS images as files to disk on PFS side. We'd have to check the memory constraints, but what I imagine is an actor (or process) has an astropy or fitsio HDUList in memory and is simply taking the image buffers on a periodic basis and overwriting the same numpy arrays and maybe updating a few items in a table HDU, then grabbing the whole thing as a buffer and sending it over the network.  

Assuming these are 1x1 K 16 bit images, then with basic headers and a table HDU attached you are looking at something around 15-20MB in size in memory, being updated periodically.

If we decide to transfer them via file transfer, then we could also just use a small circular number of FITS files and sending a URL for Gen2 to copy them.

Interesting. We had not thought in those terms. I guess I'd say that if there is little real cost (threshold at ~1-2 s, maybe?) to using writing and transferring FITS files we should use them just to keep the number of maintained interfaces down.

But since this is use-once-then-discard data, sure. Use zmq or something? Do you have a preference?

[Aside: Apologies for the late comment: apparently I am not getting notified when a ticket I comment on is updated. I sort of assumed that Jira worked a bit like Github issues, but apparently not. I did check that I am a watcher on this ticket so I don't know what happened. If there is any suggestion for how to make that the default behavior in my settings, let me know.]

> I guess I'd say that if there is little real cost (threshold at ~1-2 s, maybe?) to using writing and transferring FITS files we should use them just to keep the number of maintained interfaces down.

> But since this is use-once-then-discard data, sure. Use zmq or something? Do you have a preference?

I agree.  And I think its best not to over-engineer something until we see a good reason for it.  So I suggest just writing a FITS file and notifying Gen2 of the path.  For notification, how about using the messaging hub? If making a client to that does not involve anything complicated (I'm assuming not) then we can just write a small, Gen2-side receiver that will listen on the channel/topic for "gen2-ag" (or whatever you want to call it) and then FTP/SFTP/SCP the file.

A test message to see if Eric sees Jira updates as a watcher.

I got a notification. 

eric cloomis Yoshida, Hiroshige: can this ticket be closed now?

I don't think we have heard back from @cloomis or @Yoshida. Also, it is not clear yet (to me) who is assigned this work and what actor it happens in.

My understanding is that if the AGCC actor writes out MEF files with images and a binary table extension that contains metrics of detected candidate guide stellar objects, they can be sent straightaway to Gen2. If the actual candidate guide stellar objects used and/or the field acquisition/guiding offsets determined are also needed, they can either be sent as MHS then Gen2 status values to be captured by the Gen2-side client for annotation, or the AG client, or likely another new actor, will have to add an another binary table extension with the information before image files are sent out to Gen2.

Following discussions during the ICS/PFI telecon 2020-10-16: this ticket can be closed.

eric cloomis Yoshida, Hiroshige still want this ticket – we are at the point where the details can and need to be pinned down. And we think we understand the system well enough to do that. The only significant changes from the original proposal are:

• do not cleverly compress the background. We will instead save the RICE-compressed background-subtracted image: the exact image that centroiding operates on.
• do use a visit- and sequence-based filename. Really, why not?

Since the nice VGW mechanism snapshots these files, I think we should stick with keeping everything in one file.

For implementation purposes, I think the agActor should write and announce the file: it knows the guide star catalog in use, the outputs from Kawanomoto-san's routines, and the final telescope and focus offsets. It is possible (likely) that the agccActor will write the image HDUs first, but that is an internal implementation detail. Once the file is finished, some "agDisplayFile" MHS keyword would get generated, which the gen2Actor would pick up on to generate a Gen2 status keyword, or whatever eric wants to see.

eric Can we agree on a naming convention for these? Is there something you already use? I am under the impression that the "VGW" names are only for the snapshotted file – is that true?

If there are no constraints, I'll suggest including the PFS visit and guider sequence number within that. Oh, say, pfsGuidingDisplay-%06d-%03d.fits.

Yoshida, Hiroshige cloomis: Discussing this with Moritani-san, I believe that this ticket, including file name convention, might already be covered by DAMD-138, and already implemented. Can you confirm?