Object Detection with Ultralytics YOLO

Hello! It's great to hear about your progress with detecting downy mildew on grapevines using YOLOv8. 🌿 The issue of color-based false detections in a real-time setting can indeed pose a challenge. To refine your model's ability to distinguish between actual disease symptoms and similar-colored objects, you might consider a few strategies:

1. Data Augmentation: Enhance your dataset with more varied lighting and background conditions. Incorporating images that have similar colors but are not the disease can help the model learn to discriminate better.

2. Fine-tuning with Hard Examples: Identify cases where the model currently fails and add more such examples to your training set. This could include images with objects that are similar in color to the disease but aren't the disease itself.

3. Adjust Confidence Threshold: Experiment with adjusting the confidence threshold of your detection. A higher threshold may reduce false positives but be careful to not miss genuine cases of mildew.

results = model.predict('image.jpg', conf=0.5)  # Adjusting confidence threshold

1. Post-Processing: Implement a custom post-processing step that considers additional context or rules specific to your problem domain, for instance, the typical size or shape of diseased spots, or their common locations on a vine.

It's a process of trial and error, so don't hesitate to iterate on these strategies. If you continue to experience issues, please share some examples or further details so we can offer more targeted advice. 🍇

@arifan-instrumentasi-UB hi there! 🌈

YOLOv8 is primarily designed for detecting objects and their categories, rather than the sequence or color composition of objects. It can recognize objects (like a rainbow) based on the training data it has been exposed to, but it doesn't inherently understand the "correct" color sequence of a natural rainbow.

However, you could approach the problem creatively by training your model on labeled data specifying "correct" and "incorrect" rainbows. Here’s a simplified example of how your training annotations might look:

• Image 1 (correct rainbow): Class label “rainbow_correct”
• Image 2 (rainbow with yellow replaced by orange): Class label “rainbow_incorrect”

This way, YOLOv8 could potentially learn to distinguish between the different types of rainbows based on your specific definitions of "correct" and "incorrect."

Remember, accurate detection relies heavily on the diversity and quality of the training dataset. 📊

Hope that helps!

For YOLO detection training, you should label all visible instances of the classes you want the model to learn in each training image; leaving same-class objects unlabeled usually turns them into false background and hurts training. If images are very dense, the usual workaround is to tile/crop them into smaller patches and use model-assisted pre-annotation plus active learning or the Ultralytics Platform annotation tools to reduce manual effort, and you can find more dataset guidance in the data collection and annotation guide.

Thank you for the helpful response. I will proceed with training a model on the initial annotations and integrate it into the active learning cycle. I have one follow-up question: if I train the model on small 640×640 patches cropped from a typical 5k×3k image, can I safely perform inference on the original 5k×3k images?

Yes—you can train on 640x640 crops and run inference on the original 5k×3k images, but if you infer at a small imgsz the objects may shrink too much after resize, so for dense/small targets the usual best practice is a larger imgsz or tiled inference with SAHI, as noted in the image tiling guidance.

Got point. Appricate your help on that, I do believe I will have more questions in project. :-)

Happy to help—feel free to post any follow-up questions here so the team and community can weigh in, and if you end up working with tiny or dense targets the small-object mAP guide has a few practical tuning ideas.

Thanks for further information, I see the sentence in guild "there are P2 model variants of the Ultralytics YOLOv8 model that are optimized for preserving fine spatial detail.", does it mean p2 yolo structure such as yolo26-p2.yaml? I plan use this to train my model. And one more question, if I use orignal image size 5k*3k to train model, and use SAHI to do inference, is it right approch for small object?

The project I am working on is a little bit tricky. It includes both dense and sparse objects with vastly different sizes. Some images just have a couple of big objects, but some images include over one hundred small objects. My plan is to label all of them first and train a YOLO model with the original image size of 5k × 3k using an imgsz of 1024 or higher. For the inference phase, I can use SAHI, but the question is, it seems like I cannot apply SAHI to all images because most of the images are sparse. So, how do I handle this situation?

Yes, the P2 note refers to the small-object architecture variants such as yolo26-p2.yaml; for training you’d normally use a scaled config like model=yolo26n-p2.yaml, and the YOLO26 model docs note these are YAML-only architectures. For your mixed dense/sparse case, using 5k×3k sources is fine but the model still trains at your chosen imgsz, so a practical setup is one model trained with all labels at the largest imgsz you can afford, optionally adding tiled crops for the densest images, then using normal inference by default and routing only the high-resolution or small-object cases to SAHI when you need extra recall.

Thanks, I will use yolo train model=yolo26x-p2.yaml pretrained=yolo26x.pt as training command. In terms of router, the key is I have to indentify the image is dense/sparse automaticlly, however, seems like no way to know if the image is dense/sparse before inference?

Correct—you usually cannot know dense vs. sparse reliably before inference, so a practical setup is a cheap first pass with normal YOLO at your target imgsz, then re-run only the uncertain high-resolution cases with tiled inference when you see no detections, very low confidence, or mostly tiny boxes; sparse images can stay on the standard object detection pipeline.

I see. I've completed an end-to-end cycle from labeling to prediction. Thanks for your help!

During the process, one issue I encountered is that some objects cluster together as a group, so I labeled them with one box and assigned the same label as a single object. The reason for this is that we still need to recognize the object group as well, not just individual objects. Is this the right approach? Or do we have to assign a new, distinct label for the grouped objects?

Another issue is that the predictor assigns multiple/duplicate labels to a single object, the boxes are most overlap. I tried using agnostic_nms and tweaking the iou parameter to reduce these multiple/duplicate labels, but it didn't work well. I am wondering if the final solution to eliminate multiple/duplicate labels is a custom post-prediction step? For example, calculating box overlaps manually and keeping only the one with the highest confidence score?

If a cluster is a different target from a single instance, give it a separate class such as object_group and apply that rule consistently; mixing single objects and merged clusters under the same class usually creates ambiguous supervision and can cause overlapping duplicates. I’d avoid a custom post-filter first—if you can share 2–3 labeled images and the matching predictions here, we can check whether this is a labeling consistency or small-object resolution issue, since with Ultralytics YOLO26 end-to-end inference and standard NMS behavior, persistent same-class duplicates are usually caused upstream rather than by a missing manual overlap step.

Understood. The situation is that there is no exact number of objects in a group—it could range from one to a hundred. This makes it difficult to decide which labels to create, so currently, I put them under the same label regardless of how many objects are in the group. What is the right approach here? Could this ambiguity be the root cause of the duplicate label issue?

I have attached 3 pictures (sorry I am not allowed to share data so I am using masks and fake labels):

Objects 1a and 1b represent an object group containing 3 individual objects. The inference outputs show two different-sized rectangles with the same label. (Confidence = 0.25, IoU = 0.70; changing IoU to 0.25 did not help, agnostic_nms=False).

Object 2 is a single object, but it produces two almost identical, overlapping rectangles with the same label. At a low confidence threshold of 0.10, both rectangles appear; changing it to 0.25 leaves just one.

Is this expected behavior given the IoU settings, or is it a result of the labeling issue?

Thanks again.

The better rule here is to define labels by visual granularity rather than count: annotate an individual object when it can be boxed cleanly, annotate a separate object_group class only when the cluster itself is the target or the instances cannot be separated, and avoid mixing large cluster boxes and tight instance boxes under the same class over the same region, since that teaches the model two valid box scales for one label and is a likely cause of your object1 duplicates; for object2, seeing two boxes at conf=0.10 but one at 0.25 is generally expected low-threshold behavior, and IoU mainly governs overlap matching rather than fixing class-definition ambiguity, so I’d standardize the labels before adding any custom post-processing.

Thank you very much, let me summarize to ensure I understand the label approach:

1. Define two labels: one for a single object (object) and another for an object cluster (object_group).
2. Annotate an individual object when it can be boxed cleanly — use the object label. 3.Use the object_group label when the cluster itself is the target or the instances cannot be separated. That means if there are multiple objects that cannot be separated and the cluster is the target, use the object_group label.
3. Avoid mixing large cluster boxes and tight instance boxes under the same class over the same region — I'm a little confused here: in one image, there must be both single objects and clusters, so how do I avoid mixing large cluster boxes (object_group) and tight instance boxes (object)? I guess the same region means object box and cluster object box overlap?

Yes—“same region” means overlapping annotations for the same underlying objects; in one image it’s fine to have both object and object_group, but they should be mutually exclusive by area: use object where instances can be boxed cleanly, and use one object_group box only for the dense patch where they cannot, without also boxing those same members individually. If you train both levels on the same pixels, duplicate predictions are very likely, so the key is a consistent one-representation-per-region rule as described in the annotation best-practices guide.

Thanks, understand the approach. Really appricate your help! Will let you know any further question. :)

Glad that clarified it; if any new edge cases come up, please share a couple of representative labels and predictions here before retraining and we can help sanity-check the annotation rule.

Thanks again! Yes for sure, we'll follow the annotation rule and how things go, keep you post if anything new.

Sounds good—after updating the annotations, please delete any *.cache files in your labels folder before retraining, and feel free to post back here if any edge cases still produce duplicate boxes.

Got it. Thanks for reminding. :-)

You’re welcome—if anything unexpected shows up after retraining, share a sample label/prediction pair and the yolo checks output here and the Ultralytics team can help verify it.

For surveillance, a strong default is Ultralytics YOLO yolo26s.pt for balanced speed/accuracy or yolo26m.pt for denser scenes, paired with model.track(..., tracker="bytetrack.yaml"); the detection guide and tracking docs are good references, and if you share your camera resolution, FPS, and hardware here in Discussions the Ultralytics team can suggest a tighter config.

For TensorRT *.engine models the GPU is effectively chosen when the engine is deserialized/loaded, and device= in model.predict() won’t “move” an already-loaded engine off CUDA:0; to avoid PyTorch’s default CUDA init grabbing GPU 0, set the device before creating YOLO(...) (or pin the process with CUDA_VISIBLE_DEVICES), as noted in our common multi-GPU troubleshooting guidance and predict docs.

import os

os.environ["CUDA_VISIBLE_DEVICES"] = "1"  # pin to physical GPU 1 (it becomes cuda:0 in-process)

from ultralytics import YOLO

model = YOLO("yolo26n.engine")  # load AFTER pinning
results = model.predict(source=stream_url, stream=True, device=0)

If you need to switch GPUs dynamically per stream/job, you’ll generally need separate processes (or separate containers) per GPU; also please paste !yolo checks plus nvidia-smi -L from inside the container and the full text logs showing the engine load so we can confirm whether the issue is GPU index remapping vs. early CUDA initialization.

I am using Python multiprocessing to offload inference input streams onto separate processes. In each process, I instantiate a YOLO model (TensorRT .engine file) for GPU inference.

I attempt to assign a specific GPU per process using:

os.environ["CUDA_VISIBLE_DEVICES"] = str(device)

However, even when device=1, the process still runs on GPU 0.

Environment

Inside the container:

nvidia-smi -L

Output:

GPU 0: NVIDIA GeForce RTX 2080 SUPER (UUID: GPU-xxxx...)
GPU 1: NVIDIA GeForce RTX 2080 SUPER (UUID: GPU-yyyy...)

On container startup, I see this warning:

/opt/venv/lib/python3.10/site-packages/torch/cuda/_init_.py:65: FutureWarning:
The pynvml package is deprecated. Please install nvidia-ml-py instead.
If you did not install pynvml directly, please report this to the maintainers
of the package that installed pynvml for you.
  import pynvml
INFO:     Started server process [1]
INFO:     Waiting for application startup

Worker Function (Per Stream Process)

def inference_worker(
    stream_url: str,
    frame_queue,
    idx: int,
    width: int = 640,
    height: int = 480,
    conf: float = 0.7,
    polygon: list = None,
    thread_name: str = None,
    camera_name: str = None,
    device: int = 0,
):
    """Runs YOLO inference in a separate process"""

    alert_thread = {}
    KNOWN_HEIGHT_CM = 155
    FOCAL_LENGTH = 1400

    # Attempt to set device per process
    os.environ["CUDA_VISIBLE_DEVICES"] = str(device)

    try:
        from ultralytics import YOLO
    except Exception as e:
        frame_queue.put(("_ERROR_", f"Import error: {e}"))
        return

    try:
        model = YOLO(model _path+ f"_{device}.engine")
    except Exception:
        model = export(intruder_path + f"_{device}.pt", device=device)
        return

Issue

Even when:

device = 1
os.environ["CUDA_VISIBLE_DEVICES"] = "1"

The inference still runs on GPU 0 instead of GPU 1.

This is almost always caused by Linux multiprocessing defaulting to fork: if your main server process (e.g. Uvicorn/FastAPI) imports torch/ultralytics (or anything that initializes CUDA/TensorRT) before the fork, the child workers inherit a CUDA context already bound to physical GPU 0, and changing CUDA_VISIBLE_DEVICES inside inference_worker() won’t take effect; the fix is to use spawn (or run 1 worker process per GPU as a separate OS process/container) and ensure CUDA-related imports only happen after the env var is set, per our multi-GPU troubleshooting guide.

# main.py (make sure ultralytics/torch are NOT imported at module top-level)

import multiprocessing as mp

def inference_worker(stream_url: str, device: int):
    import os
    os.environ["CUDA_VISIBLE_DEVICES"] = str(device)  # set BEFORE any torch/ultralytics import

    import torch
    from ultralytics import YOLO

    print("CUDA_VISIBLE_DEVICES:", os.environ["CUDA_VISIBLE_DEVICES"])
    print("torch sees", torch.cuda.device_count(), "GPU(s); current:", torch.cuda.get_device_name(0))

    model = YOLO(f"{model_path}_{device}.engine")
    for r in model.predict(source=stream_url, stream=True, device=0):
        pass

if __name__ == "__main__":
    mp.set_start_method("spawn", force=True)
    # start processes here

If this still pins to physical GPU 0, please paste the !yolo checks output from inside the container and confirm whether any part of your server imports torch before the worker processes are started.

Thanks alot Glen, this helped, I had an ocr code which was subtly initializing cuda contexts at container startup, thus preventing GPU selections using os.environ["CUDA_VISIBLE_DEVICES"] = str(device)

Glad that surfaced it — anything that touches CUDA (OCR libs, torch, TensorRT, etc.) must be imported/initialized only after CUDA_VISIBLE_DEVICES is set in each spawned worker (see PyTorch multiprocessing notes), and you can also swap pynvml → nvidia-ml-py to clear the deprecation warning you’re seeing.

你好，你看到的 float32[1,300,6] 是 YOLO26 的 NMS-free（端到端）检测头的输出，导出时使用 nms=False 会得到这种格式：300 表示最多保留的检测数（max_det），每个检测的 6 个值对应 x1, y1, x2, y2, conf, cls（cls 以 float 形式存储）。如果你想拿到未做 NMS 的原始输出用于自定义后处理，请使用默认设置导出（不设置 nms），此时输出为 (B, 4+num_classes, num_predictions) 结构，参考 导出文档里的输出张量说明，以及 端到端检测指南。

yolo export model=yolo26n.pt format=onnx nms=False  # (1, 300, 6)
yolo export model=yolo26n.pt format=onnx            # (1, 4+nc, N) 原始输出

如果方便的话，把你实际的导出命令（包含 imgsz / nms 等参数）和 ONNX 的 input/output 名称贴在这个讨论里，我们可以更精确地确认每一维的含义和坐标尺度。

Not specifically you can use the pretrained model of yolo you just ne to call on person id and reflect it on your processed frames. Class_id == 0 : person

@ShahnawazHusian to add new classes you should fine‑tune from your existing checkpoint on a dataset that contains both the old and new classes; YOLO doesn’t support “locking” all old weights and only appending new ones. By default all layers are trainable, but you can freeze early layers to preserve most features, for example:

from ultralytics import YOLO

model = YOLO("path/to/old/best.pt")  # model already trained on old classes

results = model.train(
    data="data_with_old_and_new_classes.yaml",
    epochs=100,
    freeze=10,          # freeze first 10 layers (backbone-heavy); head stays trainable
    lr0=0.001           # often use a smaller LR when extending a trained model
)

If you want to “re‑train” an existing class, just keep that class in your labels and oversample or rebalance your dataset; freezing the head/neck/backbone entirely would stop any learning. The freeze argument and related options are summarized in the training configuration docs.

@heymuun as @rugvedjalit mentioned, you don’t need to change the YAML or retrain if you only want the person class: you can filter at inference time with classes=0 (COCO’s person index), for example:

from ultralytics import YOLO

model = YOLO("yolo26n.pt")  # COCO‑pretrained
results = model.predict(source="video.mp4", classes=0)

This keeps the model size the same but returns only person detections; if you truly need fewer parameters, use a smaller model variant (e.g., yolo26n.pt) or retrain a nc: 1 model, though the parameter reduction from changing nc alone is quite small.

@legend-zhen Thanks for the traceback. Your checkpoint was saved with custom code (ultralytics.nn.add_modules) from a modified Ultralytics repo, but you’re loading it with the pip-installed package where that module doesn’t exist. Fix by either installing your modified repo into the same environment, or exporting to a format that doesn’t require the original Python classes:

# Option A: load with the same modified code
pip uninstall -y ultralytics
pip install -e path\to\your_modified_ultralytics

# Option B: export once from the environment where it loads, then use the artifact
yolo export model="D:\YOLO\YOLO11\ultralytics-main\runs\detect\train8\weights\best.pt" format=onnx

Please also run and paste the text output of:

yolo checks

to confirm you’re not mixing a local repo and a pip install; compare the Ultralytics install path it prints with the paths in your traceback. Export formats and usage are summarized in the Export guide and general troubleshooting tips are in Troubleshooting Common YOLO Issues.