bob issueshttps://gitlab.idiap.ch/groups/bob/-/issues2016-08-04T09:28:44Zhttps://gitlab.idiap.ch/bob/bob/-/issues/56subworld 'onethird' of mobio is empty2016-08-04T09:28:44ZAndré Anjossubworld 'onethird' of mobio is empty*Created by: siebenkopf*
Dear Bobbers,
I just found out that the 'onethird' subworld of the mobio database does not seem to work correctly:
>>> files = bob.db.mobio.Database().files(groups='world', subworld='onethird')
>>> print len(f...*Created by: siebenkopf*
Dear Bobbers,
I just found out that the 'onethird' subworld of the mobio database does not seem to work correctly:
>>> files = bob.db.mobio.Database().files(groups='world', subworld='onethird')
>>> print len(files)
0
The 'twothirds' subworld works:
>>> files = bob.db.mobio.Database().files(groups='world', subworld='twothirds')
>>> print len(files)
1224
though it is not really 2/3 of the database:
>>> files = bob.db.mobio.Database().files(groups='world')
>>> print len(files)
9600
I guess that there is something wrong with the protocols...
Cheers
Manuelhttps://gitlab.idiap.ch/bob/bob/-/issues/55Inappropriate documentation and inconsistencies in the LFW database2016-08-04T09:28:41ZAndré AnjosInappropriate documentation and inconsistencies in the LFW database*Created by: siebenkopf*
The documentation of the functions inside the In the bob.db.lfw.Database are incomplete/misleading:
- What is the difference between "clients", "clients_ids" and "clients_names"? Is the "clients_names" informat...*Created by: siebenkopf*
The documentation of the functions inside the In the bob.db.lfw.Database are incomplete/misleading:
- What is the difference between "clients", "clients_ids" and "clients_names"? Is the "clients_names" information really important for out purpose?
- The documentation of the "protocol" and "groups" parameters is misleading. If there are no groups and no protocols defined, either remove these keywords or document that these parameters are ignored.
- The documentation of the "files" method is incorrect since the method only returns the file names.
Furthermore, there are inconsistencies with other databases:
- To be consistent with other databases, the "clients" function should return the list of client ids, but it returns a list of tuples (client_id, client_name).
Additionally, I don't find a way to use the "unrestricted" training configuration that might be useful to train our algorithms. Is it possible to retrieve the required data for that?https://gitlab.idiap.ch/bob/bob/-/issues/54LBPTopOperator is untested and seems to be buggy2016-08-04T09:28:38ZAndré AnjosLBPTopOperator is untested and seems to be buggy*Created by: laurentes*
The current LBPTopOperator implementation is a port of some older torch5spro code. Unfortunately, it suffers from the following problems (non-exhaustive list):
- No unit test!
- Does not seem to work!
- Poor pyth...*Created by: laurentes*
The current LBPTopOperator implementation is a port of some older torch5spro code. Unfortunately, it suffers from the following problems (non-exhaustive list):
- No unit test!
- Does not seem to work!
- Poor python bindings (no helper functions to get information about the expected size of the output)
- Generic C++ core exceptions rather than specialized ones
- Few check on the input/output array size are performed
This requires some serious revision.v1.1https://gitlab.idiap.ch/bob/bob/-/issues/53Problem with eigenface.py in bob.example.faceverify2016-08-04T09:28:36ZAndré AnjosProblem with eigenface.py in bob.example.faceverify*Created by: smarcel*
/remote/filer.gx/user.active/marcel/work/development/bob/packages/bob.example.faceverify
beaufix27:bob.example.faceverify> ./linux/eigenface.py
Training PCA machine
Extracting models
Traceback (most recent c...*Created by: smarcel*
/remote/filer.gx/user.active/marcel/work/development/bob/packages/bob.example.faceverify
beaufix27:bob.example.faceverify> ./linux/eigenface.py
Training PCA machine
Extracting models
Traceback (most recent call last):
File "./linux/eigenface.py", line 13, in <module>
faceverify.eigenface.main()
File "/remote/filer.gx/user.active/marcel/work/development/bob/packages/bob.example.faceverify/faceverify/eigenface.py", line 107, in main
model_features[key] = extract_feature(image, pca_machine)
File "/remote/filer.gx/user.active/marcel/work/development/bob/packages/bob.example.faceverify/faceverify/eigenface.py", line 57, in extract_feature
pca_machine(image.flatten(), projected_feature)
TypeError: cannot wrap numpy.ndarray(float64,1) as blitz::Array<float64,2> - dimensions do not match
https://gitlab.idiap.ch/bob/bob/-/issues/52IP Block - Get output shape - Two different functions for similar purpose2016-08-04T09:28:34ZAndré AnjosIP Block - Get output shape - Two different functions for similar purpose*Created by: laurentes*
I've just noticed that there are two different functions for similar purpose in the IP block decomposition code. To get the expected number of blocks given an input array and some parameters, both `getBlockShape(...*Created by: laurentes*
I've just noticed that there are two different functions for similar purpose in the IP block decomposition code. To get the expected number of blocks given an input array and some parameters, both `getBlockShape()` and `getNBlocks()` could be used.
For the next release, we should remove one of them and update the bits which rely on these functions accordingly (at the C++ level, `DCTFeatures` and `LBPHSFeatures`).v1.1https://gitlab.idiap.ch/bob/bob/-/issues/51Search Engine Optimisation, and consolidation of links2016-08-04T09:28:32ZAndré AnjosSearch Engine Optimisation, and consolidation of links*Created by: Waldo000000*
Googling for Bob returns poor results. e.g.
* Searching for "bob toolbox" or "bob toolkit" or "bob library" or "bob signal processing" all fail to return a link to http://idiap.github.com/bob/ on the first ...*Created by: Waldo000000*
Googling for Bob returns poor results. e.g.
* Searching for "bob toolbox" or "bob toolkit" or "bob library" or "bob signal processing" all fail to return a link to http://idiap.github.com/bob/ on the first page of results.
* Searching for "bob idiap" returns a link to the github page (https://github.com/idiap/bob), not the home page, as first result.
* Searching for "bob biometrics" returns the correct link but only at 5th position
* Searching for "bob machine learning" has the link in 2nd position
To address this issue, we should follow relevant instructions in Google's Webmaster Tools, for example:
* [Webmaster Guidelines](http://support.google.com/webmasters/bin/answer.py?hl=en&answer=35769)
* [Search Engine Optimization (SEO)](http://support.google.com/webmasters/bin/answer.py?hl=en&answer=35291)
Finally, we need to decide whether the advertised home page of Bob is http://idiap.github.com/bob/ (as was noted in the recent announcement emails) or http://www.idiap.ch/software/bob. There is currently a link at the top of https://github.com/idiap/bob that points to http://www.idiap.ch/software/bob that redirects to http://idiap.github.com/bob/. So anyone who "bookmarks" the Bob homepage right now is bookmarking http://idiap.github.com/bob/. If we are happy with that URL, we should edit the link on https://github.com/idiap/bob accordingly. Making this choice of a single homepage URL may in turn help us to improve search results.v1.1https://gitlab.idiap.ch/bob/bob/-/issues/50Solving/Simplifying the RPATH or INSTALL_DIR2016-08-04T09:28:29ZAndré AnjosSolving/Simplifying the RPATH or INSTALL_DIR*Created by: anjos*
Currently, to build our Ubuntu or OSX packages, we need to disable the setting of these variables as files get moved during installation using `debuild` or `MacPorts`. Here is a strategy to get rid of this annoyance:...*Created by: anjos*
Currently, to build our Ubuntu or OSX packages, we need to disable the setting of these variables as files get moved during installation using `debuild` or `MacPorts`. Here is a strategy to get rid of this annoyance:
1. Move the library `_core_array.so` to the `<prefix>/lib` directory and version it properly
2. Make all other python bindings depend on that instead of a library hidden at python directories
3. Make the python bindings use the RPATH by default (this is disabled when the user passes `-DCMAKE_SKIP_BUILD_RPATH=TRUE` to CMake. Under OSX, have a similar mechanism that will do that for the INSTALL_DIR property.
Notes:
1. The RPATH functionality is only required for the python bindings
2. The python bindings only require that functionality if the libraries they depend on are not installed in a standard location.https://gitlab.idiap.ch/bob/bob/-/issues/49On any Ubuntu version, bob gets linked to libvl.so2016-08-04T09:28:28ZAndré AnjosOn any Ubuntu version, bob gets linked to libvl.so*Created by: anjos*
The problem is that the pre-compiled Ubuntu versions are now depending on libvl.so instead of depending on libvl.so.0
If you have a 12.04 somewhere, you can test this. Just uninstall libvl0.
Now, install bob from...*Created by: anjos*
The problem is that the pre-compiled Ubuntu versions are now depending on libvl.so instead of depending on libvl.so.0
If you have a 12.04 somewhere, you can test this. Just uninstall libvl0.
Now, install bob from our ppa. Fire-up python and then try to import bob. You will get the error:
```sh
$ python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import bob
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/pymodules/python2.6/bob/__init__.py", line 16, in <module>
from . import ip
File "/usr/lib/pymodules/python2.6/bob/ip/__init__.py", line 1, in <module>
from ._ip import *
ImportError: libvl.so: cannot open shared object file: No such file or directory
```
This can be (temporarily) fixed with the following commands:
```sh
$ sudo apt-add-repository ppa:biometrics/vlfeat
$ sudo apt-get update
$ sudo apt-get install libvl-dev
```
Besides, our packages do not (yet) depend on the packages libvl0 or libblitz1ldbl. They should.https://gitlab.idiap.ch/bob/bob/-/issues/48Bob, RPATH policy and versions on shared objects2016-08-04T09:28:26ZAndré AnjosBob, RPATH policy and versions on shared objects*Created by: anjos*
The current infrastructure does not use the properties VERSION (build) and SOVERSION (api) for marking the C++ libraries. I'm not sure the same should be done for python bindings written with Boost.Python.
Further...*Created by: anjos*
The current infrastructure does not use the properties VERSION (build) and SOVERSION (api) for marking the C++ libraries. I'm not sure the same should be done for python bindings written with Boost.Python.
Furthermore, when installing Bob globally, the RPATH mechanism should be disabled as it is totally useless.https://gitlab.idiap.ch/bob/bob/-/issues/47ImageMagick 6.7.6 issues on OSX with MacPorts2012-04-07T07:46:49ZAndré AnjosImageMagick 6.7.6 issues on OSX with MacPorts*Created by: anjos*
ImageMagick 6.7.6 is now shipping with MacPorts on OSX. Some of the tests do not pass anymore. The image codec one, in particular, prints out (after some modifications so it is a little more specific on error reporti...*Created by: anjos*
ImageMagick 6.7.6 is now shipping with MacPorts on OSX. Some of the tests do not pass anymore. The image codec one, in particular, prints out (after some modifications so it is a little more specific on error reporting):
Running 7 test cases...
unknown location:0: fatal error in "image_gif": std::runtime_error: file '/var/folders/b3/7l98n3bd7dqc1stjmgxb9mbw0000gn/T/bobtest_core_binformatTOI4GA.gif' is not readable because ImageMagick '6.7.6' reports: Magick:
invalid colormap index `/var/folders/b3/7l98n3bd7dqc1stjmgxb9mbw0000gn/T/bobtest_core_binformatTOI4GA.gif' @ error/image.c/SyncImage/4414
/Users/andre/work/bob/cxx/io/test/image_codec.cc:96: last checkpoint
unknown location:0: fatal error in "image_png": std::runtime_error: file '/var/folders/b3/7l98n3bd7dqc1stjmgxb9mbw0000gn/T/bobtest_core_binformatlaNEuy.png' is not readable because ImageMagick '6.7.6' reports: Magick:
invalid colormap index `/var/folders/b3/7l98n3bd7dqc1stjmgxb9mbw0000gn/T/bobtest_core_binformatlaNEuy.png' @ error/image.c/SyncImage/4414
/Users/andre/work/bob/cxx/io/test/image_codec.cc:96: last checkpoint
*** 2 failures detected in test suite "ImageArrayCodec Tests"https://gitlab.idiap.ch/bob/bob/-/issues/46SVD segfaults (BLAS function) on Ubuntu 32 bits when using blitz 0.10 hg2016-08-04T09:28:23ZAndré AnjosSVD segfaults (BLAS function) on Ubuntu 32 bits when using blitz 0.10 hg*Created by: laurentes*
We have noticed that the SVD was crashing on Ubuntu 32 bits, when using the latest release of blitz++ from mercurial. Strangely, this only happens with this particular combination of platform and blitz version, a...*Created by: laurentes*
We have noticed that the SVD was crashing on Ubuntu 32 bits, when using the latest release of blitz++ from mercurial. Strangely, this only happens with this particular combination of platform and blitz version, and hence no problem is encountered when using 64 bits versions of Ubuntu or the latest but old 0.9 release of blitz++, even when using valgrind.
The crash is caused by a segmentation fault, and gdb reports the following:
```
Program received signal SIGSEGV, Segmentation fault.
0xb6e4f19b in ATL_dgemvT_a1_x1_b0_y1 () from /usr/lib/libblas.so.3gf
```
There are many tickets for other libraries using BLAS which report similar problem with this particular function, but none of them really explain the cause of the problem. This might be related to some data alignment issue.
[NumPy/SciPy](http://projects.scipy.org/numpy/ticket/551)
[gnome-mousetrap](https://bugs.launchpad.net/ubuntu/+source/gnome-mousetrap/+bug/732927)
[OpenCV1](https://bugs.launchpad.net/ubuntu/+source/opencv/+bug/684302)
[OpenCV2](http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610400)
The workaround that we have currently chosen is to copy the data of the blitz::Array's to/from C-style arrays, only for the linux 32 bits implementation of the SVD.v1.1https://gitlab.idiap.ch/bob/bob/-/issues/45Some eye labels of the MoBio database are incorrect2016-08-04T09:28:19ZAndré AnjosSome eye labels of the MoBio database are incorrect*Created by: siebenkopf*
By applying a simple sanity check on the eye positions (le.x > re.x) I found a few eye positions that are labeled incorrectly. The complete list of files will follow soon.
Mixing up the eye positions ends up ...*Created by: siebenkopf*
By applying a simple sanity check on the eye positions (le.x > re.x) I found a few eye positions that are labeled incorrectly. The complete list of files will follow soon.
Mixing up the eye positions ends up in getting a face that is upside-down during preprocessing. Hence, the proprocessing generates invalid files.https://gitlab.idiap.ch/bob/bob/-/issues/44Exception Raising with HDF5-related file manipulation ends in segfault2016-08-04T09:28:17ZAndré AnjosException Raising with HDF5-related file manipulation ends in segfault*Created by: anjos*
This example will trigger it:
```python
import bob
f = bob.io.HDF5File('test.hdf5', 't')
f.set('bla', 3)
del f
m = bob.machine.LinearMachine(3,3)
# saving on read-only file, exception is raised and then Pyth...*Created by: anjos*
This example will trigger it:
```python
import bob
f = bob.io.HDF5File('test.hdf5', 't')
f.set('bla', 3)
del f
m = bob.machine.LinearMachine(3,3)
# saving on read-only file, exception is raised and then Python segfaults on exit()
m.save(bob.io.HDF5File('test.hdf5'))
```v1.0https://gitlab.idiap.ch/bob/bob/-/issues/43Writing external code that depends on Bob2016-08-04T09:28:15ZAndré AnjosWriting external code that depends on Bob*Created by: anjos*
Sometime ago we had the ability to compile external projects against Bob using CMake. Our CMake development environment does export its properties and all those files get installed properly. Remains untested though:
...*Created by: anjos*
Sometime ago we had the ability to compile external projects against Bob using CMake. Our CMake development environment does export its properties and all those files get installed properly. Remains untested though:
1. How to compile C++ extensions using Bob libraries
2. How to compile Python C++ bindings using Bob libraries and extensions to boost.python (e.g. const_ndarray objects)
This bug should remain opened until we get this functionality back.https://gitlab.idiap.ch/bob/bob/-/issues/42No range check of std::vector in DEBUG mode2016-08-04T09:28:13ZAndré AnjosNo range check of std::vector in DEBUG mode*Created by: siebenkopf*
In the current version of Bob, there is no range check on the std::vector::operator [] and no sanity checks for std::...iterator's. Unfortunately, the proposed method for GnuCC, i.e., adding the compiler flag "-...*Created by: siebenkopf*
In the current version of Bob, there is no range check on the std::vector::operator [] and no sanity checks for std::...iterator's. Unfortunately, the proposed method for GnuCC, i.e., adding the compiler flag "-D_GLIBCXX_DEBUG" interferes with:
+ some functionalities of Boost, like the boost::program_options
+ also Boost.Python seems to be affected
+ the -DBZ_DEBUG flag to enable range checking in blitz::Arrays also seems to affect this (not sure)
by adding C++ linking errors.
The proposed solutions on the internet suggest to compile boost (and blitz) with the -D_GLIBCXX_DEBUG. Unfortunately, this would require to ship the compiled versions of boost (and blitz) with Bob.
A workaround for at least the indexing check would be to used the std:: vector::at(i) function instead, which does the range checking. Unfortunately, the range check is not disabled in release mode. This could be solved by:
#ifndef DEBUG
#define at(x) operator[](x)
#endif
(another solution I found in the net), but this of course would influence ALL at() functions...
Another workaround (which we had in our old software system) is to use our own derived class from the std::vector that actually does the range check (only in debug mode) and calls the operator::[] of the std::vector. Unfortunately, this is very ugly since it requires to re-write (at least) all constructors of the std::vector.v1.1https://gitlab.idiap.ch/bob/bob/-/issues/41Add an example of a satellite package2016-08-04T09:28:10ZAndré AnjosAdd an example of a satellite package*Created by: laurentes*
There is currently no example of a satellite package for Bob. It would be nice to introduce one. For this purpose, we could recycle the former face_verification submodule of bob, providing simple scripts for feat...*Created by: laurentes*
There is currently no example of a satellite package for Bob. It would be nice to introduce one. For this purpose, we could recycle the former face_verification submodule of bob, providing simple scripts for feature extraction and verification.https://gitlab.idiap.ch/bob/bob/-/issues/40Unit test for SIFT features extraction based on VLFeat fails on Ubuntu 12.04 ...2016-08-04T09:28:08ZAndré AnjosUnit test for SIFT features extraction based on VLFeat fails on Ubuntu 12.04 32bits*Created by: laurentes*
There is currently an issue with the test of the *SIFT* features under *Ubuntu 12.04 32 bits*. For unknown reason, the *SIFT* descriptors computed by *Ubuntu 12.04 32 bits* are different from the reference one ge...*Created by: laurentes*
There is currently an issue with the test of the *SIFT* features under *Ubuntu 12.04 32 bits*. For unknown reason, the *SIFT* descriptors computed by *Ubuntu 12.04 32 bits* are different from the reference one generated with *Ubuntu 10.04 32 bits*. This happens despite the fact that we are using the exact same version of *VLFeat 0.9.14* (last release), and that *VLFeat* has almost no external dependence:
```
$ ldd /usr/lib/libvl.so
linux-gate.so.1 => (0x00b52000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x00412000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0x0073c000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00174000)
/lib/ld-linux.so.2 (0x00b8b000)
```
Tracking the problem, it likely originates from the keypoint detection, as there is no such an issue with the *Dense SIFT* features, which also relies on *VLFeat*. I guess that some of them are slightly below the threshold to be considered as keypoints on 12.04 but slightly above on 10.04. This is particularly annoying as this then shift the whole keypoints, making the comparison of the descriptors tough.
There are three possible options:
- Remove the test, considering that this is a VLFeat issue
- Add additional references and checking that one of them matches the values generated
- Add a more clever test. which will allow some keypoints more (or less), and able to still match the descriptors in such a situation.
Personally, I will go for the first one.v1.0https://gitlab.idiap.ch/bob/bob/-/issues/39FisherLDATrainer does not have a zscore_convert option2016-08-04T09:28:06ZAndré AnjosFisherLDATrainer does not have a zscore_convert option*Created by: ivana7c*
In contrast to SVDPCATrainer, the FisherLDATrainer does not have the zscore_convert option. It would be nice to add this option for consistency.*Created by: ivana7c*
In contrast to SVDPCATrainer, the FisherLDATrainer does not have the zscore_convert option. It would be nice to add this option for consistency.v1.1https://gitlab.idiap.ch/bob/bob/-/issues/38VLFeat is not detected despite installation2016-08-04T09:28:03ZAndré AnjosVLFeat is not detected despite installation*Created by: anjos*
From my understanding of the cmake file, we should see a printout when VLFeat is detected on the system:
```
Found VLFeat: /usr/lib/libvlfeat.so
```
But we don't seem to see this line ever. Could you make sur...*Created by: anjos*
From my understanding of the cmake file, we should see a printout when VLFeat is detected on the system:
```
Found VLFeat: /usr/lib/libvlfeat.so
```
But we don't seem to see this line ever. Could you make sure that it is properly detected and reported?v1.0https://gitlab.idiap.ch/bob/bob/-/issues/37Sphinx generates URL to non-existing `source code` pages in the documentation...2016-08-04T09:28:01ZAndré AnjosSphinx generates URL to non-existing `source code` pages in the documentation when using the plot extension with inline code*Created by: laurentes*
The plot extension of sphinx is always generating a *source code* URL when using the `.. plot::` directive. This is particularly annoying when inline python code is used after this directive, as sphinx will still...*Created by: laurentes*
The plot extension of sphinx is always generating a *source code* URL when using the `.. plot::` directive. This is particularly annoying when inline python code is used after this directive, as sphinx will still generate an URL pointing to a file which does not exist. There are two potential solutions:
- Either we find a way to disable the generation of the *source code* URL. I've looked at the sphinx documentation without success so far.
- Or we should always create an external python file which will be used by the `.. plot::` directive.
This currently affects the tutorial about the *measure* submodule of Bob.v1.0