Egocentric Cutting and Food Prep Video Data (Slicing, Chopping, Peeling)

Egocentric cutting and food prep data is first-person video of a person slicing, chopping, dicing or peeling food, recorded from the contributor’s own point of view with synchronized sensor streams alongside. The camera sits on the head, close to what a robot’s onboard camera would see over a cutting board, so the frames show what the hands are doing to the ingredient and the tool rather than a distant view of someone standing in a kitchen. On this site it is a custom collection: you name the cut, the ingredient and the setting, and capture is run to that written skill spec.

The data is human capture. A paid, consented contributor wears the rig and performs the task. It is not robot or teleoperation data, and it is not a fixed corpus you download. This page is narrower than egocentric cooking video, which covers food preparation as a whole, and narrower than kitchen pretraining at scale and food-service capture, each of which has its own page. The subject here is the cutting family of food-prep tasks: which of them the site states it can capture, how they are specified, what makes them hard to record, and how the episodes are labeled and checked before delivery.

The phrases people use for this are close cousins: a food prep video dataset, egocentric slicing and chopping video, cutting robot training data, or custom food preparation data collection. They describe one request from different angles. Whichever wording you start from, the work is the same: write down the cut, collect it on demand from real kitchens, and receive validated episodes with the labels a training pipeline expects.

NVIDIA’s GR00T N1 paper describes a data pyramid with web data and human video at the base, synthetic data in the middle and real robot trajectories at the top. First-person human video of food preparation sits in that base layer. It is far more abundant than robot data, and a person can work through many kitchens without the safety and access problems of putting an early-stage robot near knives, hot surfaces and hot liquids. For cutting specifically that safety point is the practical case for human capture: the demonstrations come from people, in the kitchens where the robot will eventually work, and nobody has to supervise an unfinished robot holding a blade.

Cutting is also a clean test of manipulation skill because it is bimanual by default. The site describes knife work as exercising fine bimanual dexterity, tool grip and control, and notes that chopping, pouring and transferring a loaded pan are bimanual in a kitchen, so a spec has to name bimanual coordination explicitly rather than treat it as a rare case captured incidentally. A single clip of a hand on a knife does not carry that. Both hands, their relationship to each other and to the ingredient, and the moment the blade meets the food all have to be present in the episode.

Variety across people matters as much as variety across kitchens. Capturing the same tasks performed by different people, at different paces and with different habits, including left- and right-handed knife work and different chopping styles, keeps a model from overfitting to one person’s technique. Generalist’s GEN-0 write-up makes a related point in different words: "data quality and diversity matters more than sheer volume." A corpus that repeats one board, one knife and one person does not generalize better than one that visits many distinct kitchens and contributors.

Public corpora are captured for someone else’s task distribution. EPIC-KITCHENS-100 is the reference example: its paper describes 100 hours of unscripted footage from 45 kitchens recorded with head-mounted cameras, and its authors report that adding more data saturated and that the results highlight the need for more diverse data rather than merely more data. A custom collection lets you aim at the cut, the ingredient and the setting your model is missing, instead of hoping a public release happens to contain them.

Four rows of the site’s commercial task catalog name a cutting task explicitly. Each is listed with a skill level, a capture setup and a status exactly as the catalog states them, and the table below reproduces them. In the restaurant and commercial kitchen environment the catalog lists chopping and portioning vegetables with a chef’s knife and cutting board, described as washing, trimming and chopping vegetables into even pieces and portioning them into containers, and a broader culinary chef and knife-work task described as breaking down produce and proteins with precise knife cuts and cooking dishes on a professional line. Both are marked as active collection.

In the working kitchen set for food prep the catalog lists peeling and chopping vegetables with a knife, and slicing bread and spreading a condiment. Both are marked as available on request. Peeling appears only in that peel-and-chop row, and slicing as its own task appears only in the bread row, so those are the two phrasings to use when you want to cite what the site already states. Alongside these, the kitchen task categories documented on the site include knife work: dice, julienne and chiffonade.

Neighboring food-prep rows exist that do not name a cut. Back-of-house food preparation, staging, portioning and storage is listed as a food prep task, and catering lists bulk food preparation of vegetables, proteins and sauces in large batches. Those fit a spec that includes cutting as one step, but the catalog does not describe a cut in them, so this page does not claim one. The site’s skill-spec guide offers a worked example of the shape a cutting spec takes: dicing an onion with a chef’s knife, requiring both hands visible at grasp and first cut and budgeting hours across daylight, low light, cluttered and failure-case conditions.

A cut, ingredient or technique outside those rows is a skill-spec question to settle in a Spec Pilot rather than an assumption. The catalog is a list of what is captured or available, not a ceiling on what can be briefed.

A food-prep collection uses the same capture stack as every Firsthand program. The instrumented tier is a head-mounted stereo rig that records first-person RGB, with a metric depth stream recovered from the calibrated stereo rig rather than from a standalone depth sensor, and 6-DoF IMU data at 200 Hz from head- and wrist-mounted sensors. The wider stack is ten streams: a 4K head camera, two wrist cameras, depth, IMU, 3D hand and body pose, instance segmentation and action labels, hardware-aligned under 2 ms. The two wrist cameras give a second, closer view of the hands than the head camera alone, which matters when a hand wraps around a handle.

Every stream is hardware-triggered onto one PTP clock domain, so depth, motion and hand pose line up with the same video frame rather than being approximated afterwards. The rig is calibrated twice per session, before capture starts and after it ends, and an episode is accepted only if RMS reprojection stays under 0.28 px. The catalog lists the capture setup per task: a head-mounted phone or multiview rig for the restaurant and commercial kitchen rows, and a multiview rig with handheld grippers for the food-prep working-kitchen rows. Which tier applies to your program is set in the skill spec.

Depth is the stream to plan around in a kitchen. Wet and reflective surfaces degrade it, and a rinsed board or steel sink is exactly where cutting happens, so kitchen episodes ship per-frame depth confidence maps and you can mask low-confidence regions instead of trusting them. An episode with more than 35 percent invalid depth pixels in the manipulation region goes to the reject log. Heat is not sensed, force and tactile readings are not among the streams, and no robot or teleoperation data is captured.

Each attempt is delivered as one episode. Inside it, action segments divide the episode into start- and end-timestamped spans, each carrying start_ns, end_ns, verb and noun. For this task family, a segment can be one cut as written in the skill spec, so a dice becomes a sequence of labeled cuts rather than one long clip. The other standard fields are hand_joints and hand_visible for 3D hand pose, contact_events for the moment the hand meets the item, objects, and instance_masks, stored at the depth resolution of 848×480 so they line up with the depth stream.

Hand pose is delivered for both hands with a per-joint visibility flag for occluded fingers. That is the label that carries the bimanual structure of cutting: where the guiding hand sits relative to the blade hand across the whole cut. Contact events mark when the hand meets the ingredient or the tool, and per-frame instance masks follow produce as it changes shape instead of relying on masks propagated between frames.

The site does not list labels for the quality of a cut. There is no stated label for cut thickness, uniformity or evenness, no stated food-state label such as doneness or temperature, and no stated ontology of cuts beyond the verb and noun on each action segment. If your pipeline needs a cut-type taxonomy, the verb and noun vocabulary is something the skill spec defines with you, and anything beyond it is a scoping conversation, not a delivered field.

Validation runs against signed accept criteria written into the spec before capture. Each batch goes through per-batch QA and a reject log ships with it. Episodes are machine-checked against stated reject criteria: a sync breach beyond the ceiling for more than three consecutive frames, calibration drift beyond tolerance, the manipulated object out of frame for more than 15 percent of the episode, more than 35 percent invalid depth pixels in the manipulation region, an undocumented bystander, or a mismatch against the named skill spec. A human reviewer then checks each episode against the task spec. The worked dicing example in the skill-spec guide adds the shape of a cutting-specific reject rule: an item is rejected when the cut is off-frame for more than two seconds or a second person’s hands enter the manipulation region.

Only footage that clears the criteria is billed as a validated hour, and rejected items are recaptured at our cost. Many teams start with a Spec Pilot, a small, fast first batch that proves the spec and the accept criteria on real footage before volume scales.

Capture happens inside lived-in or working kitchens. Every contributor signs a written release before capture, and each delivered episode links to that record through consent artefact IDs in the batch data card. The consent chain has six checkpoints, from before capture to after delivery, and a break at any one discards the footage rather than shipping it at a lower grade. At ingest, automated detection finds faces, plates and screens and blurs them irreversibly, and speech is scrubbed of names, addresses and card numbers while ambient audio is kept. A human reviewer confirms that no un-consented person is identifiable in any frame, and footage that cannot be de-identified is discarded.

On safety, the site’s stated point is about the robot, not the contributor: human capture avoids running an early-stage robot near knives. A contributor knife-handling protocol is not stated on this site, so this page does not describe one. None of this is legal advice, and the executed agreement controls.

From signed spec to first validated batch, the timeline is a median of 48 hours where coverage is deep and three to four weeks where it is thin and contributors need to be recruited first. Speed comes from a warm pipeline, not from cutting consent, review or anonymization. After the first batch, on-demand top-ups run against the same accept criteria, so you can add more cuts, ingredients, kitchens or variation without rewriting the spec. The site does not state a turnaround for those later batches, so plan them in your quote.

Delivery is in the format your stack already reads: RLDS, LeRobot, WebDataset, HDF5, zarr or Rerun .rrd, or raw streams with metadata. Readable converter source ships alongside the data so the schema can be retargeted to your own loader. Collections are billed per validated hour.

The license is perpetual, irrevocable and worldwide, with the data buyer-owned and non-exclusive by default. Training, evaluating, fine-tuning and deploying models, including commercial ones, is permitted, and exclusivity is available as a separate term. The executed agreement controls. The site does not publish a price list, a minimum order, or a batch size for this task family, so those are set in your quote.

Where this site does not state something, this page says "not stated" rather than filling the gap. The table below separates what is delivered from what is not stated. There is no listed label for cut quality, thickness or uniformity, no food-state label such as doneness or temperature, no force, tactile or thermal stream, and no blade-contact force value. Nothing here claims a training outcome or a model improvement.

The tradeoff to plan for is the embodiment gap between a human hand and a robot end-effector, which retargeting or pairing with robot data has to close. What you get is human first-person demonstrations in which the hands, the ingredient and the step structure are explicit. Counts of kitchens, contributors, hours and cuts are not fixed numbers on this site; they are set in your skill spec.

Describe the cuts or food-preparation tasks, the ingredients, the kitchen types and the failure or variation cases your pipeline is missing. That becomes a written skill spec, quoted for reach, timeline and price before any capture begins, and most programs run a Spec Pilot first. The scoping checklist below maps the five parts of a skill spec onto a cutting request. A published home-cooking sample recording is on the sample data outputs page if you want to see the streams before you write a spec.

Three choices matter most for this family. Name the cut and the ingredient rather than a broad activity, because that is what lets each cut become one action segment. Name the kitchen types and the participant mix, since different kitchens present different boards and clutter, and different people cut differently. And name the lighting: daylight coverage fills fastest, while evening, low-light capture is the harder cell to fill.