Pops

The reusable pipeline every EyePop analysis runs through

A Pop is a reusable vision pipeline. It combines one or more models and abilities — models, prompts, and logic — into a workflow, and every image, video, livestream, or camera feed EyePop analyzes runs through one. Because a Pop is built by composing components, it is sometimes called a composable Pop; same thing.

Why Pops exist

Most real-world visual AI problems need more than one model. Reading a license plate means detecting a vehicle, locating the plate, cropping it, running OCR, and returning structured results. A Pop combines those steps into a single reusable workflow, so the intermediate crops never round-trip to your code.

Anatomy of a Pop

A Pop holds a list of components. The simplest Pop runs a single ability. An inference component identifies the ability it runs and any optional thresholds or output category; other component types handle operations such as forwarding, tracking, and turning segmentation masks into shapes.

Components at the top level run in parallel on the full frame. Sequencing is expressed by forwarding a component's output to the components that come next — which is what turns a list into a pipeline.

The reference is split across three pages: Pop Object for the pipeline's own shape, Components for every component type and attribute, and Forwarding for how they chain. Examples shows the common pipelines end to end.

Chaining components

A component can forward its output to further components. A crop forward passes each detected region downstream; a full forward passes the whole image. For example, a Pop can find people and then run 2D body points on each person crop.

The same shape covers the common pipelines: vehicle → plate → OCR, worker → PPE → violation, product → classification → inventory, and detect → crop → VLM.

Running a Pop

Use the Python SDK or Node SDK to attach a Pop to a worker session and hand it a source. The Quickstart shows the minimal flow in both languages; their complete guides are available from this site's navigation.

Inputs and outputs

A Pop accepts a source: Source Types covers every kind it takes, and Source Options the settings that shape how each one is processed. It returns structured JSON — bounding boxes, labels, counts, OCR text, tracking IDs, classifications, extracted fields, and VLM responses, depending on the abilities it runs.

Where a Pop runs

The same Pop definition runs unchanged in the cloud or on-premise. A persistent Deployment keeps one Pop continuously active with models pre-loaded, for low-latency and real-time workloads.

Best practices

• Start with the simplest workflow that solves the problem.

• Use detection to narrow the scope before running more expensive analysis.

• Hide intermediate stages the caller did not ask to see, rather than filtering them out in your own code.

• Test with representative production data.

• Reuse Pops across applications rather than duplicating workflows.

Next steps

• Pop Object — the shape of a Pop and how its top-level components run

• Components — every component type and its attributes

• Forwarding — chaining components, and what each one receives

• Examples — worked pipelines from one ability to multi-stage chains

• Models — the pretrained and custom models to name in an inference component

• Sources and Options — what you can submit to a Pop