Convert classes used for Detection to nn.Modules #4389
Conversation
datumbox
force-pushed
the
obj_to_nnmodule
branch
2 times, most recently
from
e424fd7 to
beab59f
Compare
datumbox
force-pushed
the
obj_to_nnmodule
branch
from
beab59f to
91284af
Compare
|
|
||
|
|
||
| class BoxCoder(object): | ||
| class BoxCoder(nn.Module): |
There was a problem hiding this comment.
This class with its encode/decode methods does not play nice with the nn.Module's forward() approach. Not sure if we should convert it but it will allow us to drop its declarations to __annotations__
| def forward(self, match_quality_matrix): | ||
| return self._forward_impl(match_quality_matrix) | ||
|
|
||
| def _forward_impl(self, match_quality_matrix): |
There was a problem hiding this comment.
Workaround for overwriting the forward on inheriting classes. We do the same on quantization.
datumbox
changed the title
|
I'm going to close this PR until it's clearer to us whether we should convert Classes to Modules OR if there will be native support of Objects in JIT. |
|
I had a chat with Vasilis about this, and indeed the first thing to evaluate is if custom classes will be supported in the lite interpreter or not. One of the reasons for that is that converting all custom classes to |
3 participants
I'm converting some of the existing classes used to do computations for Detection models to nn.Modules. It's unclear why they were structured like this, could be because they were ported from DETR in the past (perhaps @fmassa can provide more info).
This PR was originally done to investigate #4386 (comment). Though it does not resolves it (might be partial solution), this conversion enables us to drop the
__annotation__declarations.I also tried to convert the
LevelMapperbut it's modification is not straightforward as it modifies arguments post compilation and creates JIT issues. Worth checking this on a separate PR.