Open MartinThoma opened 8 years ago
I am not sure, whether an Issue is the best way to keep track of the desired features. However I have added my suggestions to the list.
Also it might be productive to hold a feature discussion conference. This might be more efficient than discussion this entirely in github.
I also think a Web Service is very useful, regardless of whether we decide to provide a system deamon. The Web-Service does have a slightly different purpose. It allows the researcher to easily and nicely present the model. This kind of marketing seems to be quite important in CV.
Regarding the Model Zoo it would be nice to find a way to provide the original published model weights. For GoogleNet this should not be a problem, recently a Tensorflow Tutorial on Finetuning Inception was published. For VGG16 this code might be useful.
Providing original weights has two advantages: 1) Comparability 2) Quality. It might be hard to obtain the same quality with self-training, as a lot of hand-optimization might be done and not all hypes are necessarily publishes.
I am not sure, whether an Issue is the best way to keep track of the desired features. However I have added my suggestions to the list.
If you know a better one, feel free to suggest it. To me, it seems that public issues are better than private e-mails, because it documents our thoughts (in case other people are watching this project / want to see why some design decisions were made how they are made).
Also it might be productive to hold a feature discussion conference. This might be more efficient than discussion this entirely in github.
I don't know. I think it is quite hard to formulate what we actually want. Writing it down helps me quite a bit. But we can talk (we somehow forgot after the last PDG)
I also think a Web Service is very useful, regardless of whether we decide to provide a system deamon. The Web-Service does have a slightly different purpose. It allows the researcher to easily and nicely present the model. This kind of marketing seems to be quite important in CV.
This is what I would call "production mode".
Another reason for a daemon: How is the user supposed to interact with his trained model? For example, he might want to do a different analysis than what we provide. (This is not only an example, but a real question: When I executed tv-train
, how do I use the trained model? I guess similar to eval.py - but eval.py is outdated, isn't it?)
I think we should write down where we want TensorVision to go.
tv-train
The user can call it like this:
where the config.json looks as shown here: https://github.com/TensorVision/TensorVision/tree/master#create-json-file
It contains paths to Python scripts which define where the data is (training, testing), how the architecture looks like, what the objective is and how to optimize the model.
tv-analyze
tv-daemon
Start a daemon which can be fed with data and does whatever the model does. This is for production.
tv-web
Starts a web-interface to easily allow third-parties to view the capability of the model. Ideally the Webinterface allows the Web-User to upload a picture themselves and also presents some pre-selected example Images, the user can click on.
Good examples are: https://howhot.io/, https://www.microsoft.com/cognitive-services/en-us/computer-vision-api and http://www.martin-thoma.de/write-math/classify/.
TODOS
Further Futures
(Integration might be discussed)
Finetune
Allow the User to load a pretrained model and finetune it on own data
Continue training
Allow the continuation of an aborted model
Model Zoo
Provide Weights an Architecture for the currently most common Models: