When growers ask us for an automated tree count, the request usually sounds simple: "Just point the model at the satellite image and tell me how many trees are in the block." The reality is messier.
The resolution problem
Most off-the-shelf detection models - including the ones trained on the popular VHRTrees and DeepForest datasets - were trained on imagery between 10cm and 30cm ground-sample-distance (GSD). Free public imagery in the United States is NAIP, which is 0.6m GSD. That's a 4-6x resolution gap. At NAIP scale, a young avocado tree might cover only 8-12 pixels - close to the limit of what convolutional detectors can resolve.
Domain gap
A model trained on Turkish hazelnut orchards captured from Google Earth doesn't generalize cleanly to California avocados captured from NAIP. The geometry of the canopies is different, the spectral characteristics of the imagery are different, and the background (bare ground, cover crop, irrigation hardware) is different.
What we do about it
Our current production pipeline does three things to compensate:
- Polygon-mask before inference. We black out everything outside the farm boundary so the model isn't tempted to detect riparian trees, neighbor blocks, or the parking lot.
- Ensemble YOLOv8 + Detectree2. Detectree2 catches detections that YOLO misses - at the cost of more false positives that we filter downstream.
- Per-detection model version tracking. Every detection is tagged with the model that produced it, so we can re-score historically when we ship a new model.
On the Esparto test farm, this gets us to about 459 of an estimated 800 trees - high precision, but recall is still the bottleneck.
The honest answer
If you need 95%+ recall on a mature orchard, you need higher-resolution imagery than free public sources provide. There are two ways to get it. Commercial 30cm imagery from Maxar or Planet costs real money and moves the recall ceiling substantially. Or you fly the block yourself, which is the route Persea supports today: a grower with their own drone gets centimetre-scale ground sample distance for the cost of an afternoon, and that is a different problem entirely from the one described above.
That is why our drone ingest runs on open formats - COG, GeoTIFF, LAZ, STAC - rather than on any one manufacturer's cloud. We do not want to have an opinion about which aircraft you bought. We do have an opinion about the payload: multispectral, so the NDVI coming off your drone is the same measurement as the NDVI coming off the satellite and can join the same series. A visible-band camera produces a picture, not an index, and we will not relabel one as the other - a visible capture gets the indices its bands can actually measure, and NDVI is not one of them.
The corollary is a refusal worth stating plainly. Captures from different sources do not get silently blended into one trend line. A satellite pass and a drone pass see different things at different scales, and quietly averaging them produces a chart that looks smooth and means nothing. Comparisons stay within a source until we can show the harmonisation is real, per index.
All of that ships now: open-format ingest, the multispectral-only rule, and the same-source refusal are in the product, not on the roadmap. Future posts will cover the super-resolution experiments we tried (and why they mostly didn't work).