=============================================================== Photometric Redshifts: estimating photometric redshifts from multicolor imaging data =============================================================== Science Case: The use of multicolor photometry for estimating redshifts of galaxies has become an increasingly common tool for extragalactic observers. This was spurred in a large part by the availability of the WFPC2 Hubble Deep Field images, which provided high quality multicolor optical photometry for thousands of galaxies in a field where extensive spectroscopy was also available to calibrate the photometric redshift methods. Even after an orbit or two, WFPC2 images detect galaxies faint enough that spectroscopy becomes impractically difficult, motivating the desire for color-based redshift estimates. A variety of methods have been employed, and some stand-alone software packages have already been created to compute photometric redshifts from multicolor photometry catalogs. If object catalogs for HST images were to be generated as a data product, then one might imagine feeding these to a photometric redshift estimation code and providing the results as another data product, potentially searchable via the archive. In practice, however, reliable, general purpose photometric redshift estimates require images through at least three filters, preferably at least four. Even then, especially with optical photometry alone (e.g., from WFPC2 or ACS), the range of redshift over which photometric redshifts can reliably be estimated is limited (e.g., galaxies at 1 < z < 2 generally require both optical and infrared photometry for quality photo-z estimates). Only a small subset of HST imaging data would be suitable for photometric redshift estimation, and it would be difficult to implement the sort of "quality control" that would result in easy-to-use and reliable results for the general user. In principle, even with measurements in only two or three bands, a photometric redshift code could be used to provide a likelihood function L(z) which could restrict the range of possible redshifts for a galaxy without necessarily specifying one "preferred" redshift estimate. However, such a product would be more complex to use, interpret, or to search than a straightforward catalog with single data values for each object, and there would be risk that naive users might use these redshift estimates uncritically without considering the very substantial uncertainties involved, especially for non-HDF-like data. Unique STScI capability: If object catalogs from HST images were being automatically generated as an STScI data product, STScI would be in a convenient position to then automatically feed multicolor data meeting some particular criteria to a photometric redshift estimator, and to standardize the performance and output product format. Drawbacks: Relatively few data sets would be suitable for providing good photometric redshift estimates. Therefore, only a small fraction of the archived data would benefit from this effort, or, perhaps worse, inadequate and misleading photometric redshift estimates could be calculated and distributed for a larger body of unsuitable data sets. Assumptions: Science-grade catalogs of the images are a prerequisite to carrying out any photometric redshift analysis. Since this is another SHARE topic, we will assume that these catalogs are automatically available, providing measurements of: o object fluxes, o flux errors, o ideally, also some type of object classification, at least to the level of star/galaxy discrimination. Ideally, the catalogs should be made from the deepest images available for a given field. This would therefore benefit from the availability of stacked/coadded images. Again, since this is another SHARE topic, we will assume that if image combination is possible it will have been done. Multicolor catalogs are also essential for computing photometric redshift estimates. At an absolute minimum, images in two different bands are required. 2-band photometric redshifts won't be very useful (although in principle a redshift likelihood function can be computed even with one color, i.e., 2 bands - it just won't be very constraining). Therefore: 1) The procedure can only be carried out for areas on the sky where images in multiple bandpasses overlap 2) Some procedure is needed to match multicolor photometry for the same objects. This could be done in several ways: a) Independent catalogs could be generated for the different images, and the catalogs for different bands could be matched by position and merged to produce multicolor catalogs; b) Images in multiple bands could be co-aligned, and joint catalogs produced using matched apertures. Method (b) is often preferable, but requires additional processing in order to register images taken in different bandpasses and to define the overlap regions over which the catalogs will be measured. This may be more complex, but if SHARE efforts have already led to (1) WCS improvements and (2) automatic combination of non-aligned images, then it should not be too difficult to adapt those techniques to produced co-aligned, multicolor image sets. For the purposes of the resource estimates here, we will assume that all issues of image registration/combination and cataloging have already been addressed. Required Decisions 1. Is there interest/demand in the community for automatic photometric redshift computation? It is quite possible that this idea will be met with considerable skepticism, if not outright hostility from some quarters. Before any resources are devoted to development, the community should be carefully polled on this. 2. What restrictions should be imposed on the data sets for phot-z fitting? E.g., >= 3 broad band filters only? Only "high latitude" fields without large foreground objects? Etc. 3. Should the procedure try to use all photometric data available from any and all HST instruments that have viewed a particular field or object within that field? Or should it be restricted to data sets taken with a given instrument, perhaps in the same visit? 4. Should an existing photometric redshift mechanism/software package be used, or should a new system be developed? Min and Max Goals Minimum goal: likelihood vs. photometric redshift function and best-fit values for each extended object with photometry in a multicolor photometry catalog of HST data observed with a single instrument through broad band filters. Relatively restricted quality checking and verification (see discussion below). Use pre-existing phot-z method/code with little modification or enhancement. Maximum goal: as above, but with much more scientist time invested in quality checking and verification against existing or new spectroscopic redshift data sets. More extensive quality/reliability reporting in the phot-z data products. Also, incorporate multiwavelength data from multiple HST instruments where available. Develop new, optimized photometric redshift code, or customize an existing method. Implementation Plan Given the availability of multicolor catalogs, the implementation of automated photometric redshift estimates should be reasonably straightforward. Tasks: 0. Assess user community iterest in "automatic" photometric redshift estimation before proceeding with development. Required resources & timescale: 1 FTE scientist for ~1-2 weeks to prepare a presentation (e.g., to the STUC) and/or questionaire for the community (e.g., at AAS? or by e-mail?) polling interest in such an effort, and to assess feedback. 1. Assess methods/software for photometric redshift estimation. Many astronomers have developed such techniques, and there is an active industry of developing/extending/testing these. However, relatively few public software packages are presently available (the only one I know that can be downloaded from a public site is 'hyperz'). Key issues: - assessing algorithms/methods - software availability Required resources & timescale: For Minimum goals: This work must be done by astronomers knowledgeable in this area. 1 month of a (knowledgeable) FTE should suffice to investigate and critically assess the available methods. For Maximum goals: If STScI wishes to develop a new photometric redshift system or extensively modify a previous one, this will probably require at least 3 months for a knowledgeable FTE scientist to develop the system, and 3-5 months for an FTE science programmer to implement and test. 2. Establish criteria for suitable data sets. As noted above, only data sets with multicolor imaging are appropriate, and perhaps only with >2 bands. Quite possibly, one would wish to impose other restrictions: - availability of data covering certain wavelengths. (E.g., is it worthwhile to compute phot-z's if only UV bands, or only narrow bands, are available? or if the only available photometry is widely spaced in wavelength?) - S/N or limiting depth considerations (E.g., it may not be worthwhile to estimate photometric redshifts if the exposures are very short and shallow, or if one image is deep and another is shallow, etc.) - target considerations (E.g., one may wish not to try photometric redshift estimation on fields at low galactic latitude, or which contain bright foreground stars or galaxies, extended nebulosity, planets, etc.) Required resources & timescale: For Minimum goals: MAST has already invested some effort into providing mechanisms for establishing whether multiple HST data sets cover the same portion of the sky. We expect that existing efforts within MAST, FASST, or byproducts of other recommendations from SHARE (e.g., image combination) could be used to establish which data sets are suitable for photometric redshift analysis. Therefore I will assume that most of the FTE resources needed to implement this will largely come from other sources, and thus do not assign them here. Similarly, S/N characterization is another SHARE recommendation (also FASST?) and therefore we do not include FTE resources for implementing this. Issues regarding target considerations are very similar to those relevant for object cataloging, so once again we do not include further FTE resources here. Roughly 2 weeks of an FTE scientist may be needed to consider and define criteria on which to base the decision for which data sets are suitable for phot-z analysis. For Maximum goals: Implement photometric redshift fitting for multicolor, multi-instrument catalogs, e.g., combining ACS and NICMOS photometry on common objects. We are assuming here that any issues regarding implementation of multi-instrument catalogs has been dealt with as part of other SHARE or FASST recommendations, and thus require no additional resources here. 3. Software development / interfacing. If existing photometric redshift software is adequate, then it may only be necessary to interface it with other archive systems. However, it is not unlikely that new software might be written, or significant modifications might be made to existing systems. Required resources & timescale: If substantial new software development for photometric redshift analysis is needed, we expect this would require at least 6 FTE months for a programmer. It will almost certainly require scientist time as well, if the new methods must be developed in house. Some archive/programming effort will be needed in order to ingest phot-z catalog results into the archive, and to provide an interface for accessing these data. 4. Quality control Photometric redshifts should not be used blindly. However, if sufficient testing is available, e.g., by comparison to spectroscopic data sets, then the methods can be tested, and accuracy and reliability can be quantitatively assessed (up to a point). Required resources & timescale: For Mininum goals: Relatively little quality control would be done -- the procedure would report likelihood vs. redshift curves, and it would be up to the user to assess their reliability. For Maximum goals: This will require significant effort on the part of a scientist knowledgeable in this field, who must identify suitable test data sets (the HDF is an obvious example, but cannot be used to test results based on other filter combinations, or at different sensitivity limits, etc.). we expect that at least 3 FTE months for a scientist will be needed for this effort.