Details
Undefined Description
We have been discussing the handling of multi-exposure visits in the butler and the handling of data ingest and we realize we need the camera to write us some more headers indicating the number of exposures requested in the takeImages command.
The takeImages command can be told how many images to take. We therefore need the camera to add the following headers (even if only one image requested).
- FIRSTSEQ: The sequence number of the first image taken.
- ENDSEQ: The expected end sequence number when all images are taken.
I don't think the headers need to have an "N out of M" component to them because I think we can work it out from SEQNUM, FIRSTSEQ and ENDSEQ and if we use the above headers they are fixed for each exposure for that takeImages command.
We understand that it is possible for the camera to abort taking data before all N images have been taken and that therefore ENDSEQ will not be correct. This is okay because it will be extremely rare. The prompt processing system will simply skip the visit if it sees data turning up with a new next_visit. The number is very useful though for the vast majority of occasions where it is correct.
All instruments should get these two new headers.
We are assuming that the observing script will implement multi-snap visits by calling takeImages once with a request for multiple images and not calling takeImages multiple times. If we are doing the latter we will need a way for the observing script to tell the camera relevant information such as "this is exposure 3 out of 5" and the camera can then work out the headers itself.
Attachments
Issue Links
Activity
Note, that the image visualization scripts must call takeImages with the given number of images for typical (e.g. 2x15 second) image sequences. If not the camera will not be able meet its allocated time budget.
Also note while providing n out of m can be implemented very quickly since the info is already provided, the FIRSTSEQ, ENDSEQ suggested in this ticket would require XML and code changes.
Tony Johnson
added a comment - - edited Note, that the image visualization scripts must call takeImages with the given number of images for typical (e.g. 2x15 second) image sequences. If not the camera will not be able meet its allocated time budget.
Also note while providing n out of m can be implemented very quickly since the info is already provided, the FIRSTSEQ, ENDSEQ suggested in this ticket would require XML and code changes. I was advocating FIRSTSEQ / ENDSEQ because the headers are fixed for all observations from that takeImages command and SEQNUM==ENDSEQ tells you you are done. Nothing needs to update the header during takeImages and you can set both immediately up front.
In the camera proposal from Tony Johnson it's not ideal that you can tell you've got to the end by having to say imageIndex + 1 == imagesInSequence. Being 0-based doesn't seem right to me.
Currently all of the image related events sent from the camersa to header service (and anyone else interested) have the following items:
<item>
<EFDB_Name>imagesInSequence</EFDB_Name
<Description>The total number of requested images in sequence</Description>
<IDL_Type>long</IDL_Type>
<Units>unitless</Units>
<Count>1</Count>
</item>
<item>
<EFDB_Name>imageIndex</EFDB_Name>
<Description>The zero based index number for this specific exposure within the sequence</Description
<IDL_Type>long</IDL_Type>
<Units>unitless</Units>
<Count>1</Count>
</item>
These items do not currently get written to the FITS file headers, either by CCS or by the header service, but adding them as header items should just be a matter of configuration.