The matcher.py file in the repository implements the basic L1-based Hungarian matcher and does not reflect the KMO-based Hungarian bipartite matching claimed in the paper.
Looking through the closed issues, it seems like others have already pointed this out but the authors seem to have closed the issues without providing an explanation.
Given that the KMO matcher is really the crux of the paper, without which the model become merely a clone of the conditional DETR adapted to output points, this issue will inevitably be raised again in the future.
To avoid this issue being repeated raised in the repository, can the authors provide an explanation? Is it out of IP concerns? Is it still being implemented?
The matcher.py file in the repository implements the basic L1-based Hungarian matcher and does not reflect the KMO-based Hungarian bipartite matching claimed in the paper.
Looking through the closed issues, it seems like others have already pointed this out but the authors seem to have closed the issues without providing an explanation.
Given that the KMO matcher is really the crux of the paper, without which the model become merely a clone of the conditional DETR adapted to output points, this issue will inevitably be raised again in the future.
To avoid this issue being repeated raised in the repository, can the authors provide an explanation? Is it out of IP concerns? Is it still being implemented?