Image health seeing and obstac » History » Version 13

Version 12 (James Annis, 12/01/2012 12:03 PM) → Version 13/15 (James Annis, 12/01/2012 12:07 PM)

h1. Image Health seeing and Obstac

The lore is that the image health seeing values are sometimes unrelated to the real seeing.

What do we know?

DIMM free air seeing values are in red, Quick Reduce produced Sextractor FWHM measures of the
delivered image quality (free air seeing + dome seeing + optics + tracking) is in green,
and the Image Health FWHM measures are in blue.
(This image is from Douglas Tucker, October 26, 2012 )
Note that IH and QR track each other well at small seeing values, but that IH
has a cutoff at about 1.5".

If one finds a image with bad seeing, say 2", reported by QR and asks the SISPI
database for the harmonic_mean_seeing values for all 62 ccds, often there will
be only a single ccd reported in the database.

It is likely that Image Health has a threshold above which its seeing measurements
are thrown away: not used in the fp_harm_mean_seeing calculation and not
sent to the SISPI database.

Next, Jiangang (amongst others) points out there is a scale difference between
IH and QR. Jiangang's report is here
but I want to point out the following plot:
At small seeing values QR and IH track well, but at 1.5" the IH seeing flattens out due to
the threshold cut we discussed above. At small seeing it looks like a factor of 1.2 or 1.25 multiplied
on the IH seeing would take it into the QR/sextractor values. Jiangang's analysis shows
many varieties of FWHM calculations; sextractors are fine. (I'm going to ignore the magenta
points above the line as a bad data set)

Here is Ken Patton's description of the IH seeing measurement algorithm, from an email dated
Nov 5, 2012. Notice that there is already a calibration constant multiplier ("fudge factor") in use.

bq. Just to weigh in really quick on Image Health- it does not use sextractor, and doesn't really make a large catalog of stars on each chip. It also does not flat field or bias correct the image (it has to run within 20 seconds). To explain the basic algorithm:

# It works on each amplifier individually, and uses sky noise estimates that it previously calculated to set a pixel detection threshold. Then it steps along the chip in a roughly grid like fashion randomly sampling pixels to make a seed pixel list.
# For each seed pixel it steps around the object to make sure it's isolated and doesn't have any saturated pixels.
# It then calculates the weighted centroid and moments for the ellipticity estimate, throwing out objects above an ellipticity cut (pretty much the main thing it uses to isolate stars from anything else).
# It also calculates effectively a count-weighted radius estimate for the fwhm. For every pixel above 1/2 the maximum pixel value in the object it averages the radius from the centroid and weights it with the counts in that pixel. The fwhm is then computed as twice this "averaged" radius.
# On an individual chip the stars from each amplifier (generally we find 5-20ish on each using this method) are averaged using the harmonic mean.
# The focal plane estimate is then the harmonic mean of all the individual chips.
# This almost always produces estimates that are lower than those from sextractor and other methods- so the last thing we did was use simulated data (dc6b) to calibrate a fitting formula to scale the IH fwhm estimate with a fudge factor to bring it in line with sextractor values. Although on an individual chip the values scatter around quite a bit due to the low number of stars and crude algorithm, we tried to scale the overall focal plane average such that it lined up with extractor estimates. If this is not accurate we can adjust it.

bq. If you have any other questions please let me know- I'll try to help out however I can. -Ken