Discussion: Config file update with different values for relative and absolute alignment

[stscijgbot-hstdp]

Issue HLA-1271 was created on JIRA by Steve Goldman:

Following on from HLA-1233, this ticket will track the progress of the newly proposed changes to config files:

Update the logic of the alignment software so that there are {}separate config file settings for relative (HST-to-HST) versus absolute (catalog) alignment{}.  This is important in order to preserve relative alignment of exposures acquired with sub-pixel dithers which optimally sample the PSF.  

For standard HST ipppssoot products with FIT-REL solutions and HAP hst_ipppss products with FIT-SVM solutions,  a relative alignment between exposures in an ASN (or in a visit) is performed before a global catalog fit.   In most cases, the pointing of HST is very accurate and the relative alignment is not necessary. This step can introduce errors and degrade the quality of the combined drizzled products significantly when there are few matched sources.

PROPOSAL ({}See flowchart{}):

1.) KEYWORDS:  For the relative alignment (for both standard and HAP products), we would like to populate new header keywords so they will not be overwritten during the catalog alignment step. 

Current (catalog):     nmatches, fitgeom,  rms_ra,    rms_dec
Proposed (relative):  relmatch,   relgeom, relrms_r, relrms_d, relrefim

2.) Config settings for a successful fit:   

• FIT-REL:          relmatch  >=20, relgeom = 'rshift')        
• FIT-REL-cat:   nmatches >=10, fitgeom = 'rscale')        
• FIT-SVM:         relmatch  >=10, relgeom = 'rscale')         
• FIT-SVM-cat:  nmatches >=10, fitgeom = 'rscale')

When there are not enough matches, the relative alignment is skipped, the proposed new keywords {}relmatch, relrms{}*, etc. are set to N/A and the catalog alignment is performed for the drizzled combined product instead.   In these cases, the WCSNAME will still be FIT-REL-cat or FIT-SVM-cat but the additional keywords will let us know what was done by the software.

3.) Verify keyword mapping to values in astrometry database. For example, https://mast.stsci.edu/portal/astrometryDB/observation/read/jcsz32diq

      <{}wcsName{}>IDC_0461802dj-FIT_REL_GAIADR2
      <{}refCatalog{}>GAIADR2
      <{}nMatch{}>7                             <--  nmatches
      <{}rmsRA{}>16.69339839         <--  rms_ra     
      <{}rmsDEC{}>9.16140064         <--  rms_dec 

[stscijgbot-hstdp]

Comment by Steve Goldman on JIRA:

Jennifer Mack Please add any additional comments here.

[stscijgbot-hstdp]

Comment by Jennifer Mack on JIRA:

Attachment fit-rel-gsc242_vs_apriori.png shows the results from  the drizzlepac notebook tutorial for WFC3/IR test dataset ib1f19010.  In cases where there are few matched sources, the relative step can introduce errors and degrade the quality of the combined drizzled products significantly.

https://spacetelescope.github.io/hst_notebooks/notebooks/DrizzlePac/optimize_image_sampling/optimize_image_sampling.html

 

[stscijgbot-hstdp]

Comment by Jennifer Mack on JIRA:

Varun Bajaj notes that the relevant code appears to be at line 822:

https://github.com/spacetelescope/drizzlepac/blob/main/drizzlepac/haputils/align_utils.py

[stscijgbot-hstdp]

Comment by Steve Goldman on JIRA:

From a coding perspective I've tried to outline a plan for implementing these changes. 

 

Pass the new "rel" nmatch requirements using a new "mosaic_relgeom_list" in the configuration files (e.g. acs_hrc_alignment_all.json). 

Receive the new requirements in determine_fit_quality() in align.py and use them for the nmatches_check when doing relative fits. 

Create a new way for selecting the best relative fit in addition to the current way. This might include creating a new function similar to align_utils.py select_fit().

If the relative fit is adopted, save the new 'rel' best fit keywords in addition to the current best fit keywords in the headers of the flt and drz products for both pipeline and svm products. This will probably happen in update_image_wcs_info().

 

This will take considerable time as the code was only designed to pass around one "best-fit" and best-fit parameters. We will also have to make sure that the best-fit relative solution that is saved also passes the various checks that use the non-relative-fit keywords.

Using this scenario, the code will always still do an initial relative fit, but the fit solution will only be adopted if it meets the required number of matches. 

[stscijgbot-hstdp]

Comment by Steve Goldman on JIRA:

Jennifer Mack Currently, the code (align.py; line 990) ignores any nmatch requirements if the "fit_rms" is > 0.5.

Is this something that you want to continue for relative fits, or does this need to be changed?

[stscijgbot-hstdp]

Comment by Jennifer Mack on JIRA:

Ignoring nmatch requirements when the "fit_rms" is > 0.5 pixels seems reasonable for relative fitting.  I'm assuming it will simply skip the relative fit and proceed to the next step (catalog alignment).

I'll be on vacation Aug 8-19, so please tag Varun Bajaj with any questions on this ticket.

[stscijgbot-hstdp]

Comment by Steve Goldman on JIRA:

I think the opposite is true in that a solution is accepted if fit_rms<0.5, regardless of the number of matches. I'm guessing this is not the desired outcome. Varun Bajaj 

[stscijgbot-hstdp]

Comment by Jennifer Mack on JIRA:

Questions from Steve: 

Do we want to keep the requirement that the number of relative fit nmatches is ignored if the fit_rms > 0.5?

What are the final nmatch requirement numbers that we want for the catalog and also for the relative fits?

what does the relrefim keyword that was requested correspond to?

 

1.) If relative fit_rms > 0.5 pixels then the fit is bad and move on to the catalog fit.

2.) nmatch requirements for a successful fit.

Type of Fit. Matching requirement. Fitting requirement.

FIT-REL      relmatch >=20,        relgeom = 'rshift')       
FIT-REL-cat  nmatches >=10,        fitgeom = 'rscale')       
FIT-SVM      relmatch >=10,        relgeom = 'rscale')        
FIT-SVM-cat  nmatches >=10,        fitgeom = 'rscale')

--> NEW keywords for relative alignment to be added to both HST (ippssoot_flt) data products and SVM (hst*_ippssoo_flt) data products. (This ensures we don't overwrite the relative fit info when we do the catalog fit.)
      'relmatch', 'relgeom' 'relrms_r', 'relrms_d' 

--> EXISTING keywords will be reserved for the catalog alignment and added to both HST and SVM products:
      'nmatches', 'fitgeom',  'rms_ra',  'rms_dec'

3.) NEW keyword 'relrefim' is the ROOTNAME (ipppssoot) of the FLT/FLC image used for the relative alignment in the first run of tweakwcs.  

If the input list is sorted alphanumerically, it will be the first image.  On the other hand, there may be some build in code logic which selects the reference image based on which image has the most overlap with the other ones. (It would be good to check this because sometimes it is simply the image which downloaded first, which is not ideal.)

[stscijgbot-hstdp]

Comment by Steve Goldman on JIRA:

Alright, I think I have a viable PR for this. I just want to make sure that I understand the desired outcome for one part of this. 

 

In the case where the code has successfully completed a relative alignment with a group of ipppsssoots (e.g. icyj11). The "REL" keywords for the icyj11olq_flt.fits and icyj11olq_drz.fits will reflect those relative fit results.

When a subsequent run of the SVMs is done and relative alignment is done on those (WCSNAME='IDC...FIT-SVM-GAIAeDR3'), the "REL" keywords for the hst_...{}icyj11_drz.fits and hst...{}_icyj11_drz.fits will reflect the "REL" keywords for the SVM relative fit solution. 

 

HOWEVER, once SVM relative fitting is done, should the ipppsssoot flts have updated "REL" keywords that correspond to the SVM relative fit, or the pipeline relative fit? i.e. the FIT-REL-GAIAeDR3 or FIT-SVM-GAIAeDR3 fits?

 

 

At the moment my code change does not overwrite the ipppsssoot.flts with the "REL" keywords corresponding to an SVM relative fit. 

[stscijgbot-hstdp]

Comment by Jennifer Mack on JIRA:

This is correct.  When the SVM fitting is done, we should not touch the ipppssoot (HST) files or update any of the keywords, which are unique to these specific data products. 

The SVM hst*_ipppssoo data products will utilize the same keyword names, but they will have their own unique values as reflected from the results of the FIT-SVM-catalog fit.

 

Thus, we are able to completely capture up to 4 sets of fitting results for a given dataset:
    HST (relative and catalog) and SVM (relative and catalog)

[stscijgbot-hstdp]

Comment by Steve Goldman on JIRA:

Awesome, thanks for clarifying that. I think the code is ready for review.

[stscijgbot-hstdp]

Comment by Steve Goldman on JIRA:

closed with PR #⁠1860.

[stscijgbot-hstdp]

Comment by Jennifer Mack on JIRA:

Preliminary set of regression test data is here:

/ifs/archive/dev/processing/hla/home/mburger/singlevisits/results_2024-09-04

 

Processed with:

Name Version Build Channel drizzlepac 3.7.1rc1.dev28+g750c6fd pypi_0 pypi

[stscijgbot-hstdp]

Comment by Jennifer Mack on JIRA:

I noticed some unexpected results in the test data, which i report here for the following observations:

 

1. ) For a single FLC dataset, the keyword values for the relative and catalog fits are identical, but should have unique values corresponding to their unique number of matches, rms, etc.

/ifs/archive/dev/processing/hla/home/mburger/singlevisits/results_2024-09-04/ibxl04/ibxl04kdq_flc.fits

WCSNAME = 'IDC_2731450pi-FIT_REL_GAIAeDR3' / Coordinate system title            
RMS_RA  =    5.711020259082877 / RMS in RA of WCS fit(mas)                      
RMS_DEC =   5.2894068148818985 / RMS in Dec of WCS fit(mas)                     
NMATCHES=                  686                                                                                                       
RELREFIM= 'ibxl04kbq'          / base reference image rootname for relative fit 
RELRMS_R=    5.711020259082877 / RMS in RA of relative WCS fit(mas)             
RELRMS_D=   5.2894068148818985 / RMS in DEC of relative WCS fit(mas)            
RELMATCH=                  686 / number of matches for relative fit             

2.) For multiple FLC datasets, the keyword values for the catalog fit are the same (as expected since they are aligned as a group), but the values for the relative fit should be unique.  

/ifs/archive/dev/processing/hla/home/mburger/singlevisits/results_2024-09-04/ibxl04/i*_flc.fits

For F502N, the relative fit uses the refimage 'ibxl04kbq', so the RELRMS* values for that dataset should be empty and each subsequent FLC should have slightly different values.

A promising result is that each filter set has a unique set of fitting results, however the relative and catalog fit RMS values should not be the same (see item 1 above).

See attachment ibxl04.png

 

3.) For the SVM images, the relrefim for all FLCs is the same (hst_12812_04_wfc3_uvis_f606w_ibxl04kp, see last column), which is good! On the other hand, the relrms_r and relrms_d values for that image should  not be populated or else cleared if they were previously populated (see item 2).  Again, the rms_ra and relrms_r values should not be the same.

/ifs/archive/dev/processing/hla/home/mburger/singlevisits/results_2024-09-04/ibxl04/hst*_flc.fits

See attachment hst_ibxl04.png

 

 4.) For the SVM image below, I see fitgeom='rshift' which should not be allowed. (only 'rscale'). In this case, there were fewer than 10 catalog matches, so it should skip eDR3 and go to the next catalog.

/ifs/archive/dev/processing/hla/home/mburger/singlevisits/results_2024-09-04/ibl738/hst*_flt.fits

IMAGE                                                                  NMATCHES  FITGEOM. WCSNAME
hst_12286_38_wfc3_ir_f125w_ibl738k2_flt.fits  7                  rshift       IDC_w3m18525i-FIT_SVM_GAIAeDR3

[s-goldman]

Work continued in #1878