Skip to end of metadata
Go to start of metadata




  • Go through one use case and identify the functions needed for it

Discussion items

  • Search the images and object tables (source tables) at the same time
  • Meta data for deep coadds are useful at some situations
  • From one deep coadd, we should be able to get all the visit images that go into making the coadd
  • Try not to close any display view/tab/window because there is something to add to the display, Ciardi would rather close it himself, side by side view of multiple data is highly desired
  • Context background image
    • Images to be used (LSST, 2MASS, WISE, ...), consider WWT capabilities as one option, Healpix all sky images from other center?
    • Context background image to be three-color image for better structure information
    • LSST Chi-squared monochrome coadded images for 6 bands, good to see the structure of the sky in 6 bands (could be used to background image)
  • LSST coverage/depth map
  • interaction between the BG image and the object/source table
    • click on the image, (w/o the sources overlaid), highlight the object (if exists) ob the source table
  • Time series
    • one object selected, get all the visit images cutouts for this point, get the cached ones first, then warn users that the other images will take XXX minutes/hours
      • could we know before hand from the source list that the corresponding image is on disk/tape?
      • organization of the images could affect the speed of getting those cutout 
      • movie play, 250 - 1500 - 15000 single visit images for each filter
    • The stack of images should be stretched the same way, same algorithm and same range
    • FITS meta should have all the images we need to do the proper stretch over the stack of images
  • Questions:
    • Calibrated visit images, what has been done to them?
    • Could we organize the images by region, to make the cutout fast?
    • Will LSST produce Chi-squared monochrome coadded images for 6 bands
    • Which table records the relationship between deep coadd image and the visit images that are used to make the deep coadd?
  • Firefly open API for plugins (to support data analysis performed with LSST data)
    • Firefly can see all the available plugins to display for user to select from
    • user can plug in his own algorithm to do certain thing 
    • user can publish his own plugin for other users:  in git, in his own workspace, 
    • a set of parameters for plugins
    • Firefly can detect the parameters needed for the plugin, and then try to supply ways to gather those data
  • XY plot
    • needs error bars


context background imageload an image to be used as background image

position: the center position of the image

size: size of the image, unit degree

mission/project: that produced the image, like 2MASS, WISE, SDSS, LSST

  • a list of missions will be supplied
  • SUI will supply default image according to size

Action items



  1. Are we ever going to have 15,000 single-filter images of the same spot?  5 times a night every night in the same filter?  That's some deep-drilling field...

    The plan is definitely to organize data on tape in spatial order, not time order.  (It helps that we have dozens of drives.)  We'd also like to avoid tape if we can, but budget realities may not allow it.  Answering whether a file is on disk or tape is up to the storage manager; exposing that via the Butler is not currently anticipated, but it could be exposed via the metaserv API.

    For two perspectives on what is done to raw images to turn them into calibrated images, see Level 2 Calibrated Exposure Processing and Visit Processing.  If calibrated images are stored (which is not currently in the baseline), they would be organized spatially.  The raw images are organized spatially (see above), so the regeneration of calibrated images would also be spatially organized.

    1. About the "15,000": it was a combination of a probably overly conservative unstated assumption and a note-taking oversight, I think.

      The normal case, of course, is the SRD spec of the number of images across all filters required in the standard survey (SRD Table 23, Nv1) - 825 - and the estimate for how this will break down as a function of filter band (SRD Table 24, non-normative) - between 56 in u and 184 in r and i.

      The "1,500" number is a wild guess at a high number for the number of times certain small regions on the sky might be covered in the standard survey in all filters if a low percentage of dither were used (leading to no overlap at standard field centers and deep overlap at field edges).  This number was then roughly multiplied by 10 for deep drilling.  The resulting 15,000 was clearly not per filter.  It's also entirely unclear what the adjacent-fields situation for deep drilling may be, so propagation of the conservative x2 overlap factor may be inapplicable.

      (Please be aware that the notes from these design meetings are raw live-typing notes.)

  2. Will LSST produce Chi-squared monochrome coadded images for 6 bands

    See the Data Products Definition Document for the current list.  We do have a deep coadd for each band, but I don't think it's defined as being chi-squared.

    Which table records the relationship between deep coadd image and the visit images that are used to make the deep coadd?

    This information has not been ingested in past Data Challenges, so the short answer is "None" for currently-available data.  I believe the information is available from the CoaddPsf object and the coadd FITS headers.  Of course we need to make this information available in the production system. It's a good point that the current baseline schema as loaded into the schema browser only has this information in provenance tables (and doesn't have any coadd metadata available in tables).

    1. The reference to a "chi-squared" coadd in our notes is to the "M" coadd from the DPDD (p. 35, section 5.2), which is synthesized from multiple bands.  This is the key coadd used for the deepest detections, as I understand it, and the note-taker wished to confirm that it is indeed planned to be retained as a data product.

      1. It occurs to me that the image access API needs to provide for the selection of template coadds by airmass.  I guess that requires a query interface to determine the available airmasses.  Presumably that list could vary as a function of location on the sky and template epoch.

      2. The deep multi-band coadd, as well as one deep coadd per band, is called out on page 50 (section 5.4.3) as being kept indefinitely and made available to the users.  If that's what you want, you've got it (smile).