Aperture Photometry in the JWST Pipeline Source Lists.

[stscijgbot]

Issue JP-645 was created by Brad Whitmore:

Elaboration of Requirements for Aperture Photometry in the JWST Pipeline Source Lists.

BACKGROUND:

Basic source lists requirements for the JWST pipeline were defined in:

https://outerspace.stsci.edu/display/JWSTCC/Vanilla+Point+Source+Catalog

This is sometimes referred to as the "Vanilla Source List". An "Optimal Source List" is also being discussed within the JWST Photometry Working Group and will be presented to the Calibration Working Group at a future date.

Below is an elaboration of the requirements for aperture photometry, as discussed within the JWST Photometry Working Group >>> webpage: https://outerspace.stsci.edu/display/JWSTCC/JWST+Photometry+Working+Group

REQUIREMENTS:

1. Circular aperture photometry should be performed using the Photutils package.

This can be in addition to the detection and photometry algorithms that are currently included in the pipeline code using an image segmentation approach, as long as this approach is able to identify point-like sources in different environments (e.g., high background, crowded regions) at a level that at least looks as good as with DAOPHOT. Early results from Larry Bradley's Jupyter handbook suggest this is true but this should be evaluated in more detail as we go along.

2. Aperture sizes in pixels should come from reference files developed by the NIRCAM, MIRI, and NIRISS instrument teams providing the pixel values for each instrument/filter combination that encircle 20 % - 50 % - 70 % of the energy in a PSF.

3. A local background should be used for sky subtraction based on the median value in a circular aperture taken between the 80 and 85 % encircled energy apertures, as defined in pixel values by the reference file described in item 2.

(NOTE: it is possible that the percentages defined in items 2 and 3 will be changed in the future, following a study of the optimal apertures.)

4. The format for the reference files should include aperture radii (in pixels as a function of detector/filter), and aperture corrections (to infinity) for each detector/filter combination. The aperture corrections should take into account the small contribution from the wings of the PSF in the sky annulus. A separate row should be used for each filter.

Clarification from Larry Bradley - " Right now, I simply need the aperture radii (in pixels) as a function of detector/filter. Once we have defined how many apertures to use in the output catalog, etc., I will define/deliver the initial version of the references files (one per instrument). The instrument teams can then redeliver updates as needed."

5. The source list should be optimized for point source detection, but should also do a reasonable job on somewhat extended sources. The finding algorithm should do reasonably well on all fields (e.g., stars, small galaxies like HDF, nearby galaxies with high backgrounds, ... ), rather than being tuned for a specific type of field.

(NOTE: A study may be needed to determine what the best values are for search parameters, e.g., FWHM, S/N, ... , and how well they work for different types of images).

6. The number of artifacts should be minimal. Typical artifacts include close pairs of stars, diffraction spikes, multiple detections of saturated cores, Airy rings, ...

7. Photometry with three units will be included in the catalog 1 - flux densities in Jy 2 - Vegamag in mag 3 - Abmags in mag

8. A single source list file should be produced providing the following information:

c1: X-position c2: Y-position c3: ID-number c4: RA c5: DEC

c6: fluxdens_20 (i.e., the flux density for the 20 % encircled energy aperture) c7: err_fluxdens_20 (error estimate in fluxdens_20) c8: fluxdens_50 c9: err_fluxdens_50 c10: fluxdens_70 c11: err_fluxdens_70 c12: back_fluxdens (median value in background annulus, tentatively planned for 80 - 85 % encircled energy aperture) c13: err_back_fluxdens (rms error estimate in back_fluxdens) c14: fluxdens_tot (total flux density if a star - set to NA if star? = N) c15: err_fluxdens_tot

c16: abmag_20 (i.e., the magnitude for the 20 % encircled energy aperture) c17: err_abmag_20 (error estimate in mag_20) c18: abmag_50 c19: err_abmag_50 c20: abmag_70 c21: err_abmag_70 c22: abmag_tot (total magnitude if a star - set to NA if star? = N) c23: err_abmag_tot

c24: vegamag_20 (i.e., the magnitude for the 20 % encircled energy aperture) c25: err_vegamag_20 (error estimate in mag_20) c26: vegamag_50 c27: err_vegamag_50 c28: vegamag_70 c29: err_vegamag_70 c30: vegamag_tot (total magnitude if a star - set to NA if star? = N) c31: err_vegamag_tot

c32: CI_20_80 (concentration index, i.e., the difference between mag_20 and mag80, Note: other CIs can be determined based on other columns above) c33: star? (Is this a star? Y/N. e.g., . using a combination of the CI 20_50 and CI_50_80 and CI_20_80 values) c26: sat_flag (saturation flag - Y/N - based on whether any pixels are saturated in full readout from the DQ array) c27: sharpness c28: roundness c29: major_axis c30: minor_axis c31: isolation metric (e.g., how roundness changes as function of radius ) Might use Leonardo's - nearest neighbor algorithm for this values

c32: sky_bbox_ll (RA/DEC for source bounding box corners for WFSS spectral pipeline) c33: sky_bbox_ul c34: sky_bbox_lr c35: sky_bbox_ur

NOTE: Other columns based on the image segmentation of the code can also be included. (e.g., mag_auto, Kron_radius, ...)

Question under consideration - If star? = no, should there be an estimate for total magnitude, since it could be misleading. At present the answer is no, with a NA = Not Applicable used for the relevant columns above. There was not a consensus on this item so it is still under discussion.

9. The catalog file should include a header that includes the information that does not vary (e.g., dataset used to obtain source list, date taken, aperture sizes used, filter used, ...) and that also explains the columns.

 

 

 

[sosey]

Just minor comment re the last question: The WFSS code does look at the magnitude for each object and only extracts those brighter than some minimum. I can of course account for NA mag, but would need direction on whether to always extract non-stellar identified objects regardless of mag. The extraction magnitude limit is currently a parameter into the x2d code, default to 99.

https://github.com/spacetelescope/jwst/blob/master/jwst/extract_2d/grisms.py#L218

[stscijgbot]

Comment by Larry Bradley: As discussed in the last two JPWG meetings and listed as Action Items #2 and #3 in the JPWG minutes of the 2/5/2020 meeting, to complete the work for this ticket I still need algorithms for:

1.  Definition of star or non-star and when to provide a total magnitude (Brad) and if there should definitely be such a column with the star/non-star criteria. 

From the minutes: "We might also then add a column for "likiehood_this_is_star" = 1 if the CI value is < 1.1 the CI value for a star from the reference file, = 2 if 1.1 < CI 1.3, = 3 if CI > 1.3. A more sophisticated algorithm (e.g., using all three apertures) might be developed as part of action item # 2 below.)"

Please clarify exactly what columns are requested and final algorithms.  If the answer is use the above heuristic, then 1) do you want this column in the output catalog and 2) for what values do you want the "total_mag_if_star" column to be populated?

2.  Isolation criteria (Brad and Leonardo)

[stscijgbot]

Comment by Brad Whitmore: Here are my recommendations on the two items from Larry above.

• From March 2 email to JPWG

UPDATE: Brad looked into the "star/not a star" flag a bit with somewhat surprising results, which will be included in the technical document he is working on for the optimal aperture study. The bottom line is that he expected that the concentration index using 70 and 30 % flux values would have a median values very near 70/30 = 2.33. However, for F070W, F200W and F444W the values were 1.9, 2.1 and 2.6 for the NIRCam simulation he is working with (of LMC as made by Matteo and Leonardo). This precludes the plan of using 2.33 +/- std dev (~ .15) to identify stars. Possible reason are: 1) some miscalculations on my part (am I missing something ? Need to look at each step to see if can figure out what is going on), 2) webbpsf not giving very good encircled energy radii, 3) a mismatch between the MIRAGE simulations I have been using and webbpsf, ... In any case, the real values to use to characterize stars will need to be done from observations on orbit anyway, hence I suggest leaving the star/non-star column as NA (Not Available) for now, since it appears to be more complicated than expected.

 

• From March 3 email to Matteo, Larry, Leonardo

Discussion of isolation criteria to use in JWST source lists.

 

The original plan discussed when the JWST Photometry Working Group (JPWG) started was to adopt the criteria the NIRSPEC team plans to check whether a given star can be used for MSA target acquisition, namely:

 

1 - the source needs to be the brightest object within  a radius "TArefbox", generally taken to be 3.2 arcsec.

 

- the source cannot have any other neighbors within a radius "TAcentbox", generally taken to be 0.3 arcsec.

 

This, and a specific algorithm for making the needed calculations, can be found in a presentation by Leonardo Ubeda at:

 

[https://outerspace.stsci.edu/pages/viewpage.action?spaceKey=JWSTCC&title=JWST+Photometry+Working+Group&preview=/33425609/42795398/isolation_criteria_leonardo-29may2019.pdf]

 

---

However, when we discussed this with the JWST Calibration working group in July, the consensus was that:

 

this would be too specific for general users,

 

the NIRSPEC team could use the source list to run their software themselves.

 

 

Here is the discussion from the PWGCWG_notes_jul_9_2019_edit.rtf at:

[https://outerspace.stsci.edu/display/JWSTCC/JWST+Photometry+Working+Group?preview=/33425609/46630039/PWGCWG_notes_jul_9_2019_edit.rtf]

 

 

Isolation Criteria Discussion:

 

Karl: is it a number (i.e., distance from the closest star) or is it a flag (“good star”)? Is it specific for only NIRSpec TA or can it be a general feature for all the instruments?

Specific for NIRSpec TA: Leonardo uses custom number.

General: users want to know if there is a bright star and the distance from object of interest.

—> To be discussed in the Photometry WG.

 

 

---

With this discussion in mind I suggest we use include two columns, the distance to the nearest neighbor

in pixels, "dist_nn",  and the AB magnitude of the nearest neighbor, "abmag_nn".

 

 

Does that sound ok to the three of you?

 

Cheers,

Brad

 

 

 

[stscijgbot]

Comment by Howard Bushouse: Baseline requirements have been included in B7.5

[stscijgbot]

Comment by Larry Bradley: For the record, the isolation_criteria column was replaced by two columns, nn_dist and nn_abmag, representing the distance in pixels and AB mag of the nearest neighbor, respectively.

[stscijgbot]

Comment by Anton Koekemoer: An issue here is that one of the baseline requirements (https://outerspace.stsci.edu/display/JWSTCC/Vanilla+Point+Source+Catalog) is: "the ca{color:#172b4d}talog should provide an indication if the source is a point or an extended source", and it was reported by [~lbradley] today (May 13, 2020) at the JWST Photometry meeting that this has not been implemented in B7.5; see also email from him below:{color} {quote}Hi all,

I was informed today that no new development will go into Build 7.5.

The deadline for Build 7.6 is the end of June. Please provide me with the criteria/algorithm for determining whether an object is a star or not by June 12 to get this feature in Build 7.6.

Thanks, Larry {quote} {color:#172b4d}So, I'm assigning this ticket to [~correnti] so that this can be worked on within the JWST Photometry Group, so that the necessary algorithm/ criteria can be provided back to [~lbradley]  by Jun 12, in order for him to incorporate this into Build 7.6. Once this has been given to Larry, then this ticket should be assigned to Larry at that point.{color}

[stscijgbot]

Comment by Anton Koekemoer: Also setting this ticket as critical for commissioning and science and adding the "Commissioning" label, since these catalogs are required in order for the spectroscopic extraction steps in the pipeline to work.

[stscijgbot]

Comment by Matteo Correnti: [~koekemoe], [~lbradley]

The JPWG converged on the following algorithm to determine if the objects in the catalog are point sources or extended sources:

IF (CI_1 > threshold_1) AND (CI_2 > threshold_2) THEN

     Source is Extended

ELSE

     Source is Point

 

Where the pipeline code would have these defaults:

CI_1 is Concentration index 1 (50/30)

CI_2 is Concentration index 2 (70/50)

threshold_1 = 2.0

threshold_2 = 1.8

Actual values will be delivered by each Teams as parameter reference files, since they may depend on instrument and filter details. 

[stscijgbot]

Comment by Alicia Canipe: [~lbradley] [~correnti]

Have all baseline items in this ticket been implemented? If so, I will close this ticket.

[stscijgbot]

Comment by Larry Bradley: Yes.  The algorithm for determining whether a source is a star was implemented in https://github.com/spacetelescope/jwst/pull/5234.

[stscijgbot]

Comment by Alicia Canipe: Closing, since all items from the ticket have been implemented.