Build an edge-case taxonomy for agricultural vision data

A crop-vision model can score well on familiar rows and still miss a weed in deep shade, mistake a rare plant for crop, or fail when wind and rain obscure the image. More examples help only if the dataset describes the conditions that make those examples hard.

Build an edge-case taxonomy before expanding an agriculture image annotation project. The taxonomy should let annotators record what is visible, what is uncertain and what condition may have affected the image. Keep those dimensions distinct. A single label such as “difficult image” hides the reason a model may fail and gives the team little direction for collecting the next batch.

Start with the error you need to diagnose

Write down the field decision the model supports: for example, identifying weeds for later review or separating crop from non-crop plants. Then list the errors that would matter in that workflow. A missed rare weed, a crop plant marked as weed and an image that cannot support a confident identification are different outcomes. They should not collapse into one error category.

Keep the annotation unit clear. If the task is plant detection, label each visible plant or plant region. If the task is segmentation, define which pixels belong to the plant and how to treat overlap. Record image-level conditions, such as glare or rain on the lens, separately from object labels. This separation makes it possible to ask whether errors cluster around a particular plant, capture condition or both.

Make weed categories useful without pretending certainty

Use a hierarchy. At the top level, distinguish crop, weed and other visible vegetation if those categories fit the task. Under weed, add named varieties only when the project has a reliable reference for identifying them and the distinction affects the model’s use. Keep a broader “unresolved weed” or equivalent class for cases where the image does not support a narrower label.

Do not make annotators guess a species from a blurred or partial view. Define what evidence is sufficient for a specific variety, and provide an uncertainty or review path when it is not. If a variety is visually indistinguishable at the available resolution, that is a taxonomy limitation—not an invitation to force a confident label.

Record abundance or crop impact only if the model needs it. A weed’s identity and its proximity to a crop plant are separate facts. A compact schema might therefore store plant class, variety where supported, confidence or review status, and relation to the crop as separate fields. Do not create a new label for every combination.

Describe light and weather as visible conditions

Lighting categories should describe the image, not guess the time of day. Define a small set of observable states: even light, hard shadow, partial shade, backlight or glare, for example. Specify whether annotators should tag the whole image, each object, or both. One frame can contain a sunlit row and a shaded plant, so a single image-level label may not be enough.

For weather, label evidence in the frame rather than a presumed forecast. Rain streaks, wet lens or foliage, dust, fog, snow, and wind-driven motion blur can be useful distinctions when they affect visibility. Keep weather separate from image quality: wind is a condition, while motion blur is an effect. The same effect can have other causes, and that distinction matters when investigating failures.

Do not create a long menu of rare conditions on day one. Start with conditions that occurred in your data or are plausible in the deployment environment. Add a category when it has an operational meaning and annotators can apply it consistently. Otherwise, use a review flag and revisit the examples with domain experts.

Test the taxonomy on a small, difficult sample

Draw a sample that includes ordinary images and suspected edge cases: uncommon weeds, harsh shadows, glare, wet foliage and motion blur. Ask annotators to apply the draft rules, then inspect disagreements by category. If reviewers disagree on whether a plant is a rare variety, revise the evidence rule or keep the label broader. If they disagree about whether a shadow belongs to the object or the scene, clarify the annotation unit.

XYNTRIQ’s stated workflow is to label a small sample against the client’s guidelines, share the output for review and provide a fixed-scope quote within 48 hours of pilot review. That can make a sample useful as a protocol test: provide the taxonomy and acceptance criteria, then check whether the returned labels answer the questions your model team needs answered. Treat the sample as a way to find unclear instructions, not as proof that the full dataset will represent every field condition.

Keep evaluation honest

Track counts for each important edge case and inspect errors by category. A strong overall score can conceal poor performance on a rare weed or a particular lighting condition. Keep “unknown” and “unusable” outcomes visible rather than dropping them from analysis; they show where collection or taxonomy needs work.

When creating evaluation splits, separate by field, date or location where possible. Randomly splitting adjacent frames can put near-duplicates in training and evaluation data, making performance look better than it will on a new field visit. Finally, compare the categories in the dataset with conditions observed after deployment. A taxonomy is useful only when it helps the team identify what is missing and collect the next, better-targeted batch.