Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-9623

Investigate posible matcher improvements

    XMLWordPrintable

    Details

    • Story Points:
      20
    • Sprint:
      Alert Production S17 - 2, Alert Production S17 - 3
    • Team:
      Alert Production

      Description

      This issue is a catch all for investigative work relating to DM-7366 that has blocked DM-8113.

      Optimistic pattern matcher B appears to preform poorly for dense stellar fields (6-10k reference stars per visit). This issue involves finding solutions, work arounds, and possible matcher improvements for both the current stack matcher and the pure Python implementation from a previous issue in this Epic. This involves finding ways to mitigate false positive matches reliably and discovering why the stack matcher fails immediately when running on dense stellar fields.

        Attachments

          Issue Links

            Activity

            Hide
            cmorrison Chris Morrison [X] (Inactive) added a comment - - edited

            Investigations into matching on extremely dense stellar fields (N stars of order 1k) has revealed the following:

            Using saturated stars is not recommended. Due to the high density of stars a large faction of the brightest N stars will be saturated if they are not specifically removed. This can cause outright failures to match or cause the matcher to wander after finding an initial match due to the centroid of the saturated object not being precise enough on subsequent match/WCS fit iterations. If attempting to match on dense stellar fields, it is recommended that the isGood flag be substituted in place of the isUsable flag.

            The starting match criteria and subsequent softening loops in both the stack and Python matchers are insufficient to remove false positives in the matching process. Specifically in the stack matcher the variable maxOffsetPix is not part of an the iterative process, that is searching for small matches first and then subsequently softening the max search distance allowed. Finding a suitable starting point for the matchers through statistics computed on the reference/source catalog or tightening tolerances when presented with a large number of reference objects may be required. It also my be worth pursuing changing the number of bright stars used to create a pattern to alleviate this false positive problem. How to figure out what complexity of pattern to match on the fly for a given density if stars is an open question.

            A possible solution to back off of the "optimistic" part of optimistic pattern matcher is to find several pattern matches from the brightest N stars and return the best match.

            Show
            cmorrison Chris Morrison [X] (Inactive) added a comment - - edited Investigations into matching on extremely dense stellar fields (N stars of order 1k) has revealed the following: Using saturated stars is not recommended. Due to the high density of stars a large faction of the brightest N stars will be saturated if they are not specifically removed. This can cause outright failures to match or cause the matcher to wander after finding an initial match due to the centroid of the saturated object not being precise enough on subsequent match/WCS fit iterations. If attempting to match on dense stellar fields, it is recommended that the isGood flag be substituted in place of the isUsable flag. The starting match criteria and subsequent softening loops in both the stack and Python matchers are insufficient to remove false positives in the matching process. Specifically in the stack matcher the variable maxOffsetPix is not part of an the iterative process, that is searching for small matches first and then subsequently softening the max search distance allowed. Finding a suitable starting point for the matchers through statistics computed on the reference/source catalog or tightening tolerances when presented with a large number of reference objects may be required. It also my be worth pursuing changing the number of bright stars used to create a pattern to alleviate this false positive problem. How to figure out what complexity of pattern to match on the fly for a given density if stars is an open question. A possible solution to back off of the "optimistic" part of optimistic pattern matcher is to find several pattern matches from the brightest N stars and return the best match.
            Hide
            krughoff Simon Krughoff added a comment -

            I would like to register that I would like to leave open the possibility of making isGood the default even in sparse fields. Other than that, this sounds good.

            Show
            krughoff Simon Krughoff added a comment - I would like to register that I would like to leave open the possibility of making isGood the default even in sparse fields. Other than that, this sounds good.
            Hide
            cmorrison Chris Morrison [X] (Inactive) added a comment -

            Completing ticket and reiterating Simon's suggestion to permanently use the isGood flag for all matching changing the signal to noise cut instead.

            Show
            cmorrison Chris Morrison [X] (Inactive) added a comment - Completing ticket and reiterating Simon's suggestion to permanently use the isGood flag for all matching changing the signal to noise cut instead.

              People

              Assignee:
              cmorrison Chris Morrison [X] (Inactive)
              Reporter:
              cmorrison Chris Morrison [X] (Inactive)
              Reviewers:
              Simon Krughoff
              Watchers:
              Chris Morrison [X] (Inactive), Simon Krughoff
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Jenkins Builds

                  No builds found.