graysonarts / graysonarts/aboutface
Sanity-check what the Embedding is actually keyed on
- Dominant language
- Rust
- Stars
- 0
- Forks
- 0
- PR merge metrics
- No merged PRs in 30d
Description
## What to build
Find out whether the Embedding is measuring faces or measuring the room, before anything is built on top of it.
The protocol from the implementation plan: capture the same person twice against different backgrounds and under different lighting, and two different people against the same background. If the two backgrounds separate one person more than the shared background separates two people, the Embedding is keyed on the room, and the crop and the lighting get fixed before any layout work starts.
This is the risk that comes with ADR-0007. DINOv2 is a general-purpose visual model, not a face model; it was chosen for apparent resemblance rather than identity, and the same property that makes it right for the piece is the property that could make it key on hair, wall colour, or window light. The plan gates Stage 2 on this deliberately.
Needs a human: it requires real people standing in front of a real camera in more than one room.
## Acceptance criteria
- [ ] A repeatable tool reports pairwise cosine distances across a labelled set of Captures
- [ ] The capture set covers one person x two backgrounds/lightings, and two people x one shared background
- [ ] The comparison in the plan is stated as a pass/fail result, with the actual numbers
- [ ] The result is written down in the repo, with the images or their provenance, so it can be re-run after a model or crop change
- [ ] If it fails: crop framing and lighting are adjusted and the check re-run until it passes, or the failure is escalated as an ADR revisiting ADR-0007
## Blocked by
- #9
Contributor guide
No contributing guide indexed for this repository
Research direction
Read blocked issue #9, ADR-0007, and the implementation plan first, then locate the Capture representation and the embedding entry point. Run the repeatable comparison over the labelled capture set, record pairwise cosine distances and the pass/fail result, and preserve the images or their provenance in the repository; if it fails, document the rerun or ADR escalation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- computer-vision, machine-learning
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Clearly specified
- Newbie friendliness
- 45/100