Egocentric Catering and Event Kitchen Video Data

Egocentric catering and event kitchen video data is real-world, first-person video of work in a kitchen that prepares and serves food for events and institutions. It is recorded from the worker viewpoint, with depth, 3D hand pose, contact events and frame-accurate action segments aligned on one hardware clock. The tasks it covers are the ones the site states in its task catalog, under the Catering & Event Kitchen environment: banquet plating, bulk food preparation, and event service setup and breakdown.

The meal plating and serving page covers plating, portioning and serving across several environments, and the cutting and food prep page covers cutting and preparation. The food service page is broader. This page is about the catering environment itself, where the catalog describes work in batches and in sequence: many plates, large batches of prep, and a service area that is set out and then cleared and packed.

The site states catering work in one catalog environment, Catering & Event Kitchen, under the Food & Beverage sector. Its examples line reads "Hotel banquet kitchen, airline catering, hospital canteen, stadium concessions, event catering facility." Three task rows sit under it, one rated Easy and two rated Medium, and every one lists a head-mounted phone or multiview rig as the capture mode.

All three rows carry the status Available on request. The site defines that status as work scoped and recruited to spec when a buyer asks for it. None is marked Ready to deploy or Active collection, so this page does not claim that contributors or site access are already in place. The first table below lists the three rows as the catalog states them.

The catalog row is Banquet plating, described as portioning hot dishes onto plates in sequence, wiping rims and loading plates onto service trays. It is rated Medium. The order in the description is the useful part: portion, wipe, load, repeated plate after plate.

The word hot is catalog wording. The site states no temperature, holding or food-safety rule for this row, so none is claimed here. Dish and menu types, plate counts and tray types are Not stated and are set in the written spec. The same row also appears on the meal plating and serving page, where it sits with the other plating, portioning and serving rows.

The row is Bulk food preparation, described as prepping vegetables, proteins and sauces in large batches using hotel pans and commercial mixers. It is rated Medium. The pans and mixers are tool types the catalog lists, not models.

The catalog names three ingredient groups and a batch scale, not recipes. Specific ingredients, quantities, batch sizes and pan or mixer models are Not stated. The cutting and food prep page notes that the catering environment lists this row and that the catalog does not describe a specific cut in it, so this page claims no cut either.

Event service setup and breakdown is described as setting out chafing dishes, service stations and utensils, then clearing and packing them after service. It is the only Easy row in the environment.

It is the one row where the work is about the service area rather than the food. Setup and breakdown are two ends of the same row, so a spec can ask for one or both. Event sizes, guest counts, layouts and what is packed where are Not stated.

The catalog lists the three rows separately and does not state that they are performed in one event or by one worker. A spec can still name them as separate task families or chain them: prepare in bulk, plate in sequence, set out the service area, then clear and pack. That chain is a way to write a spec, not a claim about how any one event runs.

Action segments are what make a chain usable. Frame-accurate step boundaries separate prepping, plating, wiping, loading, setting out and clearing, aligned to video and depth, so a policy or a reviewer can tell where one step ends and the next begins. How many segments an episode holds is Not stated.

The catalog places the work in the catering and event kitchen settings its examples line names, and the environment page states that contributors are recruited to spec in Western program markets, so the footage reflects how this work is done in North American and European businesses. The site names no venue, caterer, company, city or region, and it does not state capture at a customer own site. Access and schedule are agreed in the spec, and the number of sites is Not stated.

The privacy steps the site states are these. Every episode links to a signed contributor release through a documented consent chain, and the consent record is part of the delivery. Faces, plates and screens are detected and irreversibly blurred at ingest, a reviewer confirms the result before anything ships, and the anonymization record is delivered with the data. Physical-safety measures, PPE rules, hygiene rules and venue access terms are Not stated.

A head-mounted phone records the first-person view of real work on site, and a multiview rig adds synchronized third-person angles when the spec asks for them. All three catering rows list this single setup. On the rig tier, every stream is hardware-triggered onto one PTP clock domain, and the rig is calibrated twice per session, before capture starts and after it ends. An episode is accepted only if RMS reprojection stays under 0.28 px.

Camera count, resolution and frame rate for catering work are Not stated, so session length and volume are quoted against your spec.

Each episode follows the Firsthand episode schema: ten streams synced under 2 ms, with head and wrist RGB, depth, 3D hand pose with per-joint visibility, contact and grasp events, and frame-accurate action segments. In a catering kitchen, hand pose tracks how the fingers hold and place each item, contact events mark when fingers meet a plate, a pan, a tray or a utensil, and action segments mark each step.

Object labels use the terms your spec sets. Force or tactile data, and success or quality labels, are Not stated for these rows. If your policy needs them, they are defined in the spec. Tactile gloves are a separate capture tier with their own page.

Delivery formats are RLDS, LeRobot and WebDataset, plus HDF5, zarr and Rerun .rrd. The format table below sets each against what its official documentation states. Action segments are the step labels, and any further object labels follow the spec.

Every batch is validated against signed accept criteria before it ships, with a reject log, and delivery is rolling, per validated batch. Billing is per validated hour, and rejected items are recaptured at our cost.

A survey of more than 150 studies states that, compared with rigid objects, deformable object manipulation poses significant challenges for perception, modeling and manipulation, because deformable objects have an infinite-dimensional state space and complex dynamics. The same survey states that data-driven approaches can address some of those challenges.

The site does not state that vegetables, proteins or sauces are deformable, and the catalog names no specific item, so this page applies the survey only where your spec names deformable items. What the catalog does state is the shape of the work: large batches, plates portioned in sequence, and a service area set out and then cleared and packed. Repeating the same step across many items and many plates is hard to cover with a few recordings, which is why a spec names the tasks, the items and the number of sequences. Cycle times, repetition counts and error rates are Not stated.

Where coverage is already deep, the first validated batch lands in a median of 48 hours from signed spec. Thin environments typically take three to four weeks, because vetting operators there is the bottleneck, and we quote that up front. The site does not state which of the two applies to catering work.

All three catering rows are Available on request, so treat the timeline as the scoped-to-spec case until the quote says otherwise. On-demand top-ups run against the same spec and accept criteria after each training run.

You describe the catering tasks, items and sequence your policy needs. We turn that into a written spec covering tasks, environments, capture tier, annotation depth and accept criteria, then quote reach, timeline and price before any capture begins.

A Spec Pilot, a small and fast first batch, can prove the spec and accept criteria before you scale. Billing is per validated hour, a reject log ships with every batch, rejected items are recaptured at our cost, and every collection ships under a perpetual, buyer-owned commercial license.