Crop Disease Detection with Computer Vision

A computer-vision project that classifies photos of crop leaves into disease categories (or a healthy class) using a fine-tuned convolutional neural network, and presents each prediction with a confidence score so a human can decide what to do next. The workflow is the classic image-classification pipeline — preprocessing, dataset preparation, augmentation, training, validation, testing, prediction — implemented with standard Python libraries and a pre-trained model, which keeps it achievable as a first machine-learning project.

>Predictions are screening aids, not diagnoses. A model output is a statistical guess based on the images it was trained on; it can be wrong, and it should never be treated as an authoritative agronomic diagnosis. This project does not recommend pesticides, chemicals, or treatments, and it never claims to guarantee crop protection or yield. Its job is to flag which leaves deserve a closer, expert look.

Who Is This For?

• Students looking for a first real computer-vision project — a complete pipeline they can build in a few weeks and explain end to end
• Agronomy students and extension teams who want a reproducible way to triage field photos before involving a specialist
• Small-farm cooperatives exploring cheap, phone-based plant-health screening
• Developers who want to practice transfer learning, evaluation, and honest model reporting

The Problem

Crop diseases spread quickly, and early symptoms are easy to miss. A farmer walking a large field cannot inspect every leaf; expert agronomists are scarce and expensive; and by the time a problem is obvious by eye, it has often already spread. What’s missing for most growers is a cheap first-pass screening tool: photograph a leaf, get a fast indication of whether it looks diseased and how confident the model is, and use that to decide which plants warrant a closer, expert look. Image classification is the right tool for this because the question is inherently visual — and modern transfer learning makes it feasible for a student project rather than a research lab.

How It Works

1. Collect and Organize a Dataset

The project starts from a public, labeled plant-image dataset — for example PlantVillage, a widely used public collection of leaf photos labeled with diseases and a healthy class. Images are organized into folders by class, and the dataset is split into train / validation / test sets before any training, using a class-balanced split so every disease appears in all three partitions.

2. Preprocess and Augment

Each image is resized to the input size the pre-trained model expects (for example, 224×224), normalized with the model’s expected channel statistics, and converted to batches. Augmentation — random flips, rotations, slight brightness and contrast shifts — is applied to the training set only, which teaches the model to be robust to how a photo was actually taken in the field (different angles, lighting, phone cameras). Test and validation images are not augmented, so evaluation measures the model on realistic, unmodified photos.

3. Fine-Tune a Pre-Trained Model

Instead of training a network from scratch, the project starts from a model pre-trained on a large general image collection (for example, a ResNet or EfficientNet backbone), replaces the final classification layer with one matching the project’s classes, and fine-tunes. This is the transfer-learning step that makes the project feasible on a laptop: most of the visual understanding is already learned, and the fine-tune teaches it the specifics of leaf textures and disease patterns.

4. Train and Validate

Training runs in epochs over the augmented training set; after each epoch the model is evaluated on the held-out validation set. Because plant-disease classes are often imbalanced (some diseases are far more common in the dataset than others), accuracy alone is misleading — the project tracks per-class precision, recall, and F1 alongside overall accuracy, and watches validation metrics to stop before the model starts memorizing the training set (overfitting).

5. Test on Never-Seen Images

The held-out test set — images the model never saw during training or validation — produces the final evaluation: a confusion matrix showing which classes are confused with which, and per-class precision/recall/F1. The confusion matrix is where the project learns its honest limits: if two similar-looking diseases are routinely confused, that is a finding to report, not hide.

6. Predict with Confidence

A small inference path loads the trained model and classifies a new photo, returning the predicted class plus the model’s confidence (the softmax probability) for every class, not just the top one. The UI shows the top predictions with their probabilities and marks low-confidence cases as “uncertain — check manually,” because a leaf photo taken in bad light deserves a different response than a clean, high-confidence one.

7. Visualize and Report

A simple results screen (or notebook) shows the image, the predicted classes with probabilities, and a per-class performance summary. A brief model card records the dataset, split, metrics, and known confusions so anyone reading the results understands what the model can and cannot do.

Key Features

• Train/validation/test split — class-balanced, created before training
• Augmentation pipeline — flips, rotations, brightness/contrast shifts applied to training only
• Transfer learning — pre-trained backbone fine-tuned to plant-disease classes
• Per-class metrics — precision, recall, and F1 alongside accuracy, because classes are imbalanced
• Confusion-matrix analysis — the project reports which diseases are commonly confused
• Confidence-aware predictions — top-k probabilities and an “uncertain” flag for low-confidence inputs
• Model card — dataset, split, metrics, and known limitations recorded with the model

Functional Requirements

User Stories

• As a student, I want to build a complete image-classification pipeline with transfer learning, so that I learn the full workflow rather than just running a notebook.
• As an agronomy student, I want per-class precision and recall, so that I can see exactly which diseases the model handles well and which it confuses.
• As a small-farm user, I want a confidence score with every prediction, so that I know when to trust the model and when to ask an expert.
• As a developer, I want a model card documenting the dataset and its limitations, so that nobody misreads the model as a diagnosis tool.

MVP Scope

Multi-class severity grading, a phone-camera capture flow, and per-plant multi-leaf analysis are natural second-phase additions.

Project Timeline

• Phase 1 — Environment and data (Week 1): Python setup, dataset download, folder inspection, and the train/validation/test split with a class-balance check.
• Phase 2 — Data pipeline (Week 2): Preprocessing, normalization, augmentation, and batching; a quick overfit check on a few images to verify the pipeline.
• Phase 3 — Transfer learning (Weeks 3–4): Pre-trained backbone, classification head swap, fine-tuning loop, and validation monitoring with early stopping.
• Phase 4 — Evaluation (Week 5): Test-set metrics, per-class precision/recall/F1, confusion matrix, and error analysis on the worst classes.
• Phase 5 — Inference and polish (Weeks 6–7): Prediction script/UI with confidence display, model card, and a short write-up of known limitations.

Testing Strategy

• Pipeline smoke tests — a batch of images flows from file to model input with the right shapes and normalization.
• Split-integrity tests — no image appears in more than one partition; class balance is reported.
• Overfit sanity check — the model can overfit a tiny slice of training data, proving the pipeline learns before scale-up.
• Evaluation tests — the metrics module matches hand-computed values on a small labeled batch; confusion-matrix dimensions equal class count.
• Confidence tests — an out-of-domain image (a non-leaf photo) produces a low-confidence flag or a documented fallback.

Security and Privacy Considerations

• Field photos are user data. The MVP runs locally; if a web version is built, uploads should be processed, not stored, and any stored examples must be explicitly consented.
• No treatment recommendations. The project classifies and reports; it must never output pesticide, chemical, or dosage guidance. That boundary is part of the product, not an afterthought.
• Honest failure modes. Poor lighting, blur, and unseen disease variants produce wrong predictions; the confidence display and model card exist precisely so this is visible.
• No fabricated metrics. Reported accuracy, precision, recall, and F1 must come from the project’s own evaluation runs — never invented or copied from other models.
• Dataset licensing. Public datasets carry licenses; the project records the source and terms and respects usage restrictions.

Success Metrics

• The full pipeline runs end to end on a laptop: split → augment → fine-tune → evaluate → predict.
• Test evaluation reports per-class precision/recall/F1 and a confusion matrix — not just a single accuracy number.
• The error analysis names at least two real confusion patterns (for example, two visually similar diseases) and what to do about them.
• A held-out field-style photo (different lighting than the training set) produces a visibly lower confidence than clean test images — proving the confidence signal works.

Common Challenges

• Imbalanced classes — rare diseases are underrepresented; per-class metrics and optional class weighting keep this visible rather than hidden behind accuracy.
• Overfitting — the model can memorize training images; validation monitoring, early stopping, and augmentation keep generalization honest.
• Visually similar diseases — some diseases look alike even to experts; the confusion matrix surfaces this and the project documents it instead of pretending the model is perfect.
• Real-world photos differ from dataset photos — lighting, angle, and background vary; the model card states that field performance may be lower than test performance.
• Small datasets — with few images per class, fine-tuning is fragile; augmentation and starting from a strong pre-trained backbone are the standard mitigations.

Learning Objectives

• Build a complete computer-vision classification pipeline with standard Python libraries.
• Understand transfer learning: what a pre-trained backbone provides and why fine-tuning beats training from scratch for small datasets.
• Reason about evaluation honestly: why accuracy is not enough, what precision/recall/F1 add, and what a confusion matrix reveals.
• Practice data discipline: class-balanced splits, augmentation boundaries, and no data leakage between partitions.
• Communicate model limits clearly — the confidence display and model card are as much a part of the project as the model itself.

Why This Idea Is Different

This project is the site’s first agricultural computer-vision Idea, and it sits in the CV family as a distinct job. The AI-Powered Campus Attendance via Facial Recognition classifies people — detecting and matching faces for attendance — and the Medical Image Annotation Tool for Researchers builds annotation workflows for researchers labeling medical images. This project classifies plant leaves to triage crop disease: a different subject, a different objective (screening field photos for expert review rather than identity or labeling), and a different audience (farmers and agronomy students rather than institutions or ML research teams). All three share the computer-vision foundation and the responsible-use framing — but #051 is agricultural plant-disease triage, not facial recognition and not medical annotation. It also follows the dataset-first research pattern of the Open-Source Medical Dataset Explorer for AI Researchers, which tackles the same “find a good public dataset and understand its limits” problem for medical data that this project faces for plant data.

What Similar Tools Exist

| Tool type | Approach | Limitation |
|———–|———-|————|
| Research-grade plant disease models | Large curated models from ag-tech labs | Not something a student can build or inspect end to end |
| Mobile “plant doctor” apps | Cloud photo diagnosis | Opaque, often unverifiable, sometimes diagnosis claims |
| Generic image classifiers | Any pre-trained model applied to photos | No plant-specific training, no honest per-class reporting |
| Manual scouting | Human experts walk fields | Expensive and scarce |

This project’s differentiators: a fully transparent student-buildable pipeline, per-class evaluation and confusion analysis, a confidence-aware screening boundary, and an explicit no-treatment-recommendation rule.

Technology Stack

• Python — the whole pipeline
• PyTorch or TensorFlow/Keras — model and training loop
• Pre-trained backbone (ResNet or EfficientNet family) — transfer learning
• torchvision / TensorFlow datasets + PIL — preprocessing and augmentation
• pandas + matplotlib — metrics tables, confusion matrix, charts
• Jupyter notebooks or a small Streamlit app — exploration and inference UI

Future Enhancements

• Multi-leaf analysis: classify all leaves in a photo, not one crop
• Severity grading as a separate regression task (mild / moderate / severe)
• Phone capture flow with on-device inference for field use
• Confidence-threshold alerting (“flag anything below X confidence for review”)
• Federated or privacy-preserving sharing of anonymized field images between farms

Related Ideas

• AI-Powered Campus Attendance via Facial Recognition — the CV family’s people-classification member; this project classifies plants instead
• Medical Image Annotation Tool for Researchers — annotation workflows for researchers; this project is a screening classifier
• Open-Source Medical Dataset Explorer for AI Researchers — the dataset-discovery pattern this project applies to plant data

Browse more Project Ideas · Beginner Ideas