Changes between Initial Version and Version 1 of Stackphot_20100514

Timestamp:

May 17, 2010, 4:54:12 PM (16 years ago)

Author:

eugene

Comment:

--

Stackphot_20100514

@@ +1 @@
+== Stackphot Initial Release == 
+
+I have finished up some major work on the IPP stack extended source
+photometry analysis, and I am placing a small example on an rsync
+server for people to investigate.
+
+The data can be found at:  rsync://pikake.ifa.hawaii.edu/md04.stackphot/
+
+Download it with a command like: rsync -auv
+rsync://pikake.ifa.hawaii.edu/md04.stackphot/ md04.stackphot/
+
+There are two sets of files in this directory:
+ * MD04.skycell.079.stk.* : these are the inputs to the stackphot analysis
+ * MD04.skycell.079.stkphot.* : these are the outputs from the
+stackphot analysis.
+
+The analysis was performed using the griz images from the current
+'refstack' for MD04.  Those stacks do not include some of the recent
+fixes related to the covariance matrix calculation.  That point may
+affect the depth to which psphot did the analysis.
+
+There are 4 sets of output files, one for each of the input filter
+images (0 = i, 1 = g, 2 = r, 3 = z).  The *.im.fits is the psf-matched
+image, *.wt.fits is the equivalent variance, *.mk.fits is the
+equivalent mask, *.cmf is the set of FITS tables with detection
+information.  In the cmf files, there are 4 data units.  The primary
+data unit is the header with metadata about the input image (not very
+complete or accurate I'm afraid -- we are fixing this up).  The next
+(EXTNAME = SkyChip.psf) is the PSF table.  This uses a new format
+'PS1_SV1' which includes fields for the radial profile information
+(see below), along with the cmf fields familiar from the PS1_V2
+version.  (Note that we will continue to use PS1_V2 for all photometry
+analysis except stackphot and diff -- for diff we will be using the
+PS1_DV1 format which I've mentioned before).  The next data unit
+(EXTNAME = SkyChip.xsrc) is the extended source table, with the
+elliptical profile data and the petrosians -- note that these are only
+provided for 'extended' sources.  The final data unit (EXTNAME =
+SkyChip.deteff) is the detection efficiency table.
+
+Note that we are intending to change the EXTNAMEs to all upper case
+(perhaps before next week).
+
+Over the next few days, I'll be running more of these MD04 skycells.
+We also will create a new set of stacks using all of the images to
+date (or a 'best seeing' subset).
+
+-----
+
+Here is a summary of the stackphot analysis:
+
+In the stack photometry analysis, we start with a set of skycell
+images (normally stacks, but they could be warps as well).  In the
+case of stacks, the input stack data has both convolved (PSF-matched)
+and unconvolved images.  For the stackphot analysis, like in the stack
+analysis, we define a target PSF and smooth the input images to
+generate a set of PSF-matched images that have the desired target PSF.
+ We can optionally use the convolved stacks or the unconvolved stacks
+as the input to this PSF-matching step.
+
+We then use the unconvolved images for the detection process.  We
+perform the detection process on the individual images.  We also
+generate a chi square image from all inputs and run the detection
+analysis on that image as well.
+
+The detected sources in each of the input images are merged together
+into a set of common objects.  For images where a source is not
+detected, we generate one from the common object at the location -- in
+the end all positions for which a source is detected on any image is
+then treated as a source.  For all sources, we force a common position
+(average of the actual detections).
+
+We then use the convolved images (PSF-matched to the target PSF) to
+perform the analysis.  In addition to the standard psf photometry, we
+now generate additional measurements: for all sources, we measure
+aperture fluxes for a series of radial apertures, along with the
+errors and the 'fill factor' (the number of pixels used for a given
+radius divided by the area at that radius in pixels -- this is useful
+to judge the amount of masking and quality of the aperture).
+
+For extended sources, we also measure the elliptical contour at the
+0.25 Peak flux level.  We use this contour to generate a re-normalized
+radial profile, following the elliptical contour.  In order to
+generate a clean radial profile, we measure the profile separately for
+each of 30 angular bins and compare 180-degree opposite bins -- the
+shallower of the opposite profiles wins out.  This enforces 180 degree
+rotational symmetry and approximates the SDSS deblender.  Also note
+that the analysis of a single source is performed with the other
+sources subtracted (using the best fit psf or simple galaxy model), so
+the resulting analysis is essentially isolated to a single source.
+
+We then use the radial profiles to measure Petrosian quantities
+(Petrosian radius, magnitude, R50, R90 values as defined by SDSS).  We
+also report the surface brightness and enclosed flux at specific major
+axis radii for the elliptical contours.  (Again -- these are only
+reported for the extended sources).
+
+I have made comparisons to the SDSS analysis using SDSS images and
+find that the results agree well (I'll put together a report over the
+next few days).
+
+For both the circular and elliptical apertures, we are currently using
+the radii defined by SDSS.  The inner and outer radii in pixels are
+listed below:
+
+@RADIAL.ANNULAR.BINS.LOWER           F32     0.00 0.56 1.69 2.59 4.41
+7.51 11.58 18.58 28.55 45.50  70.51 110.53 172.49 269.52 420.51
+@RADIAL.ANNULAR.BINS.UPPER           F32     0.56 1.69 2.59 4.41 7.51
+11.58 18.58 28.55 45.50 70.51 110.53 172.49 269.52 420.51 652.50
+
+Some points and caveats:
+
+* unlike SDSS, we are currently using the Petrosian flux measured on a
+given image to determine R50 and R90 for that image (SDSS uses the
+r-band)
+* the average object positions are used to measure the radial, not
+r-band specifically like SDSS
+* we do not currently resample and recenter the source pixels to place
+the center at a pixel center (as photo does).  this should only be an
+important effect in the inner ~2 pixels if the image is nearly
+undersampled (which we clearly are not).
+* the zero points are not being carried into the stack correctly, so
+the photometry is NOT currently calibrated.  The data in the sample is
+from MD04, which overlaps SDSS, so it should be easy to calibrate from
+SDSS.
+* the astrometric calibration is being applied to the output 'cmf'
+tables, but the WCS seems to be broken in the header
+* there is a bit of work still needed to integrate the analysis into
+the IPP automatically.
+* non-linear model fits are still not being included in the analysis