Add `top_k` argument to post-process of conditional/deformable-DETR
Author: CreatlV
Pull request: yes

# What does this PR do?

The current post-processing for object detection methods of deformable and conditional DETR assumes the number of classes * the number of object queries > 100. This reflects the original code in the [deformable-DETR repository](https://github.com/fundamentalvision/Deformable-DETR/blob/11169a60c33333af00a4849f1808023eba96a931/models/deformable_detr.py#L412). However, this limits the flexibility of training on datasets with fewer classes/object queries. This PR suggests updating the post process for object detection code not to break if n_classes * n_object_queries < 100. 

This PR suggests adding `top_k` argument to post-process functions of conditional/deformable-DETR with the default value of the previously hard-coded value.

## Before submitting
- [ ] This PR fixes a typo or improves the docs (you can dismiss the other checks if that's the case).
- [x] Did you read the [contributor guideline](https://github.com/huggingface/transformers/blob/main/CONTRIBUTING.md#start-contributing-pull-requests),
      Pull Request section?
- [ ] Was this discussed/approved via a Github issue or the [forum](https://discuss.huggingface.co/)? Please add a link
      to it if that's the case.
- [ ] Did you make sure to update the documentation with your changes? Here are the
      [documentation guidelines](https://github.com/huggingface/transformers/tree/main/docs), and
      [here are tips on formatting docstrings](https://github.com/huggingface/transformers/tree/main/docs#writing-source-documentation).
- [ ] Did you write any new necessary tests?


## Who can review?

Anyone in the community is free to review the PR once the tests have passed. Feel free to tag
members/contributors who may be interested in your PR.

@amyeroberts, as you added these models do you think this approach is a reasonable addition?


Comments:
_The documentation is not available anymore as the PR was closed or merged._

@CreatlV  Thanks for opening this PR! 

Having the processor be compatible with the model is definitely something we want and updating the code to make it less brittle is a great initiative. At the moment, with `min`, if `num_queries *num_classes < 100`, then the model will return all of the boxes. I think we could adapt this further to make it scale `k` according to the model. Specifically, adding an argument e.g. `k` to the method, which defaults to `num_queries` or its current default. We can keep the `min` upper bound to keep it safe. 

@NielsRogge For the number of boxes returned, the default `k` value for this model is 100 (rather than 300). Was there a reason for setting it to this value? (I'm guessing consistency with other detr models?)


@amyeroberts it was done to reflect the original code, as linked in his message. The probabilities get reshaped to `(batch_size, num_queries*num_labels)` and then the top 100 values (highest scoring queries) are taken for each example in the batch. However, since Deformable DETR uses 300 queries by default, this will always be > 100. But when you train the model from scratch with a custom number of queries, this would indeed raise an error.

Making this more general makes sense. Note that we typically filter them based on a certain threshold; we first filter the 300 queries to get the top 100 recognized objects, and then set a threshold like 0.9 to only get the predictions with a score higher than 0.9. Both the `threshold` and the `top_k` value can both be seen as postprocessing hyperparameters. However I'm not sure `top_k` is general enough as it seems DETR-specific

I added `top_k` as an argument to the post-processing functions of conditional/deformable-DETR that used them. With the default value unchanged from previously. The top_k value for `post_process` of conditional DETR is 300, compared to 100 of the other functions, is this intentional @NielsRogge ?   

Thanks again for adding this improvement and iterating! 🎉