Skip to content
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

Add config parameters to network constructors: n_channel_input and output_softmax? #95

Closed
jonalm opened this issue Oct 17, 2021 · 5 comments

Comments

@jonalm
Copy link

jonalm commented Oct 17, 2021

Hi there,

I'm trying out the image networks for classification of data with some imagy-properities (e.g. x-y-locality) but not 3 channels like conventional images. As far as I can tell, the 3 input channels are hard coded in the network implementation. Would you consider a PR adding a n_channel_input = 3 keyword argument to the networks?

Also, would you consider a PR for an optional output_softmax = false parameter, which (if true) adds a final softmax layer?

best
Jon

@darsnack
Copy link
Member

Just to clarify, are you working off the last release or the master branch?

@jonalm
Copy link
Author

jonalm commented Oct 17, 2021

Master

@darsnack
Copy link
Member

For accepting multiple input channels, that's definitely something we'd like to support. The VGG models already accept such a keyword. For something like ResNet, there is usually an initial conv-batchnorm-activation before all the residual blocks. There, I think it would be nice to accept any Flux model as the "initial backbone."

For the softmax layer, I feel like the cleaner design is to just tack on a softmax at the end. Something like

model = Chain(ResNet50(), softmax)

Generally, we try to limit the number of keywords to keep the API simple.

@DhairyaLGandhi
Copy link
Member

Right, it seems like we should not have softmax in the models by default. I even wonder if we should make the classification head optional. In most cases, that would be dropped and retrained anyway, but it is good to have it around optionally when its convenient not to have to do that (say in demos). Ditto for bias and activation.

@darsnack
Copy link
Member

I'm going to close this as a duplicate of #176 which has a more up to date discussion.

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

No branches or pull requests

3 participants