bob issueshttps://gitlab.idiap.ch/bob/bob/-/issues2013-04-05T11:05:11Zhttps://gitlab.idiap.ch/bob/bob/-/issues/114Publication for BOB hidden :-(2013-04-05T11:05:11ZAndré AnjosPublication for BOB hidden :-(*Created by: smarcel*
Hi guys
I suggest to copy the reference for BOB which is currently here:
https://github.com/idiap/bob/wiki/Publications
upfront on the website.
Either on the main page http://idiap.github.com/bob/
and/o...*Created by: smarcel*
Hi guys
I suggest to copy the reference for BOB which is currently here:
https://github.com/idiap/bob/wiki/Publications
upfront on the website.
Either on the main page http://idiap.github.com/bob/
and/or the most visited pages:
https://github.com/idiap/bob/wiki/Releases
http://www.idiap.ch/software/bob/docs/releases/last/sphinx/html/
v1.2https://gitlab.idiap.ch/bob/bob/-/issues/113Merging bob::core::InvalidArgumentException and bob::ip::ParamOutOfBoundaryError2013-03-13T17:28:51ZAndré AnjosMerging bob::core::InvalidArgumentException and bob::ip::ParamOutOfBoundaryError*Created by: laurentes*
The following two exceptions bob::core::InvalidArgumentException and bob::ip::ParamOutOfBoundaryError have the exact same purpose. They should be merged.*Created by: laurentes*
The following two exceptions bob::core::InvalidArgumentException and bob::ip::ParamOutOfBoundaryError have the exact same purpose. They should be merged.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/110IP bug for rgb_to_hsl: returns NaNs2016-08-04T09:30:30ZAndré AnjosIP bug for rgb_to_hsl: returns NaNs*Created by: csmccool*
The floating point implementations of "rgb_to_hsl" return NaNs if you pass an RGB array of ones (1.,1.,1.), however, the integer based methods don't seem to have this issue. Below are some examples of the problem ...*Created by: csmccool*
The floating point implementations of "rgb_to_hsl" return NaNs if you pass an RGB array of ones (1.,1.,1.), however, the integer based methods don't seem to have this issue. Below are some examples of the problem using the python interface:
```python
import bob;
import scipy;
bob.ip.rgb_to_hsl(scipy.array([[[1.]],[[1.]],[[1.]]])) # Using a scipy array or numpy array
```
RETURNS
```python
array([[[ nan]],
[[ nan]],
[[ 1.]]])
```
While
```python
bob.ip.rgb_to_hsl_f(1.,1.,1.)
```
RETURNS
```python
(nan, nan, 1.0)
```
The integer based methods seem to be ok as can be seen below:
```python
bob.ip.rgb_to_hsl_u8(255,255,255)
RETURNS
(0, 0, 255)
bob.ip.rgb_to_hsl_u16(65535,65535,65535)
RETURNS
(0, 0, 65535)
```
Cheers,
Chris.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/109libsvm 3.15 and 3.16 potential crash on svm_free_model_content()2019-07-16T14:50:50ZAndré Anjoslibsvm 3.15 and 3.16 potential crash on svm_free_model_content()*Created by: anjos*
The [following bug](https://trac.macports.org/ticket/37862) must be closed before we can properly release bob-1.2.0. The MacPort will be crippled without this.
The patch (to libsvm) is easy:
```patch
--- svm.c...*Created by: anjos*
The [following bug](https://trac.macports.org/ticket/37862) must be closed before we can properly release bob-1.2.0. The MacPort will be crippled without this.
The patch (to libsvm) is easy:
```patch
--- svm.cpp.orig 2013-01-31 12:03:51.000000000 +0100
+++ svm.cpp 2013-01-31 11:58:02.000000000 +0100
@@ -2747,6 +2747,7 @@
model->probB = NULL;
model->label = NULL;
model->nSV = NULL;
+ model->sv_indices = NULL;
char cmd[81];
while(1)
```
If you have problems using our libsvm bindings under MacPorts, please verify if you are not using one of the two versions of libsvm indicated in this bug report. If so, downgrade it to 3.14. or re-build it with the fix applied.
The author of libsvm has been informed of this problem and also the MacPorts maintainer. Both received the same patch instructions.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/107Warnings in bash scripts caused by CYGWIN check2016-08-04T09:30:24ZAndré AnjosWarnings in bash scripts caused by CYGWIN check*Created by: laurentes*
Recently, we introduced a specific test to set the PATH properly for CYGWIN in the following bash scripts:
- python/bin/gdbpy.in
- python/bin/ipython.in
- python/bin/python.in
This generates the following k...*Created by: laurentes*
Recently, we introduced a specific test to set the PATH properly for CYGWIN in the following bash scripts:
- python/bin/gdbpy.in
- python/bin/ipython.in
- python/bin/python.in
This generates the following kind of warnings under Ubuntu
```sh
./bin/python: 5: [: unexpected operator
```v1.2https://gitlab.idiap.ch/bob/bob/-/issues/106Blitz++ misdetection does not stop the build2013-03-07T11:10:47ZAndré AnjosBlitz++ misdetection does not stop the build*Created by: anjos*
Testing this unexpected feature of our build system on Arch Linux's buggy Blitz++ installation (no pkg-config for Blitz++ was available), made me realize that, at no times, we have a provision for a failed Bltiz++ de...*Created by: anjos*
Testing this unexpected feature of our build system on Arch Linux's buggy Blitz++ installation (no pkg-config for Blitz++ was available), made me realize that, at no times, we have a provision for a failed Bltiz++ detection or that it is not working adequately. A fix must be inserted before the next release.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/105Distance in KMeansMachine is square Euclidean2016-08-04T09:30:21ZAndré AnjosDistance in KMeansMachine is square Euclidean*Created by: laurentes*
Preparing the Bob tutorial, I've just noticed that the distance returned by the getDistanceFromMean() method of the KMeansMachine class is not the Euclidean distance, but the square Euclidean distance. This is no...*Created by: laurentes*
Preparing the Bob tutorial, I've just noticed that the distance returned by the getDistanceFromMean() method of the KMeansMachine class is not the Euclidean distance, but the square Euclidean distance. This is not a real problem because of the bijection between these two, but to my mind, this needs to be updated.
For this purpose, we need to update/add tests, and make sure that it does not affect our baseline results.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/104Wishes for the next major release (1.2.0)2019-02-13T14:33:28ZAndré AnjosWishes for the next major release (1.2.0)*Created by: laurentes*
I've decided to create a thread to help us to converge towards a better Bob for the next major release. I doubt we will have the time to deal with everything shortly, but there will be at least a trace of it. Fee...*Created by: laurentes*
I've decided to create a thread to help us to converge towards a better Bob for the next major release. I doubt we will have the time to deal with everything shortly, but there will be at least a trace of it. Feel free to update this thread with your thoughts/wishes.
## To consolidate what is already there
1. The user guide is already fairly good. I would not say the same about the documentation of the python bindings that show up when using the `help()` function of python. For many functions/classes, this documentation is very limited and unhelpful.
2. The library is becoming larger. We should have stricter rule when defining class methods that refers to the same concept. For instance, very often, we have a variable related to the input/feature dimensionality. Depending on the class, it might be obtained using a 'getDimD()', 'inputDims()', or whatsoever. I think this is very annoying from a user perspective. Same for the API of the trainers.
3. For many functions, we have two different kinds of python bindings: one kind which follows the C++ API (e.g. void f(const BA& input, BA& output)), and one which is more
'pythonic' (e.g. BA f(const BA& input)). These two bindings often share the same python function name. I don't think this is a good strategy, as these sometimes leads to impossible cases when the C++ API has many overloaded functions. I think the function name should reflect this difference. OpenCV strategy was roughly to used two different namespaces (cv for the C like functions, and cv2 for the pythonic one). We could do something slightly different such as appending the function name with something like '_c' or '_cc' to clearly highlight this fact.
4. ~~As previously discussed, the LBP code could be refactored in a single more generic but parametrized class.~~ (Already done by Manuel)
5. Learning from our previous experiences, I would be in favour of making mandatory a version number to any class that provides a 'save_to_hdf5' method.
6. ~~Add a tutorial for the Audio Processing module~~ (Already done by Elie)
7. Provide is_similar_to(const Object& b, const double epsilon=1e-8) functions for all C++ classes that have double members. The default "==" and "!=" operators are largely useless when we want to provide code that runs on several platforms (i.e., 32 and 64 bit machines).
8. ~~Whenever a C++ class uses some random initialization, make sure that you can seed this randomness.~~ (cf. issue #121 )
## To integrate new features
A. I would be nice that the combination of NumPy/SciPy/Bob roughly provides the same functionalities as the Matlab built-in functions. It would also be good to use similar function names such that it is easy for a user to move accross these platforms. A (too exhaustive) list can be found here: http://www.mathworks.ch/ch/help/matlab/functionlist.html
B. More Machine Learning algorithms:
B.1 In particular to add a Hidden Markov Model implementation, as there was one in late Torch 3.
B.2. To add a deformable and parts-based object recognition system (Felzenszwalb-like)
~~B.3 Integration of the i-vector framework~~ (Already done by Laurent)
C. More Audio Processing features:
C.1 Possibility to ~~compute and~~ plot spectrograms (Already done)
C.2 Audio codec to deal with wav and sphere files
C.3 Provide a bridge to HTK
C.4 Boosted Binary Features (cf. Anindya's thesis)
D. Image Processing Tools
~~D.1 GLCM features (Grey-Level Co-occurence Matrix)~~ (Already done by Ivana)
E. ~~Make compiling C++ bindings on satellite packages easier - we can move most of the functionality currently implemented on those packages like https://github/com/bioidiap/xbob.optflow.liu to the core of Bob.~~ (done by André)
F. New metrics: F1-score, precision and recall; cost versus training set size - This should be simple and an excellent coding exercise. If anyone wants to give it a go, please let me know. More info: http://en.wikipedia.org/wiki/F1_score
G. Better use of optimization library (L-BFGS-B) for NNet backprop implementation - this is a somewhat larger piece of work that goes around revisiting the NNet implementation to separate the optimizer from the trainer.
## To be more widely supported
1. ~~To make the Windows/Cygwin port functional~~ (cf. issue #82 )
2. To generate RPM like package:
* For Fedora: http://koji.fedoraproject.org/koji/
* For Suse: https://build.opensuse.org/
3. To generate a package for the TinyCore distribution: http://distro.ibiblio.org/tinycorelinux/downloads.html
In particular, it would be nice to automatize the process of generating a VirtualBox VDI with bob install, potentially based on the tiny linux distribution TinyCore.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/103Cepstral features finalization2016-08-04T09:30:16ZAndré AnjosCepstral features finalization*Created by: laurentes*
In order to finalize the Cepstral features extraction, there is a need to:
- Add default values in constructor (+python bindings) (done by @laurentes but please check default values)
- Make parameters names c...*Created by: laurentes*
In order to finalize the Cepstral features extraction, there is a need to:
- Add default values in constructor (+python bindings) (done by @laurentes but please check default values)
- Make parameters names comparable to the ones from existing software such as HTK
- Document methods in header and add inline comments directly in the code when required
- Add more tests with various parameters
- Add copy constructor, assignment operator, comparison operatorsv1.2https://gitlab.idiap.ch/bob/bob/-/issues/94Some mismatch in EER between bob and Bosaris2016-08-04T09:29:50ZAndré AnjosSome mismatch in EER between bob and Bosaris*Created by: khoury*
The EER computed by bob_compute_perf.py is little bit higher than the one using Bosaris Toolkit.
Here is the link for Bosaris Toolkit:
https://sites.google.com/site/bosaristoolkit/*Created by: khoury*
The EER computed by bob_compute_perf.py is little bit higher than the one using Bosaris Toolkit.
Here is the link for Bosaris Toolkit:
https://sites.google.com/site/bosaristoolkit/v1.2https://gitlab.idiap.ch/bob/bob/-/issues/90Version of Bob at configuration time is not trasmitted to setup.py2012-10-09T20:56:56ZAndré AnjosVersion of Bob at configuration time is not trasmitted to setup.py*Created by: anjos*
If I start Idiap's Bob:
```python
>>> import pkg_resources
>>> pkg_resources.require('bob')[0]
bob 1.1.0a0 (/usr/lib/pymodules/python2.6)
```
This needs fixing before release 1.1.1.*Created by: anjos*
If I start Idiap's Bob:
```python
>>> import pkg_resources
>>> pkg_resources.require('bob')[0]
bob 1.1.0a0 (/usr/lib/pymodules/python2.6)
```
This needs fixing before release 1.1.1.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/88Bob opportunistically links against Qt42016-08-04T09:29:40ZAndré AnjosBob opportunistically links against Qt4*Created by: anjos*
The current way the build is structured, there is no flag that allows us switching off ~~OpenCV and~~ Qt4 dependences. If they are available on the target system, they are compiled and linked into the final binaries....*Created by: anjos*
The current way the build is structured, there is no flag that allows us switching off ~~OpenCV and~~ Qt4 dependences. If they are available on the target system, they are compiled and linked into the final binaries.
This behavior is incompatible with packaging tools in which you can describe to which packages another package may depend on. If Bob opportunistically links against what is available, the packaging system will not detect real dependences and avoid, for example, OpenCV to be removed without Bob being removed first.
For the time being, a solution would be to make the build systems always install all dependencies.
This bug was triggered by a bug reported to us on MacPorts: https://trac.macports.org/ticket/36491v1.2https://gitlab.idiap.ch/bob/bob/-/issues/86Arrayset new features and improvements2016-08-04T09:29:36ZAndré AnjosArrayset new features and improvements*Created by: laurentes*
There are two new features that would be nice for the bob.io.Arrayset class.
1. There is currently no way to clear the content of an arrayset. The two options are a. to iterate over and delete the elements one b...*Created by: laurentes*
There are two new features that would be nice for the bob.io.Arrayset class.
1. There is currently no way to clear the content of an arrayset. The two options are a. to iterate over and delete the elements one by one or b. to delete the python object. It would be nice to introduce a clear() method.
2. There are only two possible states for an Arrayset:
* ``external`` where the content is in a file
* ``inlined`` where the content is stored in a set of bob.io.Arrays (as many as the number of samples in the Arrayset).
The ``inlined`` version might introduce a significant overhead when the Arraysets consists of many small Arrays, as in this case, there are as many Array headers as samples.
One solution would be to have a third state which stores the sample in a single Array, and where samples are obtained by slicing this Array over the third dimension.
Below is an example to highlight the problem:
Firstly, we allocate 50 samples of dimensions 1024*1024 double's, that is 400MBytes overall.
```python
import numpy, bob
A=bob.io.Arrayset(numpy.random.rand(50,1024*1024))
```
The memory usage reported (using command line tool "top") is roughly 400MB.
Secondly, we allocate 1024*1024 samples of dimensions 50 double's, that is 400MBytes overall as well.
```python
import numpy, bob
A=bob.io.Arrayset(numpy.random.rand(1024*1024,50))
```
The memory usage reported is about 800MB, which means an overhead of 100%. In particular, this occurs in common UBM/GMM experiments. Furthermore, it would be nice to find a fix.
Any suggestion is welcome.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/27Usage of abbreviations in namespaces2016-08-04T09:27:37ZAndré AnjosUsage of abbreviations in namespaces*Created by: siebenkopf*
When I try to read some C++ code of Bob, I often step over an abbreviated namespace (like tp for bob::python). Also in the python code, sometimes packages are abbreviated or, even worse, "from xxx import yyy as ...*Created by: siebenkopf*
When I try to read some C++ code of Bob, I often step over an abbreviated namespace (like tp for bob::python). Also in the python code, sometimes packages are abbreviated or, even worse, "from xxx import yyy as zzz" is used. This makes the code really hard to read since I always have to scroll up to the definition of abbreviation to understand, what is actually called.
I definitely would go for removing all these abbreviations and using the fully qualified names. I know that writing code this way may take a little longer, but I think it is worth the time. And most of the editors provide automatic source completion, that speeds up the typing.
What do you think about this?v1.2