Image Descriptors

APM/SuperCOSMOS analysis produces 32 4-byte parameters per detected object. As an example the INT Wide Field Camera survey pipeline produces the following set (which has evolved from the original APM set):

No. 		 Name 		 Description 


1 		 Seq. no. 		 Running number for ease of reference, in strict order of image detections


2 		 Isophotal flux 		 Standard definition of summed flux within detection isophote, apart from 


detection filter is used to define pixel connectivity and hence which


pixels to include. This helps to reduce edge effects for all isophotally


derived parameters.


3 		 Total flux 		An attempt at generating automatically a total flux using a curve-of-growth


technique. The closest description as to how it works is given in Hall &


Mackay (1984). This is better than the isophotal flux in terms of systematic


error, but still not perfect and definitely worse for random error.


4 		 Core flux 		Best used if a single number is required to represent the flux for ALL


objects. Basically aperture integration with radius rcore (in the FITS


header) but modified to simultaneously fit `cores' in case of overlapping


images.


5 		 X co-ord 		 Intensity-weighted centre-of-gravity in X


6 		 Y co-ord 		Intensity-weighted centre-of-gravity in Y


7 		 Gaussian sigma 		These are derived from the intensity-weighted second moments. The 


8 		 Ellipticity 		equivalence between them and a generalised elliptical Gaussian distribution


9 		 Position angle 		 is used to derive Gaussian sigma = $(\sigma_a^2+\sigma_b^2)^{1/2}$ 


Ellipticity = $1.0-\sigma_a/\sigma_b$ 


Position angle = angle of ellipse major axis wrt x axis


10 		 Peak height 		in counts relative to local value of sky 


11 		 Areal profile 1 		Number of pixels above a series of threshold levels relative to local sky.


12 		 Areal profile 2 		Levels are set at T, 2T, 4T, 8T ...128T where T is the threshold. These


13 		 Areal profile 3 		can be thought of as a sort of poor man's radial profile. Note that for


14 		 Areal profile 4 		deblended, ie. overlapping images, only the first areal profile is computed


15 		 Areal profile 5 		and the rest are set to -1 flagging the difficulty of computing accurate


16 		 Areal profile 6 		profiles.


17 		 Areal profile 7 		 


18 		 Areal profile 8 		 


19 		 Core 1 flux 		A series of different radii core/aperture measures similar to parameter 4.


20 		 Core 2 flux 		Together with parameter 10 these give a simple curve-of-growth analysis from


21 		 Core 3 flux 		peak pixel, $1/2\times$ rcore, $\surd2\times$ rcore, $2\times$ rcore, $2\surd2\times$ rcore


22 		 Core 4 flux 		 


23 		 RA 		RA and Dec explicitly put in columns for overlay programs that cannot, in


24 		 Dec 		general, understand astrometric solution coefficients. Derived exactly from


WCS in header and XY in parameters 5 & 6


25 		 Classification 		Flag indicating what image is most probably: -1 stellar, +1 non-stellar, 0 noise


26 		 Statistic 		An equivalent N(0,1)  measure of how stellar-like an image is, used in


deriving parameter 25 in a `necessary but not sufficient' sense


27 		 Core 5 flux 		$4\times$ rcore, extra to ensure $\sim99$% of PSF flux


28 		 Sky level 		 Interpolated sky level from background tracker


29 		 Child/parent 		Flag for parent or part of deblended deconstruct


30 		 Blank 		 


31 		 Blank 		 


32 		 Blank 		 

This will be enhanced to include error estimates for a TBD subset of the parameters.

As an alternative the SDSS archive has a much larger set of parameters per object (see for example http://www.sdss.jhu.edu/) - many are error estimates on parameters analogous to the above. Others include different flux measures - eg. Petrosian magnitudes, and list-driven flux measures expressed in asinh magnitudes whereby flux estimates at the same position in all other wavebands are obtained given a significant detection in any one passband. It is proposed that the parameters derived froma WFCAM image in a single passband will be similar to the above INT-WFC set. Input from the WFCAM user community (especially UKIDSS) would be welcomed to help finalise the details of the parameter set, but it is clear that any significant enhancement lies outside the scope of the WFCAM Science Archive as achievable with existing resources and would require additional resources, eg. from AstroGrid or specific science projects.

Over the last few years, provision for user access to large databases has grown from simple position and proximity-based querying capability to highly flexible systems employing `structured query language' (SQL) syntax. Examples of the former are the UK photographic archives at Cambridge (APM) and Edinburgh (SuperCOSMOS):

http://www.ast.cam.ac.uk/~mike/apmcat
http://www-wfau.roe.ac.uk/sss

while an example of the latter is the 2MASS archive:

http://www.ipac.caltech.edu/2mass

The most recent large-scale archive, that of the SDSS, employs an extended SQL (SXQL) syntax in a flexible database system (SX) which sits on top of the commercial object-oriented database management system Objectivity; details are available at http://www.sdss.jhu.edu/ and see also Thakar, Kunszt & Szalay (2001) and references therein. The object-oriented approach brings many advantages, not the least of which is enabling whole database searches for specific queries to be executed quickly provided the database is indexed (or `tagged') in an appropriate way. A simple example of an SXQL procedure is:

// Select all stars in a given RA range

SELECT
RA(),DEC(),
g,r,i,z
FROM sxStar
WHERE (
RA() BETWEEN 15 AND 16 && g < 20
)

where the the select-from-where construct allows the user to choose the parameters to be output, the `class' of object to be searched, and the search criteria to be applied to all images in the searched class.

A mirror site for the SDSS EDR is being established at Edinburgh. Given the manpower effort expended on the state-of-the-art SDSS system and its obvious flexibility, it is proposed that it be employed as the basis for the WFCAM Science Archive. Experiments are underway at Edinburgh with SX/Objectivity; these will include implementation on a Beowulf cluster for enhanced access speed. The general feeling is that SX is likely to become the community-wide standard since much development has already been done on it.