how about generate the label heatmap in the 384x288 resolution and resize the label to 96x72?

[lilhope]

Hi, I find that you generate the label heatmap in 92x72 resolution, so the [int(x/4.),[int(y/4.)]] was the center to generate Gaussian Blur. But it seems may cause mismatch with the original coordinate.e.g.int(17/4)=4,but 4*4=16. So I wonder could I generate the label heatmap in 384x288 resolution and resize it to 96x72? This method would be much slower than your implement but more accuracy? Thanks in advance!

[chenyilun95]

It's a bug we've known. That maybe causing 4-pixel error in the highest point. But we don't think it seriously because some post-processing operations might relieve the problem. I've just implemented the code (models/COCO.res50.256x192.CPN.finerlabel) quickly following your thinking in branch dev and do the experiment. You're welcome to check the code. I'll later report the result. Thank you for your carefulness!

[lilhope]

How about adding an regression layer to learn the offset, like the Region Proposal Network?(Faster RCNN).

[chenyilun95]

It seems that CNN is good at classification rather than regression in general. Adding regression to reduce error may helps a little more but it requires proper design of code implementation.

[chenyilun95]

The performance of finer label is same as the original. I think it may be because

1. there exists other coordinate misaligned problem in code.
2. post processing relieved the problem of 4-pixel error.
3. COCO evaluation tools are not sensitive to this small error. ( exp(-x) )

But I think it actually helps (+ >0.0) if the implementation is completely right. it's a pity...

[lilhope]

get It. Thanks for your nice feedback

[kaleidoscopical]

@chenyilun95 Hi! I am interested in this issue. Could you please list some high-level summaries of the post-processing step? Or, is there some papers or blogs describing similar post-processing step? @

[chenyilun95]

@kaleidoscopical These testing tricks are listed in experiments section in our paper.