Skip to content

Update Detect Step #127

@raymondwjang

Description

@raymondwjang

Overarching Philosophy

I can employ one of the two philosophies when it comes to gathering candidate cells and validating them.

  1. Gather slowly and accrue cells that I am only sure of. (Relax, breathe, one at a time)
  2. Gather everything, and update them as we go, validating and deprecating as we go. (Frantically gather everything and then sort them afterwards)

For various reasons, option 1 appears to be a better option. For one, it allows for a much better debugging experience. Secondly, once we have sufficient number of components, it becomes difficult to filter out "useless" components against backgrounds. It is nondeterministic how the algorithm would distribute brightness to this set of components, ripping a true component into arbitrary set of random components. Once this begins occurring, we would need to employ some parametrized model to siphon out "true" background and cell, but this banks on us having a solid parametrized model of background. (which I am unsure if I want to enforce)

Therefore, the detect logic has to be altered to:

  1. only add components when we're reasonably confident that it is a component
  2. remove footprints that causes error (without waiting for it to "get better" on its own)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions