-
Notifications
You must be signed in to change notification settings - Fork 40
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
Unify how we scale modules #352
Comments
Thanks @fmartiescofet! I agree, It is more inline with our architecture design to use necks instead of decoder specific settings. As you mentioned, the necks should also generalize better, by making it possible to configure the scaling (e.g. also scaling only 3 or 5 layers). Also, the last layers should be scaled while the first layers are ignored. E.g. with 5 input laters and 4 scaling settings, the 1 laters gets passed. As Francesc explained it to me, |
@fmartiescofet I think this is on hold until we remove the |
Yes, but I think it should be removed before v1.0. Probably between 0.99.8 (if released) and 1.0. Regarding the neck architecture I would leave it as it is to not confuse people and maybe add a different neck in case we want another archietcture. |
Sounds good. @romeokienzler Another point why we should have another pre-release version. |
When using
UperNet
decoder with plain ViTdecoder_scale_modules
should be set toTrue
to upscale the layers to simulate a "hierarchical output". This part can also be done in theLearnedInterpolateToPyramidal
neck, in the tests for the Unet, which also needs this hierarchical output, this neck is used.For this, I suggest deprecating
scale_modules
for theUperNetDecoder
and recommend using the neck instead.Also, we should consider the architecture for this neck as currently it only supports 4 layers and the last one is downscaled using maxpool, not sure if this is the best option and it might be interesting to look into it.
CC: @blumenstiel
The text was updated successfully, but these errors were encountered: