Skip to content

Pass losses as callables when building detection models #5325

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Quintulius opened this issue Feb 1, 2022 · 2 comments
Open

Pass losses as callables when building detection models #5325

Quintulius opened this issue Feb 1, 2022 · 2 comments

Comments

@Quintulius
Copy link

Quintulius commented Feb 1, 2022

🚀 The feature

Some models currently accept normalization strategies as callables (mobilenet_backbone accepts a norm_layer argument for example) but loss functions are currently hardcoded (F.cross_entropy for fastercnn.roi_heads for example).

Following what has been done on normalization strategies loss function could be passed as callables in the modules constructor. This shouldn't break any backward compatibility. Reduction strategies still need to be properly handled.

Motivation, pitch

Currently, trying different loss functions requires to use some dirty model patches. Accepting the losses in the model constructors would provide a much cleaner way to hack around the models.

If any interest I can propose a first PR modifying the Faster-RNN models.

Alternatives

No response

Additional context

No response

cc @datumbox

@datumbox
Copy link
Contributor

datumbox commented Feb 1, 2022

@Quintulius You are correct. The current API for detection does not allow users to modify the losses. The solution you propose can work but it is just a workaround of the underlying limitation.

It is within our plans to look into the Detection API later in the year and see how we can make it be like Classification/Segmentation models. Aka move out the transforms and the losses so that users can choose the ones that match their needs. This is a very lengthy topic and requires lots of discussion, so I'm happy to ping you to give your input one we kick it off.

@Quintulius
Copy link
Author

OK ! Modifying the detection models without breaking too much the backward compatibility seems indeed quite a challenge. I'm looking forward to seeing how these models evolve and become more flexible !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants