-
Notifications
You must be signed in to change notification settings - Fork 18.6k
All-in-one nets #734
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
All-in-one nets #734
Conversation
|
Whoops, I screwed up by overwriting deploy prototxts (at least |
|
Oh sweet! Sorry I dithered on this for so long. I'll review soon and think One could add optional input fields for phase/level/stage. Le samedi 19 juillet 2014, Jeff Donahue notifications@github.com a écrit :
|
|
Solves #57 and completes the model definition improvements for 1.0 Le samedi 19 juillet 2014, Jeff Donahue notifications@github.com a écrit :
|
|
In the last four commits, I refactored this to make it somewhat more flexible. I created new proto messages To handle deploy nets, I also added a new INPUT layer type which should act exactly like an actual net input*, and an extra *This might not be true if the existing inputs are handled specially somewhere outside of |
|
The only other thing I'd like to do before this gets merged (modulo any revisions due to reviewer comments) is add a few |
|
Oh right...the Maybe what I'll end up doing is removing the |
|
I revised this to exclude the INPUT layer and the "solver" parameter being a part of the NetState(Rule). This is good to go as far as I know, but only (conveniently) solves a part of the overall net consolidation issue -- the need to create separate train and test nets. Technically one could use the custom "stages" provided by this PR to also further differentiate between "solver" vs. "deploy" nets, but then this would require every existing tool to correctly set this setting. One possible solution to this would be to do something along the lines of @sguada's suggestion in #57 with the "include_net" in the proto. Then you'd make three separate files -- one the "main net" file that has conv1-fc8, one the "solver net" file that includes the main net and also has leveldb layers and loss/accuracy, and last the "deploy net" file that also includes the main net and has inputs and softmax prediction output. That solves the problem of redundancy among files, but doesn't eliminate the annoyance of having to work with many files. Still better than nothing though. But I won't do that for this PR; it's an orthogonal change, and this PR is still useful without it (especially for those of us whose primary caffe workflow is to train/test a net for a minute, check the accuracy, and throw it away). |
|
btw, I'd slightly prefer this one be reviewed/merged before #686 despite the ordering of the PRs. (Also this is easily the 'safer' of the two changes in that it's pretty much an optional proto thing.) But it's probably just 5-10 minutes' worth of extra rebase conflict resolution work if you'd prefer the opposite Evan, so no big deal either way. |
|
I'll review this first. Thanks for letting me know your preference. On Tuesday, July 29, 2014, Jeff Donahue notifications@github.com wrote:
|
|
re: #734 (comment) this is a nice step in combining the definitions, so let's review and merge as-is. To follow-up after this PR, one of us should:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although the logging is precise, the two cases for the logic are just I take it back, with all the possible nets there could be when combining definitions it's best to be clear.net_param inline prototxt vs net file and the (train_)_net_* cases could be combined or conciseness. Do what you like.
|
Nice schema in 1cf797825528cb39a8dc43cbe0e9ef592c610939 -- thanks for the good inline documentation of the |
|
Ok this all looks good to me. Decide if you want to change any names then merge. Thanks Jeff! This does make the workflow of defining and training a whole host of nets much neater. |
filtering rules for Layers.
includes/excludes layers based on whether the NetState meets each layer's NetStateRule(s).
|
Thanks for the thorough review Evan! I changed the name of Will merge after Travis. |
All-in-one nets
All-in-one nets
This PR lets you specify a
phase,stage, and/orlevelin each of your layers to indicate whether or not these layers should be available. The most obvious application of this is to insert "phase: TRAIN" or "phase: TEST" to special layers that are only used in one or the other so that you need not repeat the common layers; e.g., a data layer which should have a different source at train vs test time, and the accuracy layer which can only be used in the test net (although #686 will fix this whenever someone reviews that ;).The
levelparameter, anint, allows you to turn off different layers all at once (all those that have level < the net's setting), e.g. to do layerwise training. Thestageparameter, suggested by @shelhamer, (which generalizes thelevelparameter in a sense), astring, allows you to create arbitrary groups of layers. I'm not sure if I made thee best decisions with this interface design, feel free to make suggestions.The
train_net,test_net,train_net_param, andtest_net_paramshould all work as before.