Is there a document describing the histogram of shutter open/close durations in each direction as measured during commissioning?
Ditto for image header keywords associated with the shutter? What is the reference clock (meaning the physical clock as well as timescale) associated with accurate timings of shutter motions? Do calibration images share the same clock?
Probably a data management question, but are times associated with events or moving objects detected in an image corrected for the motions/direction of the shutter?
Hi @rseaman, I can answer some of these in the context of the Data Preview 1 release.
There is no document, and no DP1 catalog, that contains the shutter open/close durations, no. The Visit and CcdVisit tables have exposure time start, midpoint, and duration, all for the fiducial center of the focal plane array in TAI.
The image headers (metadata) only have one shutter-related keyword, SHUTTIME, and it is the shutter exposure time (30 seconds for DP1). This is the case for visit and raw images and the calibration frames available as part of DP1.
Given that Rubin is perhaps not (or not yet) providing data products you need for your science goals, I’d be interested to hear a bit how these times and durations are used in your analysis and what would be most useful?
For LSSTComCam the shutter is very different design to that used for LSSTCam and the SHUTTIME header is the requested exposure time (matching EXPTIME). For LSSTCam the SHUTTIME is calculated from the shutter profile data and will be the actual exposure time. In both cameras the butler metadata reports the requested exposure time (since that is generally what people want to query for)
Also with respect to the future with LSSTCam instead of DP1 with LSSTComCam, we can say that detailed shutter motion/timing information is being captured and will be released along with raw data products in the future. The exact delivery mechanism is still being worked out (e.g., Butler datasets). Also in the future the Consolidated Database (ConsDB; DMTN-227) is the likely home of the model parameters for the shutter motion.
Thanks for the info. Like all good answers, they engender additional questions. Many of these might be addressed by linking to example FITS images or headers (doesn’t have to be real data). While I don’t expect that metadata handling will center on trusty old 80-char keywords, one imagines any imaging data delivered to users will have a FITS option with a minimum set of the usual keywords, right? No need to belabor that most user access will not be the equivalent of sending a tarball of MEF files. Pixels will be an option (eventually), right? These will have to stand on their own for basic purposes.
Which is to say that FITS headers (or whatever Rubin will deliver instead for basic pixel access), will have a few FITS standard keywords like: “exposure time start, midpoint, and duration, all for the fiducial center of the focal plane array in TAI”. Right?
A use case could be “give me FITS cutouts of all detections of 3I/ATLAS with timestamps and WCS info suitable for astrometric/photometric measurements”. There is certainly a cottage industry in remeasurements of imaging data from the ongoing surveys. Or larger FOVs for precovery searches.
Yes. We are still in construction but documenting the raw FITS and the FITS products is a construction deliverable.
That already works for the DP1 cutout service for visit and difference images. The co-adds do not yet have headers indicating the earliest and last observations to go into the coadd, although that will be available in the dataset provenance in the future.
For the LSSTCam cutout service it has been requested that, for the visit images and difference images, we update the time headers to indicate the time relevant for that part of the focal plane. Since we do not yet have the shutter profile calculation running in the pipelines (we have only just started looking at this) we cannot promise yet that DP2 will have this, although DR1 will.
We are required to allow you to download a FITS file and you can do that for DP1. You can use ObsTAP or SIA queries to return datalink URLs that allow files to be downloaded locally. This works with TOPCAT just fine.
Have you looked at the DP1 data? You will see that this information is in the FITS headers for visit and difference images.
Re. “Many of these might be addressed by linking to example FITS images or headers (doesn’t have to be real data) … one imagines any imaging data delivered to users will have a FITS option with a minimum set of the usual keywords … [and] pixels”, the answer to this is yes, the DP1 images provided to users do already have all of this.
Links to the high-level overview documentation for the deeply coadded and single-visit DP1 images, and their associated metadata, are below. Similar pages exist for the other image types, including raw DP1 images.
A link to view tutorials that demonstrate how to query for, retrieve, and interact with each type of DP1 image and their metadata is: 202. Images. That link goes to html versions of the executed notebooks, but executable versions (ipynb files) are available via the “Tutorials” drop-down menu when logged in to the RSP at data.lsst.cloud.
I’m going to mark this topic as solved but as always, please do open new topics for new questions any time.
Draft can be found at https://ctn-004.lsst.io – it has some problems (the types are wrong in places and there are missing comments) but hopefully it’s better than nothing at all and I will work on it some more when people are back off vacation.