Logo Lanfrica

Data and Results for Maize Stand Counting (MaSC): Automated and Accurate Maize Stand Counting from UAV Imagery Using Image Processing and Deep Learning

Domaine:

agriculture

Type de record:

datasetmodel
Créateur:
KhaKaz
Éditeur:
Zenodo
Hôte:avatar

Maize Stand Counting (MaSC): data and results

Overview

This research data archive accompanies the paper:

Maize Stand Counting (MaSC): Automated and Accurate Maize Stand Counting from UAV Imagery Using Image Processing and Deep Learning

The archive provides the imagery, intermediate spatial transformations, object-detection outputs, row/range assignments, stand counts, and visualizations used to evaluate the MaSC workflow. MaSC detects individual maize plants in unmanned aerial vehicle (UAV) imagery and converts the detections into stand counts organized by field row and range.

The archive's primary research content is organized into three top-level directories:

  • data/ contains the input UAV raw frames and mosaics, including the pairwise homography matrices needed by the raw-frame workflow.
  • models/ contains the official YOLOv9 checkpoint used by MaSC and the YOLO11 and YOLOv12 checkpoints retained from the detector ablation study.
  • results/ contains the detection, spatial aggregation, counting, and visualization outputs for the processing modes reported in the paper.

This README describes release contents as deposited. It is intended to help readers inspect the published results, reuse the machine-readable outputs, and connect each artifact to the corresponding processing stage.

Citation

When using this archive, cite both the dataset and the associated paper.

Dataset

Dewi Endah Kharismawati & Toni Kazic. (2026). Data and results for “Maize Stand Counting (MaSC):
Automated and Accurate Maize Stand Counting from UAV Imagery Using Image
Processing and Deep Learning” (Version 1.0) [Data set]. Zenodo.
doi.org

Associated paper

Dewi Endah Kharismawati & Toni Kazic. (2025). Maize Stand Counting (MaSC): Automated and Accurate
Maize Stand Counting from UAV Imagery Using Image Processing and Deep
Learning. arXiv preprint arXiv:2510.07580; manuscript submitted to *IEEE Journal of Selected Topics in Signal Processing*. doi.org

DroneZaic method used to calculate the raw-frame homographies

The pairwise homography matrices in data/raw_mode/H_asift_group_002.csv were computed with the previously developed DroneZaic algorithm. Users of these transformations should also cite:

DroneZaic: A robust end-to-end pipeline for mosaicking freely flown aerial video of agricultural fields. DOI: 10.1002/ppj2.70033

Source code

The MaSC implementation, validation utilities, and future code updates are maintained in the MaizeStandCounting_MaSC Git…. To clone the repository, use git clone github.com. Cite the Zenodo dataset for the deposited data and results; follow the citation instructions in the code repository when reusing the software.

How the MaSC algorithm works

MaSC is an end-to-end system for converting low-altitude RGB UAV imagery into a stand count for each maize row. It was designed for inexpensive UAVs and affordable computing hardware, without requiring geographic coordinates for every image. The 2024 evaluation imagery was collected on June 12 at approximately 10 m above ground level. The broader image collection described in the paper used manually flown DJI Phantom 4 Pro and DJI Mavic 2 Pro UAVs at approximately 5–30 m above ground level, below 3.2 km/h, with nadir and oblique video recorded at 24 or 30 frames per second.

The two MaSC modes differ in how they place detections into a common coordinate system. After that step, they share the same orientation correction, range detection, row detection, and weighted stand-counting procedure.

Shared maize-seedling detector

Both modes use the YOLOv9 maize-seedling detector trained and benchmarked separately on the Maize Seedling Detection Dataset (MSDD). The detector operates on 640 × 640 pixel inputs with a confidence threshold of 0.30. YOLOv9 was selected because it achieved the strongest single-plant detection performance among the models evaluated in the associated MSDD study (reported mAP@0.5 of 0.916), while remaining fast enough for practical use.

YOLOv9 is the official and only detector used to produce the MaSC mosaic-mode and raw-frame results reported in the manuscript. The included YOLO11 and YOLOv12 weights are retained as ablation/benchmark artifacts from the comparative detector study. They allow researchers to inspect or repeat the model comparison, but they are not interchangeable with YOLOv9 when reproducing the reported MaSC stand counts.

The detector has three classes:

Class IDMeaningContribution to stand count
0Single maize plant1
1Two touching/grouped maize plants2
2Three touching/grouped maize plants3

This weighted interpretation is essential: the number of detection boxes is not necessarily the final number of maize plants. A double-class box adds two stands and a triple-class box adds three. The multi-plant classes address seedlings whose leaves overlap or whose plants appear as a tight group.

Included model checkpoints

PathRole in this release
models/yolov9_models/best.ptOfficial YOLOv9 checkpoint used by the MaSC pipeline and required to reproduce the reported MaSC detections and stand counts.
models/yolo11_models/best.ptBest YOLO11 validation checkpoint from the detector ablation/benchmark study; not used for the official MaSC results.
models/yolo11_models/last.ptFinal YOLO11 training checkpoint from the ablation/benchmark study; not used for the official MaSC results.
models/yolov12_models/best.ptBest YOLOv12 validation checkpoint from the detector ablation/benchmark study; not used for the official MaSC results.
models/yolov12_models/last.ptFinal YOLOv12 training checkpoint from the ablation/benchmark study; not used for the official MaSC results.

Use models/yolov9_models/best.pt for MaSC replication. The best.pt and last.pt names identify the validation-selected and final-epoch checkpoints, respectively, within their model-specific training runs.

Mode 1: pre-mosaicked image input

Mosaic mode accepts an RGB mosaic created by DroneZaic or another mosaicking system such as WebODM. Because a field-scale mosaic is too large for direct detector input, MaSC performs the following steps:

  1. Patchification: divide the mosaic into overlapping image patches. Patch size and overlap can be adjusted for seedling resolution; the paper recommends dimensions that are multiples of 640 pixels. The deposited DroneZaic-mosaic experiment uses 1280 × 1280 pixel patches with 10% overlap, corresponding to a 1152-pixel stride and 128-pixel overlap.
  2. Patch-coordinate recording: store the origin of every patch in the parent mosaic. The offsets and parent dimensions for this deposit are retained in attributes_1280.npz.
  3. Seedling detection: process each patch independently with YOLOv9 using a 640 × 640 model input and confidence threshold 0.30.
  4. Coordinate reconstruction: convert normalized patch detections to pixel coordinates and add the recorded patch offset to place every box in the full-mosaic coordinate system.
  5. Duplicate consolidation: apply non-maximum suppression (NMS) to detections from overlapping patches so a plant visible in two neighboring patches contributes only once.
  6. Spatial counting: use the consolidated detection centroids to identify ranges and rows, then calculate the weighted count for each row.

Mosaic mode is convenient when an orthomosaic or other premosaicked image already exists, but registration, interpolation, and blending can distort individual seedlings. The paper shows that WebODM mosaics may contain holes and misregistered or “melted” plants; MaSC nevertheless detected most seedlings in the evaluated WebODM example.

Mode 2: raw UAV frame input

Raw mode performs detection before image blending and uses DroneZaic transformations to combine detections geometrically:

  1. Frame and transformation generation: DroneZaic dynamically samples video frames with uniform overlap, performs lens and gimbal calibration, detects shot boundaries, estimates 3 × 3 homographies between successive frames, and constructs mini-mosaics to limit accumulated registration error. DroneZaic supports CorNetv3, CorNet, and ASIFT homography estimation; the transformations deposited here are the ASIFT results.
  2. Frame-level detection: run YOLOv9 directly on each frame without mosaic patchification. Each output record contains the class, normalized centroid, normalized width and height, and confidence.
  3. Pixel conversion: convert each normalized bounding box into frame pixel coordinates.
  4. Cumulative registration: accumulate pairwise homographies to transform detections from each frame into the coordinate system of the reference frame. The paper defines the pairwise transformation as H(i→i+1) and composes the required transforms to obtain the mapping from frame Fi to reference frame F0.
  5. Bounding-box transformation: transform all four corners of each detection using the cumulative homography, apply the global translation offset, and reconstruct an axis-aligned box around the transformed corners.
  6. Cross-frame duplicate consolidation: apply NMS with an intersection-over-union threshold of 0.25. When several overlapping boxes represent the same plant, retain the highest-confidence detection and suppress lower-confidence duplicates.
  7. Spatial counting: apply the same range, row, and weighted stand-counting procedure used for mosaic mode.

Raw mode preserves repeated observations of the same plant across overlapping frames. A plant missed in one image may be detected in a later image, after which NMS consolidates the aligned duplicates. This is the main reason raw mode can recover detections lost in a single view. Its accuracy depends on precise homographies: registration errors can prevent boxes from overlapping and therefore cause duplicated plants to survive NMS.

Shared range and row detection

MaSC supports both continuous production fields and genetic nurseries. In a production field, an entire continuous row can be counted without subdivision. In a nursery, unplanted alleys divide rows into ranges, and row positions may change between ranges because of terrain, row curvature, planting-density variation, and mosaic distortion. Nursery analysis therefore detects ranges first and then detects rows independently inside every range:

  1. Orientation normalization: calculate the excess-green (ExG) image and apply the Radon transform over angles from 1° through 180°. For each angle, compute the variance of the Radon projection. The angle with maximum variance represents the dominant row direction, and the image/detections are rotated so crop rows are horizontal.
  2. Centroid map: represent every consolidated detection by a value of one at its bounding-box centroid, forming a binary spatial map.
  3. Range signal: sum centroids along image height to obtain a one-dimensional signal across image width. Smooth it with a moving-average window equal to 1% of image width. Peaks indicate concentrated plant regions and troughs between consecutive peaks provide candidate range boundaries. Minimum peak separation is image width divided by the expected number of ranges; minimum trough separation is half that distance. The 2024 experiment expected seven ranges.
  4. Row signal within each range: sum centroids across the width of each detected range to form a signal along image height. Smooth it with a window equal to 1% of signal length, and detect peaks and intervening troughs using a minimum separation of 1% of signal length.
  5. Boundary refinement: remove candidate row boundaries lying within 20% of the median inter-gap distance from a peak. Processing each range independently lets row coordinates vary across the field.
  6. Weighted assignment: assign each detection to a row from its centroid position. Add one, two, or three plants according to its single, double, or triple class.
  7. Output: write indexed row counts to prediction_on_each_row.csv and spatial row rectangles plus counts to rows_coordinate_and_count.mat.

Performance reported in the manuscript

The two modes were compared with consensus manual counts collected June 18–19, 2024, six to seven days after the June 12 UAV flight. Three people counted each row independently and repeated disagreements until reaching consensus. This timing difference matters because additional emergence or mortality may have occurred between imaging and manual counting.

ModeMAE (plants/row)RMSE (plants/row)Bias (plants/row)Within ±2Within ±5
Mosaic0.6164.205.77−4.1042.7%68.1%
Raw frames0.9061.972.85−1.1966.8%93.5%

Both modes tended to undercount, as indicated by negative bias, but raw-frame processing agreed more closely with manual counts. The manuscript reports processing 83 full-resolution frames in 60.63 seconds, including 25.02 seconds for detection. The deposited data/raw_mode/raw/ directory contains the 77-frame segment described in this archive, so users should use the deposited file inventory—not the manuscript timing experiment—to determine the number of frames available here.

Archive summary

At the time this README was updated, the archive contained 473 files totaling approximately 1.98 GiB, including this README and LICENSE.txt.

ContentQuantityFormat
Raw UAV frames77PNG
Pairwise raw-frame homographies76 matricesCSV
Input mosaics2PNG
All image products310 PNG/JPG filesPNG, JPG
Text/CSV data products150 filesTXT, CSV
MATLAB data products4MAT
NumPy metadata products1NPZ
Trained model weights5PyTorch .pt
Associated manuscript1PDF

The two input mosaics are alternative representations of the same general type of field imagery. data/mosaic/global_mosaic_7.png is the DroneZaic/DMC mosaic used by the mosaic_mode results, while data/mosaic_odm/34_597_preprocessed.png is the ODM/WebODM mosaic used by the webodm_matlab results.

Directory structure

.
├── README.md
├── LICENSE.txt
├── models/
│   ├── yolo11_models/
│   │   ├── best.pt
│   │   └── last.pt
│   ├── yolov12_models/
│   │   ├── best.pt
│   │   └── last.pt
│   └── yolov9_models/
│       └── best.pt
├── data/
│   ├── raw_mode/
│   │   ├── H_asift_group_002.csv
│   │   └── raw/                         # 77 sequential UAV video frames
│   ├── mosaic/
│   │   └── global_mosaic_7.png          # DroneZaic/DMC mosaic
│   └── mosaic_odm/
│       └── 34_597_preprocessed.png      # ODM/WebODM mosaic
└── results/
    ├── raw_mode/                        # results generated from raw frames
    │   ├── yolo_result/
    │   │   └── labels/
    │   └── mosaic/
    ├── mosaic_mode/
    │   └── dmc_result/                  # results generated from DroneZaic mosaic
    │       └── fragment_1280/
    │           └── yolo_result/
    └── webodm_matlab/
        └── webodm_1920x1920/            # results generated from ODM mosaic
            └── fragment/

Detailed description of data/

data/raw_mode/raw/

This directory contains 77 sequential RGB UAV video frames:

24r_06_12_601_605_frame_000117.png
...
24r_06_12_601_605_frame_000193.png

The frame number is the final six-digit component of each filename. The sequence is continuous from frame 117 through frame 193. Each image is 1275 × 699 pixels and is stored as a 24-bit RGB PNG. Preserve the numeric filename order when reproducing pairwise registration or temporal processing.

data/raw_mode/H_asift_group_002.csv

This headerless CSV contains 76 pairwise projective transformations (homographies) calculated by DroneZaic for the 77-frame ordered sequence. There is one row for each adjacent frame pair. Each row contains nine floating-point values representing a 3 × 3 homography in row-major order:

h11,h12,h13,h21,h22,h23,h31,h32,h33

For row i, reshape the values as:

H_i = [[h11, h12, h13],
       [h21, h22, h23],
       [h31, h32, h33]]

The first matrix belongs to the first adjacent pair in the sorted sequence (frame_000117.png and frame_000118.png), the second belongs to frames 118 and 119, and so forth. As defined in the manuscript, each pairwise matrix H(i→i+1) maps coordinates from frame Fi to the following frame Fi+1. MaSC composes the pairwise transformations needed to map every frame into the coordinate system of reference frame F0. Preserve the stored precision and multiplication order when reproducing cumulative registration. Do not add a header row before loading the file as a numeric matrix. Loading and validation scripts are maintained in the MaSC GitHub repository rather than duplicated in this data archive.

data/mosaic/global_mosaic_7.png

This is the 5445 × 5178 pixel, three-channel DroneZaic/DMC mosaic used as input to the mosaic-mode workflow. It is the parent image for the 1280 × 1280 fragments and the results under results/mosaic_mode/dmc_result/.

data/mosaic_odm/34_597_preprocessed.png

This is the 8806 × 11565 pixel, four-channel (RGB plus alpha) preprocessed ODM/WebODM mosaic used by the WebODM/MATLAB workflow. The corresponding results are under results/webodm_matlab/webodm_1920x1920/. Files named no_alpha are RGB derivatives in which the alpha channel has been removed for downstream processing.

Detailed description of results/

Common detection-label conventions

Most files in a labels/ directory use one detection per line in an extended YOLO-style normalized format:

class_id x_center y_center width height confidence
  • class_id0 for a single plant, 1 for a two-plant group, and 2 for a three-plant group. These classes contribute one, two, and three plants, respectively, to the final stand count.
  • x_centery_center: center of the detected bounding box, normalized by image width and height.
  • widthheight: bounding-box dimensions normalized by image width and height.
  • confidence: detector confidence score.

To recover pixel coordinates for an image of width W and height H:

x_min = (x_center - width / 2) * W
x_max = (x_center + width / 2) * W
y_min = (y_center - height / 2) * H
y_max = (y_center + height / 2) * H

The WebODM aggregate prediction file is an exception and is described separately below.

results/raw_mode/

This directory contains the MaSC outputs produced by detecting maize plants in the 77 raw UAV frames and transferring/combining detections spatially using the pairwise registration information.

  • yolo_result/: 77 PNG images with detections rendered on their respective raw frames.
  • yolo_result/labels/: 77 extended YOLO-format detection files, one per raw frame.
  • bounding_box_mosaic.csv: 511 consolidated detections in headerless comma-separated extended YOLO format: class_id,x_center,y_center,width,height,confidence. Coordinates are normalized relative to the raw-mode mosaic product.
  • mosaic/2024-10-04_23-01-30_range02.png: reconstructed raw-mode mosaic used for spatial aggregation and inspection.
  • mosaic_with_bbox_fragment_raw.png: raw-mode mosaic with consolidated plant bounding boxes.
  • mosaic_with_range_fragment_raw.png: raw-mode mosaic with range divisions overlaid.
  • mosaic_with_row_fragment_raw.png: raw-mode mosaic with row divisions overlaid.
  • rows_coordinate_and_count.mat: MATLAB Level-5 file containing rowsz, a 28 × 5 float64 matrix. Each row follows [x_start, x_end, y_start, y_end, stand_count] in pixels.
  • prediction_on_each_row.csv: headerless 28 × 2 table containing [row_index, predicted_stand_count]. Indices are one-based in this file.
  • range_plot_original_smooth.png: diagnostic plot used to locate range boundaries from the spatial detection distribution.
  • row_gaps_on_range0.png: diagnostic visualization of row gaps for range 0.
  • final_stand_count_per_row.png: final raw-mode count visualization.

results/mosaic_mode/dmc_result/

This directory contains outputs produced from data/mosaic/global_mosaic_7.png.

  • fragment_1280/1280_fragment_*.png: 25 image tiles, each 1280 × 1280 pixels. Tiles overlap so detections near tile edges can be retained and reconciled.
  • attributes_1280.npz: NumPy archive containing object array att. The stored dictionary records the horizontal and vertical tiling offsets (h and w[0, 1152, 2304, 3456, 4608, 5760]) and source mosaic dimensions (height=5178width=5445channel=3). The 1152-pixel step with a 1280-pixel tile corresponds to 128 pixels of nominal overlap between adjacent full tiles.
  • fragment_1280/yolo_result/: the retained inference-result set. It contains 25 annotated tile images, a corresponding labels/ directory with 25 extended YOLO-format detection files, and mosaic_prediction_normalized_1280.txt, which stores the merged mosaic-level normalized predictions.
  • mosaic_with_bbox_fragment_1280.png: mosaic with consolidated bounding boxes.
  • mosaic_with_range_fragment_1280.png: mosaic with detected range boundaries.
  • mosaic_with_row_fragment_1280.png: mosaic with detected row boundaries.
  • rows_coordinate_and_count.mat: MATLAB Level-5 file containing rowsz, a 110 × 5 float64 matrix in the form [x_start, x_end, y_start, y_end, stand_count].
  • prediction_on_each_row.csv: headerless 110 × 2 table containing [row_index, predicted_stand_count]; row indices are one-based.
  • range_plot_original_smooth.png: range-boundary diagnostic plot.
  • row_plot_original_smooth.png: row-boundary diagnostic plot.
  • row_gaps_on_range0.png through row_gaps_on_range3.png: row-gap diagnostics for four zero-based ranges.
  • final_stand_count_per_row.png: final mosaic-mode count visualization.

The .npz metadata uses a pickled Python object. NumPy users must specify allow_pickle=True; load it only from a trusted copy of this archive. Refer to the MaSC GitHub repository for the corresponding loading code.

results/webodm_matlab/webodm_1920x1920/

This directory contains the alternative mosaic workflow based on the ODM/WebODM product.

  • 34_597_preprocessed_no_alpha.png: RGB image derived from the input mosaic by removing its alpha channel.
  • fragment/: 42 fragments (frag000001 through frag000042). For each fragment, the archive includes the fragment PNG, a TXT prediction file, and a JPG detection visualization, for a total of 126 files.
  • Fragment TXT files: detector output associated with each fragment. Interpret these together with the corresponding fragment image and the coordinate convention used by the WebODM/MATLAB pipeline.
  • 34_597_preprocessed_no_alpha_prediction.txt: 2,502 merged detections, one per line, in space-delimited pixel format class_id x y width height confidence. In contrast to the normalized files in labels/, these coordinate and size values are pixel-valued.
  • 34_597_preprocessed_no_alpha_with_bbox.png: RGB mosaic with bounding boxes.
  • webodm_yolo_detection.png: WebODM/MATLAB detection visualization.
  • attributes.mat: MATLAB Level-5 file containing structure att with tiling/image fields hwheightwidth, and channel.
  • rows_coordinate.mat: MATLAB Level-5 file containing rows, a 312 × 5 uint16 matrix in the form [x_start, x_end, y_start, y_end, stand_count].

Reproducing and checking the analysis

The deposited files support three levels of reproducibility: re-running plant detection when the paper's code and trained model are available, re-running spatial aggregation/counting from the detection text files, and directly verifying the published counts and figures.

1. Obtain the complete release

Download the Zenodo archive and extract it without changing the directory or filenames. Verify that data/ and results/ are siblings of this README. Zenodo provides checksums for deposited files; use those checksums to verify download integrity.

2. Select the processing mode

  • Raw mode: start with the 77 ordered images in data/raw_mode/raw/. Use H_asift_group_002.csv to associate consecutive frames and reproduce the same pairwise spatial registration. Per-frame detections are available in results/raw_mode/yolo_result/labels/.
  • DroneZaic mosaic mode: start with data/mosaic/global_mosaic_7.png, reproduce the overlapping 1280-pixel tiling using attributes_1280.npz, run the detector on each tile, and map detections back to mosaic coordinates using the stored tile offsets. Reconcile duplicate boxes in overlap regions before row/range aggregation.
  • ODM/WebODM mode: start with data/mosaic_odm/34_597_preprocessed.png, remove or ignore the alpha channel as required, reproduce fragmentation using attributes.mat, run the detector, and combine fragment predictions in the parent-mosaic coordinate system.

3. Reproduce detection

To reproduce the official MaSC results, use YOLOv9 with models/yolov9_models/best.pt, a 640 × 640 detector input, and the preprocessing and thresholds specified in the associated paper and MaSC source-code repository. Do not substitute the deposited YOLO11 or YOLOv12 checkpoints: those files belong to the ablation/benchmark study and were not used to generate the reported MaSC mosaic-mode or raw-frame results. The executable source and validation utilities are intentionally maintained on GitHub rather than duplicated in this data deposit.

For an output-only verification, compare newly generated detections against the deposited label files. Important checks include:

  • number of detections per frame/tile;
  • class ID and confidence values;
  • bounding-box positions after conversion to pixels;
  • duplicate handling in overlapping tiles or video frames; and
  • the final number and spatial distribution of consolidated plants.

4. Reproduce row and range assignment

Map each consolidated detection center into the common mosaic coordinate system. Use the row/range boundary procedure described in the paper. The deposited diagnostic figures (range_plot_original_smooth.pngrow_plot_original_smooth.png, and row_gaps_on_range*.png) allow the inferred boundaries to be visually checked.

For each region in rows_coordinate_and_count.mat or rows_coordinate.mat, count detection centers falling within the rectangle [x_start, x_end] × [y_start, y_end]. Be consistent about inclusive/exclusive boundary handling to prevent double-counting points lying exactly on a shared boundary.

5. Verify tabular results

The Python validation scripts are maintained in the MaSC GitHub repository. The following MATLAB checks provide a lightweight alternative for verifying the deposited table dimensions:

raw = load('results/raw_mode/rows_coordinate_and_count.mat');
raw_count_table = readmatrix('results/raw_mode/prediction_on_each_row.csv');
assert(isequal(size(raw.rowsz), [28 5]));
assert(isequal(size(raw_count_table), [28 2]));

dmc = load('results/mosaic_mode/dmc_result/rows_coordinate_and_count.mat');
dmc_count_table = readmatrix( ...
    'results/mosaic_mode/dmc_result/prediction_on_each_row.csv');
assert(isequal(size(dmc.rowsz), [110 5]));
assert(isequal(size(dmc_count_table), [110 2]));

6. Compare visual products

Compare reproduced results with the deposited *_with_bbox_**_with_row_**_with_range_*, and final_stand_count_per_row.png images. These files make coordinate-offset, tile-merging, row-orientation, and boundary-assignment errors easier to diagnose.

Coordinate systems and indexing

  • Image coordinates are in pixels with the origin at the upper-left, x increasing to the right and y increasing downward, unless the corresponding implementation explicitly converts them.
  • YOLO-style coordinates in labels/ and bounding_box_mosaic.csv are normalized to [0, 1] relative to the relevant image.
  • The WebODM aggregate prediction file contains pixel-valued positions and sizes.
  • MATLAB coordinate tables are one-based products of the original MATLAB workflow. Python and most image libraries use zero-based arrays; account for the indexing difference when reproducing crops or masks.
  • Files such as row_gaps_on_range0.png use zero-based range numbers, whereas prediction_on_each_row.csv uses one-based row indices.
  • The orientation and ordering of agronomic rows/ranges should be interpreted from the corresponding overlay images and the methodology in the paper, rather than inferred only from a filename.

Software and file-format guidance

  • PNG/JPG: readable with MATLAB, ImageJ/Fiji, OpenCV, Pillow, or similar image software.
  • CSV/TXT: numeric text without header rows; readable with spreadsheet software, MATLAB readmatrix, Python NumPy, or pandas.
  • MAT: MATLAB Level-5 files; readable with MATLAB load or Python scipy.io.loadmat.
  • NPZ: readable with NumPy. attributes_1280.npz contains an object array and therefore requires allow_pickle=True; load it only from a trusted copy of this archive.

Suggested Python packages for inspecting the deposit are Python 3, NumPy, SciPy, Pillow or OpenCV, pandas, and Matplotlib. Exact software and hardware requirements for re-running MaSC inference should be taken from the associated code release and paper.

Scope, limitations, and responsible reuse

  • This is a research data and results archive, not a standalone software distribution.
  • The archive contains inference inputs, outputs, and trained model weights. Source code and validation utilities are maintained in the MaSC GitHub repository. Consult that repository for environment and detector-configuration files needed for computational reproduction.
  • UAV appearance can vary with crop stage, cultivar, planting density, soil, residue, weeds, illumination, altitude, camera, motion blur, and mosaic quality. Performance measured on this dataset should not be assumed to transfer unchanged to other fields or acquisition conditions.
  • The images are image products rather than georeferenced GIS rasters in this deposit. No coordinate reference system or ground-control metadata is encoded in the PNG files; pixel coordinates should not be interpreted as geographic coordinates.
  • Detection confidence is not a probability of agronomic establishment. Users should choose thresholds based on their validation objective and report any change from the settings used in the paper.
  • The mosaic-mode yolo_result/ and raw-frame detection outputs were generated with the official YOLOv9 MaSC detector. YOLO11 and YOLOv12 weights are provided only for detector ablation/benchmark reuse.

License

Except where otherwise noted, this dataset is licensed under the Creative Commons Attributio… (CC BY 4.0). Users may share and adapt the material for any purpose provided that appropriate credit is given, a link to the license is supplied, and changes are indicated.

Any third-party software (including DroneZaic, the detector implementation, MATLAB, and WebODM) remains governed by its own license and is not redistributed by this archive unless explicitly included. The license status of the associated manuscript may be governed separately by its publisher.

Contact

For questions about the dataset, paper, or reproduction workflow, contact:

Dewi Endah Kharismawati, Ph.D.
The Ohio State University
kharismawati.2@osu.edu
orcid.org

Version history

  • Version 1.0 (2026): Initial Zenodo release supporting the MaSC paper.

Languages

Similaires