TfLite转换后模型与原训练模型结果不一致及检测异常问题排查

Hey, let's break down the possible causes for your TFLite conversion problem—this is a super common pitfall when moving trained TensorFlow object detection models to edge devices like the RPi3. Based on your description (accurate training/deployment but messed-up detection boxes post-conversion), here are the most likely fixes to check:

1. Mismatched Image Preprocessing #

The #1 culprit for weird detection box behavior is inconsistent preprocessing between your training pipeline and TFLite inference. Here's what to verify:

• Normalization range: Mobilenet models typically expect inputs normalized to either [-1, 1] (via (image / 127.5) - 1) or [0, 1] (via image / 255.0). If your training used one but TFLite inference uses the other, the model will get garbage feature data, leading to misplaced boxes.
• Input size & channel order: Double-check that the image dimensions fed to TFLite exactly match what you used during training (e.g., 320x320). Also, TensorFlow uses RGB channel order by default—if you're loading images with OpenCV (which defaults to BGR) and don't convert them to RGB, that'll throw off the model.
• Resize method: Ensure you're using the same resizing algorithm (e.g., tf.image.resize with method=tf.image.ResizeMethod.BILINEAR) in both training and inference. Different resize methods can create subtle feature differences that break detection.

2. Incorrect TFLite Conversion Settings #

Object detection models like Mobilenet-SSD have specialized output structures, and generic conversion can mess up their output format:

• Use the dedicated object detection conversion workflow: Instead of using tf.lite.TFLiteConverter directly, export a properly formatted SavedModel first with tf.saved_model.save, then convert it with the converter while specifying signature_def_key="serving_default" to preserve the correct output tensors.
• Preserve custom ops: If your model uses any custom post-processing ops (like non-max suppression), make sure to enable target_spec.supported_ops = [tf.lite.OpsSet.TFLITE_BUILTINS, tf.lite.OpsSet.SELECT_TF_OPS] in the converter. This prevents the converter from dropping critical ops that handle detection box logic.

3. Post-Processing Logic Errors #

Trained TensorFlow models often include built-in post-processing (like NMS), but TFLite models may output raw, unprocessed tensors that require manual handling:

• Coordinate order & scaling: TF Zoo detection models usually output normalized coordinates (either [y_min, x_min, y_max, x_max] or [x_min, y_min, x_max, y_max]). If you mix up the order, or forget to scale the normalized values back to your image's actual pixel dimensions, you'll end up with boxes clustered in corners (like your right-bottom issue—e.g., a normalized x_max of 0.9 on a 640px wide image becomes 576px, which is near the edge).
• Missing NMS: If the TFLite model doesn't include NMS in its graph, you'll need to implement it yourself on the output tensors. Without NMS, you'll get dozens of overlapping boxes, which might appear clustered when filtered incorrectly.

4. Quantization-Related Degradation #

If you used quantization (e.g., INT8) during conversion, that could be causing accuracy drops:

• Calibration data issues: INT8 quantization relies on a calibration dataset to determine tensor ranges. If your calibration data is too small, or doesn't match the distribution of your test data, the quantization will introduce large errors.
• Try FP32 first: To rule out quantization as the problem, convert your model to FP32 (no quantization) and test it. If the FP32 TFLite model works correctly, then you'll need to refine your quantization setup—either use a better calibration dataset, or switch to float16 quantization if your RPi3 supports it.

内容的提问来源于stack exchange，提问作者luk