修改Model Zoo中ssd_mobilenet_v2_fpnlite预训练模型输入维度报错的解决方案咨询

Hey, let's break down why you're hitting that dimension error when switching the input size to 100x100 or 200x200, and how to fix it.

The core issue here is that SSD MobileNet V2 FPNLite’s Feature Pyramid Network (FPN) is tightly tied to the original 320x320 input size. When you shrink the input to non-standard dimensions, the intermediate feature maps generated by the backbone don’t align with the FPN’s top-down connection requirements—hence the mismatch in the Add operation (your log shows 8x8 vs 7x7 tensors, which can’t be added together).

Why This Happens #

MobileNet V2 uses specific stride values across its layers, and the FPN relies on these strides to create aligned feature maps. The backbone’s maximum stride is 32, which means the original 320x320 input divides evenly by 32 (320/32=10). When you use 100x100 or 200x200:

• 100 ÷ 32 = 3.125 (not an integer)
• 200 ÷ 32 = 6.25 (also not an integer)

This breaks the spatial alignment between the lateral feature maps (from the backbone) and the upsampled top-down maps (from the FPN), leading to the dimension mismatch error.

Solutions to Try #

1. Use an Input Size That’s a Multiple of 32 (Easiest Fix)

Skip the complicated adjustments by picking an input size divisible by 32. Options like 128x128, 160x160, 256x256, or 384x384 will keep all feature map dimensions aligned perfectly. Just update your config's fixed_shape_resizer to one of these sizes, and the error should disappear immediately.

2. Adjust FPN Configurations for Non-Standard Sizes (If You Need 100x100/200x200)

If you absolutely must use those non-multiple sizes, you’ll need to tweak the FPN’s top-down connections to match the new feature map dimensions:

• First, calculate expected feature map sizes: For your input size, compute the spatial dimensions of each backbone layer (using floor division by the layer's stride). For 100x100:

  • layer_7 (stride 8): 100//8 = 12 (or 13 if padding is used, as seen in your log)
  • layer_14 (stride 16): 100//16 = 6 (but your log shows 7x7—so padding is adding an extra pixel here)
  • layer_19 (stride 32): 100//32 = 3

• Modify the FPN’s upsampling and projection layers: In your config, update the feature_map_generator section to ensure each upsampled top-down map matches the spatial size of the corresponding lateral map. You can adjust upsampling sizes or add padding/cropping steps before the Add operation. Here’s a modified config snippet to guide you:

  model {
    ssd {
      num_classes: 36
      image_resizer {
        fixed_shape_resizer {
          height: 100
          width: 100
        }
      }
      feature_map_generator {
        multiscale_feature_map_generator {
          min_level: 3
          max_level: 7
          # Define backbone feature maps with adjusted depths if needed
          feature_map_layout {
            from_layer: "layer_7"
            layer_depth: 32
          }
          feature_map_layout {
            from_layer: "layer_14"
            layer_depth: 96
          }
          feature_map_layout {
            from_layer: "layer_19"
            layer_depth: 1280
          }
          # Force upsampling to match lower layer dimensions
          top_down_upsampling_size: {
            level: 6
            height: 7
            width: 7
          }
          top_down_upsampling_size: {
            level: 5
            height: 13
            width: 13
          }
        }
      }
      # Rest of your SSD config (anchors, box predictors, etc.)
    }
  }
  

3. Retrain the Model (Mandatory for Non-Standard Sizes)

Even if you fix the dimension mismatch in the config, the pre-trained weights won’t adapt to the new input size automatically. You need to fine-tune the entire model on your dataset using the new input dimensions. This will adjust the backbone and FPN layers to the new spatial features, ensuring proper performance.

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