Date: Mon, 17 Dec 2001 14:40:34 -0500 (EST) From: Bill Sparks Subject: [Fwd: SHARE] To: gak@stsci.edu Cc: sparks@stsci.edu MIME-Version: 1.0 Content-MD5: BvF7fCtPuJ6VYxWOwDJhVA== Gerry, FYI here is an attempt to place the image combination material into the template you sent around. I have not altered what follows the template, nor have I had any feedback yet. I did send it to a few people that are interested in this issue. Cheers Bill ----------------------------------------------------------------------- Assumptions ----------- Describe aspects of the system that might not be obvious (or might not yet exist) that you feel are necessary to proceed with the implementation discussed below. An example might be that image combination assumes that the WCS in the image header has been fixed to some accuracy. If corrected WCS are available, SHARE item 1, then may avoid image registration step. We assume the OTFR paradigm that a re-run always gives better answers and hence no gain by storing information from earlier processing, such as cosmic ray locations or image offsets. Required Decisions ------------------ Allow users to set parameters in OTFR, or not. Choose software environment(s) for development work, e.g. pyraf, stsdas, Web... Algorithm choices; to be based on experience. >>cosmic rays >>other data quality >>registration >>flux scaling >>background level >>resampling technique Suite of data to be considered as available. HST only, or include Sloan, Chandra etc. Min and Max Goals ----------------- Most of our suggestions have a wide range of possible implementation. Set some min and max goals. For example, for spectral combination, the min goal is to be able to combine spectra that were intended to be combined from the start (e.g., a dithered observation set). The max goal might be to combine all available spectra for a given location/target on the sky. Minimum goal: complete current upgrade path for PyDrizzle. This will allow retrieval of sets of images from archive with offline image combination and parameter adjustment. Maximum goal: select set of images using archive tools (e.g. VTT) and retrieve fully combined single output image according to specified parameters that may differ from pipeline default. Fraction of community affected: These goals potentially allow access to a very versatile capability and could be of interest to a very large fraction of the community (anyone who works on images, essentially). Implementation Plan ------------------- Develop cosmic ray and other blemish/data quality identification module Develop image registration module Determine algorithm for image flux scaling Develop technique for image background or bias difference estimation Hence construct association table: Provide corrections to image locations and orientations Provide image flux scaling Provide image background offsets Allow user input of desired parameters for image combination and resampling (the Maximum Goal could be pursued without this, however its utility would be greatly diminished.) If non-HST data allowed, effort needed to ensure compatibility. Execute PyDrizzle or similar software to perform image combination. If "drizzle" not chosen, requires implementation of new replacement. Required Resources ------------------ - For Min Goals SSG resources to complete development of PyDrizzle and extend beyond current highest priority items. Flux scaling and background level offsets are not in current high priority implementation plan. Without module to determine flux and background, but enabled within association table, approx 0.25 FTE SSG programmer. With module development for flux scaling and background level determination, additional approx 0.25 SSG programmer plus instrument scientist prototyping and testing 0.25 FTE (Cf. NICMOS pedestal effort). - For Max Goals Pipeline to allow parameter setting by users >>OPUS/OTFR group Module development for: Cosmic ray detection and algorithms >>Single image option >>Iterative processing within pipeline environment (i.e. self contained within the group of images selected for retrieval) >>Use of external reference data such as additional images at some location, or a pre-screeened dataset, Comment: the first two of these appear realistic and tractable to me. The latter does not and is inconsistent with OTFR paradigm. Image registration determination Flux scaling Background estimation >>Develop expertise within IDT, GOODS and elsewhere and enable SSG to build on that expertise to integrate software tools in chosen environement and subsequently pipeline. Approx 1 FTE SSG programmer (two years work at 50% level) plus high degree of instrument scientist support. Construction of association table at retrieval stage >>StarView group Time Scales (for min and max goals) ----------------------------------- - For Min Goals Spring 2003 for completion. - For Max Goals Mid to late 2004: requires experience of working with large ACS datasets both technically, the images themselves, and system, retrieval and processing of such using OTFR. ----------------------------------------------------------------------- ================ Combining Images ================ Description: This archival capability would allow users to combine images that are offset with respect to one another, creating a single output image (i.e., doing drizzle on-the-fly). It includes relative registration between images, combining images that are offset by relatively small amounts, and also potentially the creation of much larger mosaiced images from pointings that are offset by scales comparable to that of the detector itself. Science Case: The large majority of long-exposure HST images are split into two or more exposures in order to facilitate the removal of cosmic rays, and furthermore many programs make use of dithering to move the objects around on the detectors, not only alleviating the effect of hot pixels but also in some cases improving the PSF sampling through the use of non-integral pixel offsets. Such techniques are already commonplace with WFPC2 and STIS, and is expected to be the norm for NICMOS and ACS observations. However, the archive currently offers only limited capability for combining separate CR-SPLIT images, and no current capability for combining dithered exposures. Yet many of the steps involved in combining dithered images are repetitive and time-intensive and can potentially be automated. Furthermore, steps that still currently involve human iteration (such as checking image registration) may also be amenable to automation using different parameters for different classes of images (some examples of image categories may include sparse extragalactic fields, dense stellar regions, or extended bright diffuse emission across the field). Unique STScI Capability: STScI has the ability to maintain up-to-date information on geometric distortion, image pointing information (in the form of jitter files and other telemetry information). Drawbacks: Although many steps in combining images using "drizzle" can now be automated, there still remains a need for manual intervention/iteration in some cases, and at a minimum there is a need for observers to check that the images have been combined correctly. Furthermore, the parameters for cross-correlation and combination must often be fine-tuned according to the nature of the images themselves (for example, depending upon whether there are many bright stars or only a few faint diffuse objects) and care would need to be taken in generalizing the algorithm to deal with such different types of images in a way that will still provide useful results. =============================================================================== >>> If corrected WCS are available, SHARE item 1, then task is significantly more straightforward. 1. More details on the current situation (a) In the pipeline, calacs >>process an associated set of images into a single output image using calacs and pydrizzle. (b) outside the pipeline >>download a set of (non-associated) images into a subdirectory from the archive. >>run BuildAsn to generate an association table for these data >>run PyDrizzle to combine the images into a single output. The current implementation does not check the image registration: it uses the WCS information in the image header plus a supporting reference file, the IDCTAB, that describes the instruments geometry. IDCTABS exist for ACS, STIS and WFPC2. If the image registrations are known, however, a correction can be given as part of the association table (delta RA, delta Dec and delta Orientat columns) and pydrizzle will adjust the drizzle parameters accordingly. It is also possible, currently under test, to use an object catalogue to measure positions on the input RAW images, to precalculate RA and Dec offsets between images using the same geometrical tools that pydrizzle uses. Hence you do not have to actually run drizzle twice to adjust positions. 2. Caveats The initial pipeline implementation uses a conservative set of drizzle parameters, although in principle you may use essentially the full drizzle parameter set offline. In addition to tweaking image positions, it is desirable to tweak image backgrounds also. Images with different filters may be combined if an appropriate scaling or weighting scheme can be selected. Presumably there are a number of options depending on the scientific application. E.g. maximizing S/N would offer one such weighting/scaling scheme. The PHOTFLAM keyword that converts count rate to flux density could provide a good starting point for such weightings. (Pydrizzle can already combine images from different instruments in principle, since the IDCTAB is specified by each individual input image. This has not been tested.) Pydrizzle can examine a data quality array and reject pixels from the drizzle combination. However under current implementations the ability to identify and eliminate cosmic rays is very limited. If a CR-SPLIT was used, then it is processed to reject cosmic rays and the cr-rejected image is passed as input to pydrizzle. Establishing reliable data quality arrays is critical to image combination, if starting with raw data. For ACS, we will examine the possibility of single image cosmic ray identification once we have some real data. Alternatively, iterative schemes could be used where a set of images are drizzled onto separate outputs then median combined to provide a first guess for use in cosmic ray identification. In other words the two limiting factors that I see currently are: (i) image registration and astrometry (SHARE item 1) and (ii) data quality handling. 3. Items that would need to be done Item 1: It ought to be possible for starview (or equivalent) to set up the association table on-the-fly. Item 2: Consider ways to improve identification of defective pixels, mostly cosmic ray hits, in individual images. A reference file for every image, for example? Can they be found once, by an expert task, and the information recorded for subsequent use, or do we need to re-identify them every time? Item 3: Continue existing upgrade path for pydrizzle to enable image combination capabilities that allow for tweaked backgrounds and flux normalization. Item 4: Methods to adjust image registration; SHARE item 1, or else investigate (i) use of object catalogues (ii) cross-correlation (iii) other methods to register images. Item 5: Methods to equalize image background (or equivalently bias) offsets. =============================================================================== RECOMMENDATIONS FOR IMPLEMENTATION ---------------------------------- - Resources required for each idea - Timescales for implementation - Evaluate the fraction of the user community likely to benefit from a given enhancement - Recommendations and road map RECOMMENDATIONS FOR COMMUNITY INVOLVEMENT ----------------------------------------- - regularly poll the STScI instrument groups for their perceptions of users' needs based on their interactions with the community - solicit STUC input on ideas for enhancements and recommendations for implementation of specific ideas - regular STUC presentations as recommended implementations proceed - updates on progress in archive newsletters - presentations/discussions at future ADASS/AAS meetings ------------- End Forwarded Message -------------