Models Supported by Ultralytics#

Use as many classes as you need to distinguish at inference: if you only care about authenticity, train a 2‑class detector (“true”, “fake”); if you need per‑symbol IDs, use 31 classes (one per symbol)—explicitly labeling “fake” typically reduces false positives versus leaving them unlabeled; you can start with YOLO26 detect and your dataset YAML as usual:

yolo detect train data=symbols.yaml model=yolo26s.pt imgsz=960 epochs=100

Model overview and task setup are in the YOLO26 models documentation and the Detection task guide.

Use a single Ultralytics YOLO26 Segment model—it outputs both boxes and masks—start with yolo26s-seg for a good speed/accuracy balance, and scale up to -m/-l if needed; for 15 symbols, begin with roughly 100–200 labeled images per class (2k–5k total instances) and increase until validation mAP stabilizes, and use a larger input size for small characters (e.g., imgsz=960–1280):

yolo segment train data=your_symbols.yaml model=yolo26s-seg.pt imgsz=960 epochs=100

Model details: see the YOLO26 overview in the YOLO26 models documentation; segmentation specifics and best practices are in the Instance Segmentation task guide.

best.pt is the epoch with the highest validation “fitness” metric; for detection it’s mAP_50-95 (seg and pose add their mask/keypoint mAP_50-95), for classification it’s the mean of top‑1 and top‑5 accuracy, and Early Stop watches the same fitness (not val_loss) and stops after patience epochs without improvement (set via patience). Rising val_loss won’t trigger stopping if that fitness is still improving; see how fitness/metrics are computed in the Insights on Model Evaluation and Fine-Tuning guide: https://docs.ultralytics.com/guides/model-evaluation-insights/.

Ultralytics supports the original RT-DETR models (rtdetr-l and rtdetr-x) for training, validation, prediction and export, but RT-DETRv2 weights and architecture are not integrated. See the RT-DETR documentation for supported models and usage; for new projects, also consider YOLO26.

Yes, you can train a single YOLO-pose model to detect both classes. For objects without keypoints (players), simply set all keypoint coordinates to zero in your dataset annotations. The model will learn to ignore these zero-value keypoints while still detecting bounding boxes for both classes. For implementation details, see the Pose Estimation task documentation on handling mixed annotations.

This approach is efficient and avoids the complexity of running two separate models, though we recommend thorough validation to ensure keypoint absence doesn't degrade detection performance for non-keypoint classes.

@hemanthmandava945 for segmentation mask inaccuracies in LiDAR reflectivity images, consider fine-tuning the pretrained YOLOv8 model on a domain-specific dataset with augmentations tailored for reflectivity images. For multi-modal training (RGB + reflectivity), it’s advisable to preprocess and align modalities carefully to avoid introducing noise. Experimenting with separate models or fusing features at specific layers during training can help. For more insights, refer to the YOLOv8 documentation. Let us know if you need further clarification!

@glenn-jocher i guess further clarification will be greatly helpful as i am beginner in this field so that the information from you will be greatly helpful for my further research

@hemanthmandava945 thank you for your comment! For beginners, I recommend exploring the Ultralytics YOLOv8 documentation for step-by-step guides on training, inference, and customization. If you have specific questions, feel free to ask!

@glenn-jocher i want to train the model on to detect pallet in lidar reflectivity images.as the resolution of images is 512 * 128 and single channel(0 -255).my questions are? can is use pretrained model using transfer learning to train on custom data ? is it possible? 2.do i need to resize the image of my data set for training (640 * 640)? as i used to pretrained model to detect cars in lidar reflectivity images of resolution 1024 *128 it work perfectly fine. 3. for annotation in images as i only need to detect pallet is annotating pallet would enough?

1. Yes, you can use a pretrained YOLO model and fine-tune it on your custom dataset for pallet detection.
2. Resizing your dataset to match the model's input size (e.g., 640x640) is recommended for consistent results.
3. Annotating only the pallets is sufficient if pallet detection is your sole objective.

For training details, refer to the Ultralytics Train documentation. Let me know if you need further assistance!

@glenn-jocher i am using yolov8x for car segmentation on lidar 2d reflective data,i got the following results: 0: 128x1024 11 cars, 4127.8ms Speed: 1.6ms preprocess, 4127.8ms inference, 221.6ms postprocess per image at shape (1, 3, 128, 1024) which actually performs well on lidar 2d data. But catch is when i am validating the model, i made annotaion of 50 images where it consist of cats and persons but i am getting poor results: Ultralytics 8.3.28 🚀 Python-3.10.12 torch-2.5.1+cu124 CPU (Intel Core(TM) i5-8265U 1.60GHz) val: Scanning /home/mandava/myenv/share/traffic-2/valid/labels.cache... 50 images, 0 backgrounds, 0 corrupt: 100%|██████████| 50/50 [00:00<?, ?it/s] Class Images Instances Box(P R mAP₅₀ mAP_50-95) Mask(P R mAP₅₀ mAP_50-95): 100%|██████████| 4/4 [04:16 all 50 491 0.00184 0.0148 0.00104 0.000264 0.00524 0.0426 0.00275 0.000623 person 50 473 0.00367 0.0296 0.00208 0.000528 0.00367 0.0296 0.00189 0.000525 bicycle 18 18 0 0 0 0 0.0068 0.0556 0.0036 0.00072 Speed: 4.3ms preprocess, 5012.5ms inference, 0.0ms loss, 3.5ms postprocess per image Results saved to runs/segment/val4 map50-95:0.0002641973106310545 i want to evaluate the model on lidar data and inference speed it taking , can you explain why i am getting the validation metrics very poor as i am getting prediction was good. here my yaml file: names:

• car

• person nc: 2 roboflow:

  version: 2 workspace: hemanthmandava test: ../test/images train: ../train/images val: ./valid/images

Thank you for sharing these details. The poor validation metrics could stem from class mismatches (your YAML defines 2 classes but validation includes 'cats'), potential annotation format issues, or domain gap between training/validation data. For LiDAR-specific segmentation improvements, consider fine-tuning on domain-adapted data and verifying label consistency. More validation guidance can be found in our Val Mode documentation.

@glenn-jocher could explain in more details, I am working with Ouster LiDAR reflectivity images and aiming to evaluate the inference speed and performance of pretrained YOLOv8, YOLOv9, and YOLOv11 models for instance segmentation. However, I am facing issues when using the YOLO validation function (val), even though the visual inspection of inference results looks good. note: the model or running on lidar video segmenting cars very well and tracking of masks also performs good

My Understanding & Key Questions: Fine-Tuning vs. Direct Evaluation:

I understand that fine-tuning means training a pretrained model on my dataset (LiDAR 2D images). However, my goal is to only validate the pretrained YOLO models without fine-tuning. Does the poor validation performance indicate a need for fine-tuning, or is it possible that the pretrained models just do not generalize well to my LiDAR images? Dataset & Annotation Format:

I have 50 annotated images (no separate training set, only validation). The annotations are in YOLO format, where segmentation masks are represented as polygon coordinates normalized to image width and height. Example annotation: 0 0.478515625 0.4783950617283951 0.52734375 0.4783950617283951 0.52734375 0.6790123456790124 0.478515625 0.6790123456790124 Validation Issues:

When I run YOLO inference, the visual results look reasonable, and the model seems to segment objects correctly. However, when using YOLO’s val function, the evaluation metrics are poor. What could be the reasons behind this discrepancy? Performance Metrics to Focus On:

Since my goal is to compare YOLOv8, YOLOv9, and YOLOv11 on LiDAR reflectivity images in terms of inference speed and segmentation accuracy, what are the most relevant evaluation metrics I should consider? I am currently looking at: IoU (Intersection over Union) F1 score mAP (mean Average Precision) FPS (Frames Per Second) for inference speed Are there any specific metrics better suited for LiDAR-based segmentation? What strategies would you recommend for properly evaluating segmentation models on LiDAR images? Are there better methods to verify annotation alignment and ensure the YOLO val function produces meaningful results?

Hi there! 👋 Your observed discrepancy between visual results and validation metrics likely stems from a domain gap between COCO-pretrained models (RGB images) and LiDAR reflectivity data (single-channel). Here's a concise breakdown:

1. Domain Adaptation: Pretrained models struggle with LiDAR's unique characteristics. Fine-tuning (even briefly) on LiDAR data is strongly recommended (YOLO Train Docs)
2. Annotation Verification: Use yolo val with plots=True to visualize predictions vs. ground truth. Check mask alignment in LiDAR coordinates
3. Key Metrics: Focus on mAP_50-95(M) for segmentation quality and FPS for speed. LiDAR-specific metrics like point-wise IoU could add value
4. Quick Fix: Try converting LiDAR to 3-channel (replicate single channel) to better match pretrained weights

For direct evaluation without fine-tuning, consider benchmarking against manually verified samples rather than relying solely on automated metrics. Our COCO-Seg validation example might help as reference. Let us know how it goes! 🚀

@glenn-jocher Issue: When using YOLOv8 for instance segmentation, I’ve noticed that the predicted masks extend slightly beyond the true object boundaries. This results in overlapping masks when objects are close together and inaccurate measurements of object sizes and shapes.

Observations:

Oversized Masks: The masks often include extra pixels along the edges, sometimes producing “flat” boundaries—similar to known issues where masks align too closely with the bounding box edges. Overlap with Adjacent Objects: Due to these extra pixels, masks of nearby objects tend to merge or overlap, which is problematic for applications requiring precise segmentation as i am projecting in 3d some of pixels segmented car points where projected on other objects . Architectural Artifact: The issue appears inherent to the current segmentation head in YOLOv8, where the approximated boundaries may not capture fine details, especially for smaller objects.

is it possible to reduce the size of the mask like getting 90% of mask, as i don't require the mask till the edge of the car. i can get major pixels of car.

this result of yolo inference on lidar data

Thank you for sharing these details. For mask size reduction in YOLOv8 segmentation, you can post-process predictions by applying a mask confidence threshold and morphological erosion. Here's a minimal example to shrink masks:

from ultralytics import YOLO
import cv2

model = YOLO('yolov8x-seg.pt')
results = model(your_image)
masks = results[0].masks.data.cpu().numpy()

# Apply erosion to shrink masks
kernel = cv2.getStructuringElement(cv2.MORPH_ELLIPSE, (5,5))  # Adjust kernel size as needed
eroded_masks = [cv2.erode(m, kernel) for m in masks]

For better domain adaptation, consider fine-tuning the segmentation head on LiDAR data using our Train docs. The pretrained COCO weights may struggle with LiDAR's unique reflectance patterns.

@LiJiang97 the preprocessing for YOLO11 typically involves resizing the input image to the specified imgsz (default 640) while maintaining aspect ratio by padding as needed. These operations are handled internally in the Ultralytics framework. The resizing is done by LetterBox in ultralytics/data/augment.py, and BasePredictor.preprocess in ultralytics/engine/predictor.py converts BGR to RGB and scales pixel values to 0-1. Let us know if you need further assistance!

@Zelyanne thank you for your question. YOLO models are designed to predict a single class per object detection, but multi-class labeling per detection isn't natively supported. You could implement a custom post-processing step to assign secondary classes based on your criteria or train the model with augmented multi-label datasets. For advanced use cases like this, consider modifying the model or leveraging additional resources to meet your requirements.