Question about the gt_count in MApMetric

[BunnyShan]

@zhreshold I have noticed that the gt_count in MApMetric is calculated by all cids in preds. But what if there are some classes not preded in the class? I have tested it on VOC val set and the gt_count will be less than real ground truth num in labels some time. Is this a problem or I misunderstand this? Thank you!

[zhreshold]

You are correct, fixed now.

[BunnyShan]

@zhreshold Another question: Why SSD's input need to be resized to a predefine shape? SSD is a fcn framework, will no resize operation increases the performance?

[zhreshold]

No-resizing is potentially good for performance, but training is more complicated since you can only do batch-1 training, and there's not a easy solution for mini-batching like fast-rcnn.

[BunnyShan]

I see. In yolo2, it uses the same size in one batch and change another size after a few batches. I will look for some other solutions. Thank you!

[BunnyShan]

@zhreshold I got about mAP:65% on voc after update the new code. Is there something wrong?

[zhreshold]

I'm verifying this.

[BunnyShan]

Thanks a lot. Fix gt_count will cause recall decrease. I will test it too.

[BunnyShan]

The gt_count fix only cause about 1% mAP drop.

[BunnyShan]

@zhreshold Is there any progress?

[zhreshold]

seems like it was related to some parameter change including lr_mult and learning rate. I did modified them for sake of a lot of GPUs, and it turns out to be not as good as the original ones.

[BunnyShan]

@zhreshold why update rescale_grad like this 'rescale_grad': 1.0 / len(ctx) if len(ctx) > 0 else 1.0 ? And previous 'rescale_grad': 1.0 makes my model don't converge.

[zhreshold]

Using multi devices will reduce the effective batch-size, 'valid' normalization in softmaxOutput and makeloss will be affected.