YOLO26 TFLite — Manual inference gives different results than Ultralytics' predict()

[TheRealGreatFAS]

Hi all,

I exported a YOLO26n pretrained model to TFLite and I'm seeing different results depending on how I run inference.

Here's a minimal reproduction script.

What works:

Using the Ultralytics API to run inference on a frame (auto method) — detections look correct.

What doesn't:

Running inference manually by:

1. Capturing a BGR frame
2. Stripping excess channels
3. Converting BGR → RGB
4. Normalizing
5. Quantizing
6. Passing the result to the input tensor
7. Invoking the interpreter
8. Dequantizing
9. Filtering by confidence
10. Rescale to original image and exporting

The manual method produces incorrect results (wrong and too few detections in wrong places compare to the Ultralytics tools) even though I believe the pre and postprocessing should be equivalent.

My question: What steps does the Ultralytics pipeline apply under the hood that I might be missing or getting wrong in my manual pipeline? Are there additional transforms (resizing, padding/letterboxing, specific normalization values, channel ordering, etc.) that could account for the difference?

I've attached a Python script that reproduces the issue with both methods side by side.

Any pointers would be appreciated — thanks!

[UltralyticsAssistant]

👋 Hello @TheRealGreatFAS, thank you for your detailed report and for sharing a minimal reproduction script for YOLO26 TFLite 🚀 This is an automated response to help get your discussion triaged quickly, and an Ultralytics engineer will also assist soon.

We recommend a visit to the Docs for new users where you can find many Python and CLI usage examples and where many of the most common questions may already be answered.

Since this appears to be a 🐛 bug report or inference discrepancy, thank you for already providing a minimum reproducible example 🙌 That will help the team investigate the difference between your manual TFLite pipeline and the Ultralytics predict() path.

If this is a custom training ❓ question, please provide as much information as possible, including dataset image examples and training logs, and verify you are following our Tips for Best Training Results.

Join the Ultralytics community where it suits you best. For real-time chat, head to Discord 🎧. Prefer in-depth discussions? Check out Discourse. Or dive into threads on our Subreddit to share knowledge with the community.

Upgrade

Upgrade to the latest ultralytics package including all requirements in a Python>=3.8 environment with PyTorch>=1.8 to verify your issue is not already resolved in the latest version:

pip install -U ultralytics

Environments

YOLO may be run in any of the following up-to-date verified environments (with all dependencies including CUDA/CUDNN, Python and PyTorch preinstalled):

• Notebooks with free GPU:
• Google Cloud Deep Learning VM. See GCP Quickstart Guide
• Amazon Deep Learning AMI. See AWS Quickstart Guide
• Docker Image. See Docker Quickstart Guide

Status

If this badge is green, all Ultralytics CI tests are currently passing. CI tests verify correct operation of all YOLO Modes and Tasks on macOS, Windows, and Ubuntu every 24 hours and on every commit.

[glenn-jocher]

The main thing you’re likely missing is Ultralytics’ resize/pad path before inference: predict() first runs pre_transform() and then preprocess() (BGR -> RGB, BHWC -> BCHW, float/fp16, /255 for non-tensor inputs), while the TensorFlow/TFLite backend runs the model in BHWC, applies input/output quantization rules, and denormalizes xywh back by the model input w,h, so if your manual path skips exact letterbox padding or rescales boxes directly to the original frame instead of undoing ratio + pad, detections will shift or disappear; please compare your script against BasePredictor.preprocess and TensorFlowBackend.forward and, if you still see a mismatch, paste the text output of !yolo checks plus the exact input shape, quantization params, and first few raw output values from both paths.

[TheRealGreatFAS]

Taking into account the letterboxing path when rescaling the bounding boxes to the original scale does fix an issue with the drawing process of the bounding boxes, I thank you for that.

The more pressing concern I have is with the accuracy of the detections (the manual preprocessing seems to affect the objects detected -> i.e. it detects a bicycle in the bus.jpg image when there are none). It might be because of the BCHW format instead of BHWC one used by the TFLite backend, I'll give that a try in the manual preprocessing.

[Y-T-G]

You can check the code here for preprocessing and postprocessing reference:

https://github.com/ultralytics/ultralytics/blob/main/examples/YOLOv8-TFLite-Python/main.py

[vincere-mori]

The most common cause of this is letterboxing. The Ultralytics pipeline resizes the image to fit within the target size while preserving aspect ratio and pads the rest with gray (114, 114, 114), which is called letterboxing. If your manual pipeline does a straight resize to the input dims instead, the spatial layout seen by the model is completely different and detections will be wrong or missing.

The other thing to double-check for quantized TFLite models: dequantization. The output tensors have a scale and zero_point per tensor that you need to apply correctly. output = (raw_output.astype(np.float32) - zero_point) * scale. If you're using the wrong scale or skipping this step, confidence scores will be off.

The reference script linked above handles both of these correctly, so comparing your preprocessing step by step against that should show where the divergence is.

[glenn-jocher]

Yes, and the other easy-to-miss step is output box scaling: in the predictor reference Ultralytics first applies LetterBox in pre_transform(), then BGR→RGB, BHWC→BCHW, and /255 in preprocess(), and for TFLite the TensorFlow backend multiplies normalized xywh by the model input w,h before the detection predictor maps boxes back to the original image with ops.scale_boxes(), so if your manual path does a plain resize or skips either denormalization or that final letterbox-aware rescale, the boxes will shift or disappear.

[Ti-03]

"Wrong places" + "too few" together almost always means two specific mismatches with what Ultralytics does internally:

1. Letterbox, not a plain resize. Ultralytics doesn't stretch to (imgsz, imgsz). It letterboxes: scale by r = min(imgsz/h, imgsz/w) (aspect-preserving), then pad the short side to imgsz with gray (114, 114, 114). You can see it in LetterBox in ultralytics/data/augment.py (default padding_value = 114). If your manual path does cv2.resize(img, (imgsz, imgsz)), you stretch the image, so every box lands in the wrong spot and small/thin objects distort out of detection. This one mismatch explains both symptoms.

2. Reverse the letterbox in post-processing. Because the model sees the padded image, its boxes are in letterboxed space. To map back to the original you must subtract the pad and divide by r, not scale by orig_w/imgsz. This is exactly what scale_boxes in ultralytics/utils/ops.py does:

gain = min(img1_shape[0] / img0_shape[0], img1_shape[1] / img0_shape[1])
pad_x = round((img1_shape[1] - img0_shape[1] * gain) / 2 - 0.1)
pad_y = round((img1_shape[0] - img0_shape[0] * gain) / 2 - 0.1)
boxes[..., [0, 2]] -= pad_x
boxes[..., [1, 3]] -= pad_y
boxes[..., :4] /= gain

A naive * orig/imgsz rescale is only correct if you stretched, so mixing letterbox-in with naive-rescale-out is a second source of "wrong places."

Then the usual TFLite checklist:

• Input is RGB, NHWC (1, H, W, 3), float /255.0. If it's an int8/uint8 model, apply the input quantization from interpreter.get_input_details()[0]['quantization'] (q = round(real/scale + zero_point)), and dequantize outputs with their own scale/zero_point.
• v8/v11/v26 output is [1, 4+nc, N] (transpose to [N, 4+nc]), boxes are xywh center-format, confidence = max class score (no separate objectness), then NMS. Confirm whether your export emits boxes normalized 0-1 or in pixels and scale accordingly before step 2.

Diff your script against the LetterBox and scale_boxes logic above and the discrepancy will be one of these, with the resize/pad being the most likely given "wrong places."

[glenn-jocher]

Letterboxing and reversing its padding are required, but two YOLO26-specific corrections matter: the default detection output is end-to-end (1, 300, 6) as [x1, y1, x2, y2, confidence, class_id], so do not transpose, decode xywh, or run NMS (end-to-end guide); also, .tflite layout depends on the exporter—current LiteRT exports use NCHW while legacy onnx2tf exports use NHWC, with the backend handling quantization and coordinate denormalization (LiteRT backend). Inspect get_input_details()/get_output_details(), reproduce centered 114-value letterboxing, then map xyxy boxes back using scale_boxes.

[Ti-03]

Thanks @glenn-jocher, you're right about the end-to-end output, my transpose/xywh/NMS note was YOLOv8-shaped and doesn't apply to a default YOLO26 export. I ran both export paths on ultralytics==8.4.106 to confirm, and the result splits by whether quantization is on:

Default (format='litert', no quantize):

IN  [1, 3, 640, 640] float32   # NCHW
OUT [1, 300, 6]      float32   # x1, y1, x2, y2, conf, cls

Boxes are already pixel coordinates in letterboxed space. Manual pipeline (letterbox to 640 with 114 padding, BGR->RGB, NCHW, /255, then subtract pad and divide by r) reproduces predict() exactly on bus.jpg, same 5 detections to within 0.1 px. No transpose, no NMS, no dequantization.

INT8 (quantize=8):

WARNING  LiteRT INT8 export does not support end2end models, disabling end2end branch.
IN  [1, 3, 640, 640] float32
OUT [1, 84, 8400]    float32   # coords normalized to 0-1

So the end2end branch is turned off for static INT8 (exporter.py), and for that model you do transpose to [N, 84], take conf as the max class score, multiply x/w by input width and y/h by input height, and run NMS yourself, before reversing the letterbox.

Two things worth checking on your side @TheRealGreatFAS:

1. Layout depends on when you exported. format='tflite' was deprecated in favour of LiteRT in 8.4.83 (2026-06-29). Exports from before that came through onnx2tf and are NHWC (1, 640, 640, 3); current LiteRT exports are NCHW. Since you posted in April, your model is very likely the NHWC one. get_input_details()[0]['shape'] tells you which.
2. Don't quantize/dequantize unless the graph asks for it. Current Ultralytics exports keep float32 graph I/O even when weights are INT8. Only legacy full-integer onnx2tf models have int8/int16 graph I/O. If get_input_details()[0]['dtype'] is float32, your manual quantize and dequantize steps are corrupting the input, which would explain phantom detections like the bicycle.

Also note the older onnx2tf path normalized coordinates to 0-1 even for end-to-end output, so on that model you multiply by w, h before reversing the letterbox. The letterbox and scale_boxes part of my earlier comment still applies in every case.