MMDETECTION SSD Model outputs - Full of bboxes and very high score

For using custom ssd model, I used mmdetection ssd model not tensorflow 1 model.

mmdetection ssd is different from tensorflow 1 ssd in terms of background class index (mmdetection ssd is 80 and tf ssdmodel is 0) so i changed the configuration’s value to 80 not 0.

But after converting to hef and inference it, it has too many bboxes and high scores (also has 1.04 score)

I thought mmdetection ssd has some different decode method from tensorflow ssd

does anyone have experience about this ?

i can share onnx and all other things to reproduce if you need

Thanks.

Hey @maro_Jeon,

Welcome to the Hailo Community!

To check your model’s output layers, just run:

hailortcli parse-hef {model}

Now, about the issues you’re seeing - our SSD post-processing (NMS and bbox decoding) is built specifically for TensorFlow Object Detection API SSD implementation (TF1, v1.13). Everything from anchor generation to class indexing and bbox decoding follows that format, including the background class at index 0.

Here’s the thing: if you’re using an MMDetection SSD model and just changing the background class index in the config, that won’t cut it. There are deeper differences in how bboxes are decoded and scores are computed. This mismatch is probably why you’re seeing too many bounding boxes, abnormally high scores (sometimes even >1), and incorrect detections overall.

The root cause is either:

  • A compilation issue where the anchors and everything are configured for TF SSD but your model isn’t actually TF SSD
  • The post-processing is running as if it’s TF SSD when it shouldn’t be

Here’s what you need to do:

1. Don’t just flip the background index Our SSD NMS expects TF-OD-API conventions (background at class 0, specific anchor generator, etc.). Just changing the background index to 80 won’t make an MMDet head work. You need the proper nms_postprocess(meta_arch=ssd) with a config that actually matches your model.

2. Start with the right config file Use default_nms_config_ssd.json as your starting point and customize it for your model - classes, image dimensions, IoU/score thresholds, and SSD decode parameters if your MMDet head uses different variances or ordering. You can find the default config location in the compiler docs.

3. Double-check your end nodes The SSD post-process needs to attach right after your box encodings and class logits layers. TF and MMDetection/ONNX use different naming conventions, so make sure your end_node_names actually point to the correct tensors (regression and classification) before decoding. If they’re pointing to the wrong layer (like post-activation or a different branch), everything falls apart.

4. Scores > 1.0? That’s a telltale sign When you add NMS through the model script, Sigmoid activation is added automatically to convert logits to probabilities. If your graph already has Sigmoid applied, or if you’re reading the output format incorrectly, you’ll get weird values. Make sure you’re using the correct NMS output format (Hailo format vs. TensorFlow format - check the tf_nms_format setting in your application).

Hope this helps clear things up!