I-vector extractor and ISV/JFA consolidation
Created by: laurentes
As discussed in ticket #104 (closed) and internally at Idiap, I've finally started to work on an i-vector extractor. As there are strong links with Joint Factor Analysis, I will have to factorize some pieces of code (ISV/JFA machine and trainer). This will affect the API of the master branch.
After some preliminary work, this will involve:
- To define separate classes for ISV and JFA (for both machine and trainer)
- To rely on the newly defined functions from bob::core for the operator==(), operator!=() and is_similar_to() methods which will make the code easier to maintain and smaller
- To define a helper method to be able to load ISV/JFA models previously saved
- To add a seed parameter (with getter/setter) to the trainers
- Wrt. API standardization, a machine must have a forward() method, as well as the possibility to be saved/loaded to/from an HDF5 file. I will hence update the bob::machine::Machine class accordingly. This way, we could set the API once (for the forward()/load()/save() methods and eventually others) for all the classes (of a specific template specialization). This would at the end lead to much less work to make sure that the API remains consistent across machines.
- Another point discussed was whether a trainer might change the hyperparameters of a machine. I'm against this option, and the optimal strategy is probably as follows: a machine has hyperparameters (features/subspace dimensionality, etc.). When a machine is passed to a trainer, these hyperparameters must have been set previously. This way, we clearly identify what are the duties of a trainer, and we don't have parameters which are both parameters of a machine and a trainer.
- To add a tutorial on this part
- To update the docstring of the python bindings with references (likely to Crim's work and our work)