#26139 [Bug] YOLOv8/YOLO11/YOLO26 intermittently truncate long OCR text fields and elongated objects

Search before asking

I have searched the Ultralytics YOLO issues and found no similar bug report.

Ultralytics YOLO Component

Train

Bug

Search before asking

I have searched the Ultralytics YOLO issues and discussions for similar reports.
I found multiple related reports, including #14151, #17903, #17839, #19523, #20443, #20833, #9768, and #21471.

These reports cover OCR, document layout analysis, and general elongated-object detection, and involve multiple users and different projects. However, I could not find a confirmed general fix that reliably resolves the problem.

Ultralytics component

Detection and OBB models
Training data transforms / LetterBox / batch processing
Bounding-box regression and inference post-processing

Bug description

When training YOLOv8, YOLO11, or YOLO26/YOLO26-OBB for OCR text-region detection or other elongated-object detection tasks, some long targets are predicted with bounding boxes that do not cover the complete target. In an OCR pipeline, this causes the crop passed to the recognizer to remove characters from the beginning or end of a text field.

The problem is intermittent and appears to depend on the individual image/target:

It does not happen to every long target.
It can happen to visually similar targets in the same dataset.
It can still happen when inference is run on images from the training set.
The affected targets appear to be randomly distributed across images and training checkpoints.
The same type of symptom has been reported for OCR text lines, document layout regions, and non-OCR elongated objects.

As a comparison, O2-RT-DETR currently does not show the same truncation behavior in the corresponding OCR workflow.

What I have tried

I have already tested different input resolutions and disabled Mosaic and other common data augmentations. These changes did not provide a reliable solution; some settings changed the failure pattern or introduced other regressions, while long-target truncation still occurred.

Expected behavior

The predicted horizontal/rotated bounding box should cover the complete text field or elongated object, including both ends, so that the entire region can be passed to the OCR recognizer or downstream processing.

Actual behavior

Some predicted boxes are systematically or intermittently shorter than the ground-truth region. The missing part is often at one or both ends of a long text field. The issue is not limited to one language, one document type, or one project.

Steps to reproduce

Train a YOLOv8, YOLO11, or YOLO26/YOLO26-OBB model on a dataset containing long text fields or other extreme-aspect-ratio targets.
Run validation and inference on both held-out images and images from the training set.
Compare the predicted boxes with the complete annotated regions.
Repeat with similar images. The truncation is intermittent rather than present on every long target.

Minimal reproducible example

I can provide a small set of images, labels, training arguments, and prediction results. The attached examples are named cut_text_1.png through cut_text_6.png and show the intermittent truncation behavior.

Environment

Ultralytics version: [please fill in]
Model(s): YOLOv8 [variant], YOLO11 [variant], YOLO26/YOLO26-OBB [variant]
Task: detect / obb
Python version: [please fill in]
PyTorch version: [please fill in]
CUDA/GPU: [please fill in]
Operating system: [please fill in]

Training and inference configuration

Training command/configuration:
[please paste here]

Inference command/code:
[please paste here]

imgsz:
[please fill in]

rect:
[please fill in]

mosaic and other augmentation settings:
[please fill in]

Questions

Could the maintainers please clarify whether this behavior is a known limitation or bug related to any of the following?

LetterBox or rectangular batch geometry changing/clipping long targets during training.
A mismatch between training, validation, and prediction preprocessing or coordinate restoration.
OBB/detection box-regression limits for extreme aspect ratios.
Feature-level assignment or post-processing causing long boxes to be systematically shortened.
Any filtering rule that removes or alters very thin/long targets after resizing.

Is there a supported configuration or a recommended upstream fix for reliably detecting full-length text fields and other extreme-aspect-ratio objects? Are there regression tests covering full-width or very long targets?

Related reports

#20443: YOLO11-OBB predictions do not capture the entire length of long objects.
#20833: Chinese report that YOLO OBB boxes remain incomplete for very long objects despite repeated training and P6 experiments.
#14151: Poor x-axis width regression for OCR text boxes.
#17903: Predicted text boxes are narrower than the ground truth.
#19523: Long objects / long strip text are not detected completely.
#9768: Thin and long objects are cropped at the edges.
#21471: Full-width OBB objects shrink horizontally during prediction.

Thank you for looking into this. This issue appears across multiple YOLO generations and application domains, so a reproducible explanation or supported fix would be very valuable.

Environment

Ultralytics 8.4.39 Python-3.11.14 torch-2.9.0+cu128 CUDA:0 (NVIDIA A800-SXM4-80GB, 81222MiB) Setup complete ✅ (255 CPUs, 2015.7 GB RAM, 0.0/50.0 GB disk)

OS Linux-5.4.0-42-generic-x86_64-with-glibc2.39 Environment Docker Python 3.11.14 Install pip Path /home/search/houchangjian/cephfs-houchangjian/yolo/ultralytics-main/ultralytics RAM 2015.72 GB Disk 0.0/50.0 GB CPU AMD EPYC 7713 64-Core Processor CPU count 255 GPU NVIDIA A800-SXM4-80GB, 81222MiB GPU count 8 CUDA 12.8

Minimal Reproducible Example

The issue can be reproduced by inference only; retraining is not required. hsv_h: 0.015 hsv_s: 0.7 hsv_v: 0.4 degrees: 0.0
translate: 0.0
scale: 0.8
shear: 0.0
perspective: 0 flipud: 0.0 fliplr: 0.0 mosaic: 0.0
mixup: 0.0 copy_paste: 0.0
close_mosaic: true
multi_scale: 0.4

Additional

No response

Are you willing to submit a PR?

Yes I'd like to help by submitting a PR!