You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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.
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 !
Uh oh!
There was an error while loading. Please reload this page.
🚀 The feature
Some models currently accept normalization strategies as callables (
mobilenet_backbone
accepts anorm_layer
argument for example) but loss functions are currently hardcoded (F.cross_entropy
forfastercnn.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
The text was updated successfully, but these errors were encountered: