Why do clips get rejected in egocentric data collection?
Most rejected clips in egocentric data collection fail for one of four reasons: hands leaving the camera's frame, a task that wasn't actually performed or wasn't the right one, sensitive content that shouldn't be in the dataset, or a technical problem like bad lighting or a recording cut too short.
Egocentric data quality is a first-person clip that shows the full task, clearly and safely, in a way a model can learn from. In practice, it just means a clip that clears all four of those checks. This matters most for physical AI and robotics training, where a model learns to grasp, move, or complete a task by watching exactly what the camera wearer's hands and body did.
A clip where the hands drift out of frame halfway through, or where the task shown doesn't match what was asked for, doesn't just look messy. It teaches the model the wrong thing, or nothing at all, and that problem carries straight into egocentric data annotation. That's why collection teams reject it rather than keep it with a caveat.
What makes a clip get rejected for hands out of frame?
This is usually the single most common rejection reason. It looks exactly like it sounds: the camera wearer's hands drift below the frame, move too far to the side, or get blocked by their own body partway through the task, so the footage no longer shows what the hands are actually doing.
It happens more easily than it sounds. A head-mounted camera has a fixed field of view, and a task that involves reaching down, turning away from the camera, or working close to the body can push the hands out of shot without the collector even noticing in the moment.
A 2024 study on egocentric hand pose estimation, presented at ECCV, backs this up. The researchers found that two of their four headset cameras often failed to capture the hands in the frame, simply because of where those cameras sat relative to the task. When they combined all four camera views, their error dropped by about 6.5 percent compared to using one of the better-positioned cameras alone. In a real collection session, this kind of problem often isn’t spotted until someone reviews the footage.
FluxWheel, the egocentric collection app Mindkosh recently launched, catches this earlier, before it ever turns into a missing-hands problem a model has to work around after the fact. A per-project checklist the collector sees during recording, things like “both hands visible for the whole task,” gets confirmed clip by clip, and if hands still leave the frame, the clip gets flagged for re-take with that exact reason attached.
What task problems get a clip rejected?
Beyond framing, a clip can be technically clean and still get rejected because of what it actually shows.
Non-meaningful task
A non-meaningful task clip is one that doesn't actually meet the guidelines of the assigned task, so there's nothing in it worth training on. The hands might be visible the whole time, but if the collector wandered off-script or the action shown doesn't match what was asked for, the clip doesn't qualify.
Wrong task or banned task
A wrong task clip shows a real, completed action, just not the one the project called for, like recording "load the dishwasher" when the task list asked for "make tea." A banned task clip shows something the project explicitly excluded, usually for safety or scope reasons.
Large-scale robot data collection projects aren’t immune to this either. The DROID dataset, a large robot manipulation dataset built from real teleoperation sessions, collected close to 92,000 episodes in total.
Only 76,000 of those were marked successful and counted as the actual dataset. The other roughly 16,000 were labeled “not successful” and released alongside it, just not counted toward the final number. Even in a well-run, large-scale collection project, a meaningful slice of what gets recorded still doesn’t make the cut.
Mindkosh's FluxWheel app handles the setup side of this by configuring tasks per project, with instructions and an expected duration the collector sees before they start, plus a real-time alert if the scene goes static for too long, often a sign nothing meaningful is actually happening in frame.
What sensitive content gets a clip rejected?
Egocentric footage is captured in real homes, workplaces, and public spaces, so some clips will unavoidably catch something that shouldn't be in a training dataset: a bystander's face in frame, a child, personally identifiable details, violent or graphic content, or footage flagged as NSFW. This isn't a reflection of the collector doing anything wrong. It's just what happens when cameras follow real people through real environments, and it's why this category exists as its own check rather than being folded into "quality."
Mindkosh's pipeline treats this as a privacy step that happens automatically before anyone reviews the footage. Faces and other personally identifiable details are detected and redacted as the clip is ingested, and automated QA flags anything that looks unusable against the project's criteria before it ever reaches a human reviewer. It's the same idea behind Meta's EgoBlur, which automatically blurs faces and license plates in egocentric footage. How PII gets removed from egocentric footage covers this part of the pipeline in more depth.
What recording and technical issues get a clip rejected?
The last category is the most mechanical: a recording that's too short to be useful, lighting too poor to see what's happening, a lens that's blurry or out of focus, or dropped frames partway through. Some of these get caught automatically the moment the file is processed, since they're measurable without anyone watching the footage.
Mindkosh's app sets an expected duration per task and fires a real-time alert for low light, low battery, or a recording that's running unusually long, so the collector can fix the problem mid-session instead of finding out after the footage is already uploaded. How shutter type affects egocentric footage goes deeper into one specific technical failure mode: motion blur and skew caused by the wrong camera shutter.
Rejection reasons at a glance
Rejecting this much footage feels wasteful in the moment, especially when a team is watching their total hours climb slower than planned. But a dataset that keeps borderline clips instead of rejecting them doesn't actually save time.
It just moves the cost downstream, into a model that learned from footage that didn't show what it was supposed to show. Strict rejection at collection time is what keeps that cost from showing up later, when it's far more expensive to fix.
Why doesn't manual review scale, and what catches rejections instead?
A human watching every clip end to end doesn't scale past a small pilot. The fix is layering the checks so manual review only handles what actually needs a person:
- During capture, real-time alerts catch problems like low light or a static scene the moment they happen, while the collector can still fix the shot.
- On upload, automated QA checks the clip against the project's own criteria (duration, framing, basic technical thresholds) and flags anything that doesn't pass, before anyone has to watch it.
With the DROID dataset: a rejection there didn’t mean the footage was damaged or unsafe to use, it just meant the task attempt didn’t count as a clean success, which is why it still got released, just labeled and set aside. Not every rejection reason carries the same weight.
The Aria Everyday Activities dataset from Meta’s Project Aria research team shows a different problem. An unblurred face or license plate in frame isn’t a “didn’t go as planned” issue, it’s a real risk to the person who ended up on camera. That’s why Aria treated it as a hard stop: faces and plates were manually blurred, checked across multiple rounds of review, and anything that still failed was excluded completely rather than released with a caveat.
This is a case for tagging rejections by reason instead of just marking them pass or fail. The reason determines what happens next. A PII issue can often be fixed automatically, redact the face or plate without touching the part of the frame that shows the task, and the clip is usable again. A task issue, like the wrong task being attempted or never completed, usually can’t be patched the same way. It needs a re-take.
Mindkosh's app applies the same layering, and logs every rejection with its specific reason as it happens, so tracking rejections and re-takes is built into the workflow. It combines automated checks and leaves room for a systematic manual review. That’s what pushes dataset quality up collectively, without multiplying the manual review workload.
Is egocentric data quality the same as physical AI data quality?
Related, but not quite the same thing. Physical AI data quality more broadly covers sensor sync, calibration, and hardware accuracy across any kind of robot or sensor data. Egocentric data quality specifically is about what the camera wearer's footage actually shows, since the biggest failure modes here are framing and task content, not sensor hardware. A perfectly calibrated camera can still produce a clip that gets rejected because the hands left the frame.
How Mindkosh catches quality problems during collection
If rejected clips and endless re-takes sound familiar, Mindkosh's collection app was built to catch these problems early, before they cost you footage. Checklists and task instructions are set once per project, real-time alerts flag framing and technical issues the moment they happen, and every clip is auto-QA'd and PII-redacted on ingest, with a logged reason attached to anything that gets flagged. The goal isn't catching bad footage after the fact. It's catching it while there's still time to fix the shot.
FAQ
What is the most common reason egocentric clips get rejected?
Hands leaving the camera's frame is typically the most common cause. It happens easily since a head-mounted camera has a fixed field of view, and a task that involves reaching, turning, or working close to the body can push the hands out of shot without the collector noticing.
What makes egocentric data high quality?
A high-quality clip keeps the hands visible for the whole task, actually shows the task that was assigned, contains no sensitive or identifying content that shouldn't be there, and is technically clean: well lit, in focus, long enough, and free of dropped frames.
Can a rejected clip be fixed, or does it need a re-take?
It depends on the reason. A sensitive content issue, like a bystander’s face in frame, can often be fixed by blurring that part of the frame, and then the clip is usable again. A task issue, like the wrong task or one that was never finished, can’t be patched and needs a re-take. The same goes for most technical issues, like bad lighting. A framing issue can sometimes be saved mid-session if the collector gets a real-time alert before they finish recording.
How do you check egocentric data quality at scale?
By layering checks instead of relying on manual review alone: real-time alerts during capture, automated QA against the project's criteria on upload, and human review reserved for the genuine edge cases that automated checks can't resolve on their own.
What is the difference between egocentric data quality and physical AI data quality?
Physical AI data quality is the broader category, covering sensor sync, calibration, and hardware accuracy across any robot or sensor data. Egocentric data quality is specifically about what the footage shows: framing and task content are the main failure points, more than hardware.
What does egocentric data mean?
Egocentric data is first-person video and sensor data captured from a head-mounted or wearable camera, showing a task from the collector's own point of view. What Is Egocentric Data? covers the full definition and how it's used.
See how Mindkosh catches quality problems during collection →
