Changeset 42289 for trunk/psastro

Timestamp:

Sep 23, 2022, 5:57:17 AM (4 years ago)

Author:

eugene

Message:

psastroUpdateChiptoFPA can fail on the inversion leaving behind a NULL chip->fromFPA. I have added a warning message to the log in psastroUpdateChiptoFPA. In psastroOneChipFit and in psastroMosaicOneChip, I add this condition ( fromFPA is NULL ) to the failure conditions and set bad chip quality. In psastroAstromGuessCheck, the NULL was making the loop skip the entry in the list of corner vectors making this comparison invalid ( mismatch between corners ) . The code now warns on NULL fromFPA and the failed chip is handled like other failed chips. Comments added to psastroOneChipGrid.c

Location:

trunk/psastro/src

Files:

• psastroAstromGuess.c (modified) (2 diffs)
• psastroMosaicOneChip.c (modified) (3 diffs)
• psastroOneChipFit.c (modified) (1 diff)
• psastroOneChipGrid.c (modified) (2 diffs)
• psastroUtils.c (modified) (2 diffs)

trunk/psastro/src/psastroAstromGuess.c

@@ -320 +320 @@
         if (!chip->process || !chip->file_exists || !chip->data_exists) { continue; }
 
-        if (!chip->toFPA || !chip->fromFPA) {
+        // if a chip fails during the calibration, the associated readout->data_exists
+        // gets set to false.  This may be the wrong solution, but it does not break this
+        // analysis here.  Note this is not the chip->data_exists field tested above.
+        // chip->data_exists is only false if the chip data is missing.
+
+        // chip->fromFPA can be NULL if the inversion fails, but I'm not sure
+        // chip->toFPA can be NULL unless it was not in the original model
+        if (!chip->toFPA) {
           char *name = psMetadataLookupStr (NULL, chip->concepts, "CHIP.NAME");
           fprintf (stderr, "no astrom model for %s, skipping\n", name);
           continue;
         }
-
-        // XXX we are currently inconsistent with marking the good vs the bad data
-        // psastroChipAstrom sets data_exists to false if the fit is bad.  this is
-        // probably wrong since it implies there is no data!
+        if (!chip->fromFPA) {
+          char *name = psMetadataLookupStr (NULL, chip->concepts, "CHIP.NAME");
+          fprintf (stderr, "inversion faiulre for %s (%d), will be skipped\n", name, view->chip);
+        }
 
         // skip chips for which the astrometry failed (NASTRO == 0)
@@ -350 +357 @@
         float astError = psMetadataLookupF32 (&status, updates, "CERROR");
         if (fabs(astError) < 1e-6) goto skip_chip;
+
+        // XXX EAM 2022.09.22 : a more robust analysis would put the corner points
+        // on the chip metadata so we can be certain the old and new corner values
+        // are correctly matched.
 
         psPlane ptCH, ptFP, ptTP;

trunk/psastro/src/psastroMosaicOneChip.c

@@ -148 +148 @@
     if (order == 1) { minNstar = PS_MAX ( 8, minNstar); }
 
+    // determine fromFPA transformation and apply new transformation to raw & ref stars
+    psastroUpdateChipToFPA (fpa, chip);
+
     bool validSolution = true;
 
@@ -162 +165 @@
     if (astNstar < minNstar) {
         psLogMsg("psastro", PS_LOG_INFO, "solution uses too few stars: %d < %d", astNstar, minNstar);
+        validSolution = false;
+    }
+    if (!chip->fromFPA) {
+        psLogMsg("psastro", PS_LOG_INFO, "toFPA/fromFPA inversion failure");
         validSolution = false;
     }
@@ -189 +196 @@
     psMetadataAddF32 (updates, PS_LIST_TAIL, "AST_MRY",   PS_META_REPLACE, "mosaic astrometry Y 10-90 percentile (arcsec)", results->dYrange * plateScale);
 
-    // determine fromFPA transformation and apply new transformation to raw & ref stars
-    psastroUpdateChipToFPA (fpa, chip);
-
-    //plot results
+    // plot results
     pmAstromVisualPlotMosaicOneChip(rawstars, refstars, match, recipe);
 

trunk/psastro/src/psastroOneChipFit.c

@@ -217 +217 @@
         validSolution = false;
     }
+    if (!chip->fromFPA) {
+        psLogMsg("psastro", PS_LOG_INFO, "toFPA/fromFPA inversion failure");
+        validSolution = false;
+    }
 
     // DVO expects NASTRO = 0 if we fail to find a solution

trunk/psastro/src/psastroOneChipGrid.c

@@ -84 +84 @@
     // adjust the chip.toFPA terms only
     pmAstromGridApply (chip->toFPA, stats);
-    psastroUpdateChipToFPA (fpa, chip); // updates PSASTRO.RAWSTARS and PSASTRO.REFSTARS
+    psastroUpdateChipToFPA (fpa, chip); // updates PSASTRO.RAWSTARS and PSASTRO.REFSTARS (see note below)
     psFree (gridStats);
     psFree (rawGridStars);
@@ -92 +92 @@
     return true;
 }
+
+/* if psastroUpdateChiptoFPA fails to invert the toFPA transformation, 
+   the ref->chip coordinates will not be set.  This is not a problem
+   at this stage since they are not used in the calculation.  Later
+   passes can still yield a valid solution.
+*/

trunk/psastro/src/psastroUtils.c

@@ -109 +109 @@
 
     psRegion *region = pmChipPixels (chip);
-
     psFree (chip->fromFPA);
     chip->fromFPA = psPlaneTransformInvert (NULL, chip->toFPA, *region, 50, 4);
     psFree (region);
+
+    // XXX EAM 2022.09.22 : for a specific case, psPlaneTransformInvert fails.
+    // This probably means the solution was poor in any case.  
+    // Some options:
+    // 1) skip the chip in psastroAstromGuessCheck (supply bad corners)
+    // 2) mark this chip as bad (return an error here and trap in psastroMosaicOneChip)
+    // 3) warn of the failure:
+    if (!chip->fromFPA) {
+        char *name = psMetadataLookupStr (NULL, chip->concepts, "CHIP.NAME");
+        psLogMsg ("psastro", PS_LOG_INFO, "WARNING: failure to invert toFPA for %s", name);
+    }
 
     // loop over cells in this chip
@@ -150 +160 @@
                     pmAstromObj *ref = refstars->data[i];
                     psPlaneTransformApply (ref->chip, chip->fromFPA, ref->FP);
+                    // if chip->fromFPA is NULL (non-invertable), the action is skipped
                 }
             }