-
Notifications
You must be signed in to change notification settings - Fork 18.7k
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
Replace input
fields with a proper layer
#1245
Comments
Can't wait for this. Here's my 2 cents: While you're at it, why not move to the machine learning naming convention of train-val-test (see ImageNet)? It's confusing that the train_val network uses phases TRAIN and TEST for my training and validation datasets, and where did "deploy" come from? Why not use this: enum Phase {
TRAIN = 0;
VAL = 1; // Was TEST
TEST = 2; // Instead of deploy
} And then rename all the test_net stuff to val_net, etc. I get why it would make sense to keep the naming convention for supporting legacy networks and models, but why was this naming convention chosen in the first place? |
Yes,we need this. |
@lukeyeager the There are all kinds of data splits that can be useful in practice, but we leave that up to the selection of inputs given to a Caffe model (as an lmdb, in memory, or what have you). |
The pyreformation BVLC#1703 aligned pycaffe Net with the real Caffe Net. This broke the pre-processing helpers that had been bolted on to `caffe.Net`. These responsibilities are gathered in `caffe.io.Transformer` instead. This is only an intermediate step in a real solution to pycaffe IO that should make use of the same data pipeline as the rest of the framework. See BVLC#1245 for further thoughts on input processing.
I totally support the idea:
I feel that deploying a trained model on a lmdb test data right now is a bit unnatural. I have to treat them like validation data and call |
Create an input layer to replace oddball Net `input` fields. close BVLC#1245
Create an input layer to replace oddball Net `input` fields. close BVLC#1245
Create an input layer to replace oddball Net `input` fields. close BVLC#1245
Create an input layer to replace oddball Net `input` fields. close BVLC#1245
Create an input layer to replace oddball Net `input` fields. close BVLC#1245
Create an input layer to replace oddball Net `input` fields. close BVLC#1245
Create an input layer to replace oddball Net `input` fields. close BVLC#1245
The switch to |
input
fields with a proper layer and assimilate deploy definition into all-in-one netsinput
fields with a proper layer
Is this done now?
|
Closing to declare victory on this. Making it a layer type was most of the battle. |
…affe#1245 and BVLC/caffe#3211 i.e. https://github.com/BVLC/caffe/blob/master/models/bvlc_reference_caffenet/deploy.prototxt Which is not to say that this page doesn't work anymore, it does for the example given.
The
input
fields cause a few headaches like(1) They are not a proper layer so they cannot be included in all-in-one nets by stage or other NetFilter rules
(2) They are nothing but bare blobs so input preprocessing cannot be configured or done automatically
(3) As a result of (2), the Python and MATLAB interfaces duplicate a lot of code and lead to brittle transitions between train / val / data layers and the
input
fields for deployment.so there's a plan to do away with them. I'll post an issue with the fully story when I can, but the core idea is to replace these fields with
MemoryDataLayer
for deployment, make the tools understand stages so we can mark the layer as the "deploy" input, and then re-define all the reference deploy models and finally deprecate the pycaffe and matcaffe preprocessing code.The deploy.prototxt could go away completely -- just like train and val were merged into train_val.prototxt there will be one net definition to rule them all that includes the layers and rules for making the train / val / deploy / whatever variations of the net. Alternatively one can stamp out each variation through Python net specification.
(1) is the top priority while (2) and (3) might be nice but leaving preprocessing to the interface languages is alright.
The text was updated successfully, but these errors were encountered: