The reason of cam_eval_thres 0.21

[Muyun99]

Hi, thanks your excellent work and nice code style.

I notice the cam_eval_thres are set to 0.21, is there some reason to set this value?

And I notice the other repos will traversal the threshold from 0 to 0.6 (please see this link), in this way I can use the best threshold, but it use the segmentation label to evaluate the miou, it seems so triky and the segmentation label is in visible the weakly-supervised setting.

So I want to know the threshold is searched with the segmentation groundtruth or set by experience. This problem confused me for a long time.

Looking forward to your reply. Thanks!

Best Regards! Yun

[zhaozhengChen]

Thanks for your interest in our work!

We also follow the previous work to traverse the threshold (Please see Appendix).

As for how to set the threshold, I think it depends on the model architecture. A fixed value may be disadvantageous for certain methods. But as you said, the segmentation label should be invisible in the weakly-supervised setting. So I think it is an ill-posed task... (You can refer to this paper, they point out this problem in WSOL task)

[Muyun99]

Thanks for your reply, I understand the whole pipeline more, and the paper you provided is really helpful.

And other question is, do you have some idea about threshold selection under the setting of real situation without segmentation groundtruth?

Maybe one way is to label a valid segmentation dataset for this hyperparameter selection. But if given a few labeled samples, the performance of semi-supervised segmentation or few-shot segmentation would be better? I am not sure

So it`s really awkward to weakly-supervised segmentation setting because of the threshold selection.

[zhaozhengChen]

I think it's a feasible way.

I'm not familiar with semi-supervised or few-shot... In AdvCAM, they achieved SOTA performance in both WSSS and SSSS. You may refer to their paper.

[Muyun99]

Okay, thanks for your information. Nice work!