Views: Turning a Question Into a Query

A DatasetView is a window onto a dataset: some subset of its samples, possibly reordered, possibly with parts of each sample hidden.

The property that makes it useful is that it is not a copy. Constructing a view does not duplicate images, does not write anything, and does not modify the dataset. It records what you asked for. The samples are fetched when something needs them, whether that is a loop in Python or the App rendering a grid.

So a view is closer to a saved question than to a result. Show me the images where the model predicted a stop sign with confidence above 0.9 and the ground truth has no stop sign is a view, and it costs almost nothing to construct.

That matters more than it sounds. If narrowing a dataset were destructive or expensive, exploration would be careful and rare: you would think hard before filtering, because getting back would cost something. Because views are free and non-destructive, the natural mode is to try a question, look, adjust, and try again, which is how you actually find things.

A view is built from view stages, each a single logical operation, applied in sequence so that each receives what the previous one produced.

The stages fall into a few families. Selection stages decide which samples pass: match on a condition, take a specific set of identifiers, exclude some. Ordering stages sort by a field or shuffle. Sampling stages limit to a count or take a random subset. Field stages control which parts of each sample come through, selecting or excluding fields. And restructuring stages change what a sample even is, for instance turning video samples into one sample per frame, or turning detections into individual patches.

Because each stage produces a view and each stage accepts one, they compose. A pipeline reads in the order it executes: filter, then sort, then limit.

The reason this shape recurs across tools, from database query builders to data frame libraries, is that it separates the two things you want to vary. What you are asking is the sequence of stages. When it runs is decided elsewhere, by whoever consumes the view.

The practical effect is that an investigation becomes an editable pipeline rather than a script you re-run.

There are two different things you might mean by filter, and confusing them is the most common source of confusion for people learning this tool.

Matching operates on samples. It decides which samples appear in the view, and the samples that appear are unchanged. Ask for samples containing at least one detection labelled dog, and you get whole images, each with all of its detections, including the cats and the cars.

Filtering labels operates inside samples. It decides which entries within a label field survive, and the set of samples is unchanged. Ask to filter detections to those labelled dog, and you get every sample, with only the dog detections visible on each, and samples with no dogs appearing empty.

Both are correct and they answer different questions.

The symptom of getting it wrong is recognisable. If you match when you meant to filter, the App shows the right images cluttered with irrelevant boxes. If you filter when you meant to match, you get a grid mostly full of images with nothing on them.

The two compose, and combining them is usually what you actually want: match to the samples containing a dog, then filter the labels to dogs only, giving relevant images showing only the relevant objects.

The clearest way to hold the distinction is as two independent axes, because a real question usually moves along both.

One axis is which samples. Matching, sorting, limiting and sampling all move along it, reducing a hundred thousand images to the two hundred worth looking at.

The other axis is what within each sample. Filtering labels, selecting fields and excluding fields move along this one, reducing a cluttered image with forty boxes to the three that are relevant.

The diagram shows a dataset narrowing along both. Neither axis substitutes for the other, and a question that only moves along one usually produces a view that is technically correct and hard to read.

There is a third move worth noting because it does not fit either axis: restructuring changes what counts as a sample. Converting a detection dataset into a patches view makes each detection its own sample, so a grid shows cropped objects rather than whole scenes. That is not narrowing, it is re-slicing, and it is the right move when the thing you are studying is the object rather than the image.

Conditions in these stages are expressions over fields, and the part worth understanding is how they reach inside label objects.

A detection is not a scalar. It has a class label, a confidence, a bounding box, and any custom attributes attached to it. So a condition can reference any of those: detections whose confidence is below a threshold, whose label is in a set, whose box area is small.

Because a sample holds a list of detections rather than one, conditions come in two shapes. Some ask about the list as a whole, such as whether any element satisfies a predicate, or how many do. Others apply per element, which is what label filtering uses.

The practically important consequence is that box geometry is queryable. Bounding boxes are stored in relative coordinates, so an expression can compute area or aspect ratio and filter on it, which makes questions like show me detections smaller than one percent of the image answerable directly.

That particular question is worth more than it looks. Small objects are where detectors fail, where annotation is inconsistent, and where evaluation thresholds behave oddly, and being able to isolate them in one stage is often the fastest route to understanding a disappointing metric.

The reason views deserve a lesson rather than a paragraph is that they are the common currency between every other part of the tool.

The App displays a view. Anything you can construct in code, you can look at, and any selection you make by dragging in the App comes back as a view.

Evaluation runs on a view. You can evaluate a model on a subset without creating a separate dataset, which is what makes per-slice evaluation cheap: evaluate on night images, then on day images, from the same dataset.

The analysis methods in the next lesson accept a view, so you can compute embeddings or quality scores on a subset rather than the whole corpus.

Export takes a view, which is how you produce a training set: define it as a query, export it, and the query is the record of what the training set was.

And annotation round trips take a view. Send the two hundred samples you decided need relabelling, not the dataset.

So the pattern across the whole tool is the same: narrow with a view, then do something to it. Learning the stages is most of learning the tool, and everything else is a verb applied to the result.

Views are the right default and there are two situations where you want something more permanent, and knowing which is which avoids both clutter and lost work.

A saved view is a named query stored with the dataset. It still computes on demand and still reflects the current data, so a saved view of samples needing review automatically includes anything that starts needing review later. This is what you want for a recurring question.

A materialised subset is a separate dataset containing copies of the samples. It is fixed: later changes to the source do not propagate. This is what you want when the exact contents matter and must not drift, which is the case for a training or evaluation set you will compare results against months later.

The distinction is between a question and a snapshot, and choosing wrong causes a specific problem. Treating a live view as a training set means the set changes underneath you as the data does, and an evaluation you cannot reproduce.

The usual practice is to define the training set as a view, because that documents the intent, and then export it, because that pins the contents. Both artefacts are worth keeping: the query explains why, the export says what.

Two limits are worth stating, because they mark where this lesson's technique stops and the next lesson's begins.

A view can only ask about what is recorded. Every stage is a condition over fields, so if the thing you want to find has no field, no query will find it. Show me the blurry images is not answerable unless something computed a blur score. Show me images similar to this one is not answerable unless embeddings exist. Most of the useful questions about a dataset are of this shape, which is exactly why the next lesson is about generating those fields.

And a view does not tell you what to ask. It is an instrument for checking a hypothesis, and the hypothesis has to come from somewhere. On a dataset small enough to skim, browsing supplies it. On a dataset of a million images, browsing supplies nothing, because a random sample of thirty images from a million tells you about the common case and the common case is not the problem.

So the honest summary is that views make checking cheap while leaving the harder half untouched. The analysis methods in the next lesson exist to attack that half: computing fields that surface where to look.