how about generate the label heatmap in the 384x288 resolution and resize the label to 96x72?
lilhope opened this issue · comments
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!
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!
How about adding an regression layer to learn the offset, like the Region Proposal Network?(Faster RCNN).
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.
The performance of finer label is same as the original. I think it may be because
- there exists other coordinate misaligned problem in code.
- post processing relieved the problem of 4-pixel error.
- 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...
get It. Thanks for your nice feedback
@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? @
@kaleidoscopical These testing tricks are listed in experiments section in our paper.