bob issueshttps://gitlab.idiap.ch/bob/bob/-/issues2018-05-19T14:08:52Zhttps://gitlab.idiap.ch/bob/bob/-/issues/209Add support to python 3.5 on Travis2018-05-19T14:08:52ZAndré AnjosAdd support to python 3.5 on Travis*Created by: tiagofrepereira2012*
Python 3.5 was released on September.
We should consider to add the support to this python version in Travis-CI.
Cheers
Tiago*Created by: tiagofrepereira2012*
Python 3.5 was released on September.
We should consider to add the support to this python version in Travis-CI.
Cheers
Tiagohttps://gitlab.idiap.ch/bob/bob/-/issues/182Regression using SVM is not supported2016-08-04T09:32:36ZAndré AnjosRegression using SVM is not supported*Created by: laurentes*
We should either update the documentation and remove options such as NU_SVR, or support the regression task correctly.*Created by: laurentes*
We should either update the documentation and remove options such as NU_SVR, or support the regression task correctly.v2.0https://gitlab.idiap.ch/bob/bob/-/issues/181The evaluation metric "Area Under Curve" (AUC) is missing2015-08-18T16:05:03ZAndré AnjosThe evaluation metric "Area Under Curve" (AUC) is missing*Created by: siebenkopf*
One well-known evaluation metric for binary classification problems is the Area Under (ROC) Curve: http://en.wikipedia.org/wiki/Receiver_operating_characteristic#Area_under_the_curve
It would be nice to have an implementation of it in ``bob.measure``.*Created by: siebenkopf*
One well-known evaluation metric for binary classification problems is the Area Under (ROC) Curve: http://en.wikipedia.org/wiki/Receiver_operating_characteristic#Area_under_the_curve
It would be nice to have an implementation of it in ``bob.measure``.https://gitlab.idiap.ch/bob/bob/-/issues/179No support of log determinant2014-01-04T16:02:46ZAndré AnjosNo support of log determinant*Created by: laurentes*
As said [here](http://docs.scipy.org/doc/numpy/reference/generated/numpy.linalg.det.html), determinant computation is subject to underflow/overflow.
When computing log determinant, this might be avoided by directly working in the log domain. In the python universe, we may rely on numpy.linalg.slogdet(). We should consider to provide such a function in the C++ universe.
Currently, the PLDAMachine class may be subject to underflow/overflow.*Created by: laurentes*
As said [here](http://docs.scipy.org/doc/numpy/reference/generated/numpy.linalg.det.html), determinant computation is subject to underflow/overflow.
When computing log determinant, this might be avoided by directly working in the log domain. In the python universe, we may rely on numpy.linalg.slogdet(). We should consider to provide such a function in the C++ universe.
Currently, the PLDAMachine class may be subject to underflow/overflow.v2.0https://gitlab.idiap.ch/bob/bob/-/issues/176Shift to a non-GPL library for FFT/DCT computation2016-08-04T09:32:26ZAndré AnjosShift to a non-GPL library for FFT/DCT computation*Created by: laurentes*
Bob (1.2.x) currently relies on FFTW for FFT/DCT computation. FFTW has a GPL license. We are now considering to turn the license of Bob from GPL to BSD. This would imply that we should not link any more against GPL libraries. FFTW is the only GPL dependence that we have.
Furthermore, we are looking for alternatives to FFTW. There are already naive implementations of DFT/DCT in bob, which are used for testing purposes. But there are really slow for large arrays. We are hence looking for more optimized source code. I have performed few tests to rely on two different BSD-like FFT libraries:
1. Kiss FFT (C and C++ implementation): I was not able to make the C implementation working with 'double' instead of default 'float'. This just provides wrong outputs. And the documentation is quite poor. The C++ implementation is working with 'double', but it does only support 1D FFT (No nD FFT or DCT computation). However, I still had to tweak/fix the code to make it compatible with all the platforms we are supporting.
2. NumPy's FFT implementation (C code based on former FFTPACK fortran's implementation [P.S.: Note that SciPy also provides a different FFT implementation based on the original FFTPACK fortran's code]:. NumPy's implementation only provide FFT (not DCT). The code is much larger than the one of kiss FFT (2k lines vs 200 lines), but is probably more reliable, since it has been used for several years by this wide deployed library.
For both solutions, we won't add a new dependence, but instead we would just cannibalize the FFT source code into bob central repository (There is no Ubuntu/OS X packages for kiss FFT any way). I have pushed FFT/DCT implementations in the master branch that rely on both libraries (separately), to keep track of all the tests I did. Solution 2. is my favourite so far. If we go for it, I will just remove the FFTW and kiss FFT-based implementations, and renamed the FFT1DNumpy (2D/DCT, etc.) classes into FFT1D. The documentation should then be carefully updated. As the underlying implementation's will be different, this may slightly affect the outputs/features/results generated with FFTW.*Created by: laurentes*
Bob (1.2.x) currently relies on FFTW for FFT/DCT computation. FFTW has a GPL license. We are now considering to turn the license of Bob from GPL to BSD. This would imply that we should not link any more against GPL libraries. FFTW is the only GPL dependence that we have.
Furthermore, we are looking for alternatives to FFTW. There are already naive implementations of DFT/DCT in bob, which are used for testing purposes. But there are really slow for large arrays. We are hence looking for more optimized source code. I have performed few tests to rely on two different BSD-like FFT libraries:
1. Kiss FFT (C and C++ implementation): I was not able to make the C implementation working with 'double' instead of default 'float'. This just provides wrong outputs. And the documentation is quite poor. The C++ implementation is working with 'double', but it does only support 1D FFT (No nD FFT or DCT computation). However, I still had to tweak/fix the code to make it compatible with all the platforms we are supporting.
2. NumPy's FFT implementation (C code based on former FFTPACK fortran's implementation [P.S.: Note that SciPy also provides a different FFT implementation based on the original FFTPACK fortran's code]:. NumPy's implementation only provide FFT (not DCT). The code is much larger than the one of kiss FFT (2k lines vs 200 lines), but is probably more reliable, since it has been used for several years by this wide deployed library.
For both solutions, we won't add a new dependence, but instead we would just cannibalize the FFT source code into bob central repository (There is no Ubuntu/OS X packages for kiss FFT any way). I have pushed FFT/DCT implementations in the master branch that rely on both libraries (separately), to keep track of all the tests I did. Solution 2. is my favourite so far. If we go for it, I will just remove the FFTW and kiss FFT-based implementations, and renamed the FFT1DNumpy (2D/DCT, etc.) classes into FFT1D. The documentation should then be carefully updated. As the underlying implementation's will be different, this may slightly affect the outputs/features/results generated with FFTW.v2.0https://gitlab.idiap.ch/bob/bob/-/issues/171SVD is failing on some matrices because of LAPACK dgesdd2016-08-04T09:32:20ZAndré AnjosSVD is failing on some matrices because of LAPACK dgesdd*Created by: laurentes*
The svd implementation is failing on some matrices, no convergence occuring. The sample matrix is available [here](http://www.idiap.ch/~ichingo/to_download/data_svd_fail.hdf5).
Similarly to NumPy, bob relies on the LAPACK function called dgesdd, as recommended by Netlib maintainers [here](https://groups.google.com/forum/#!topic/julia-dev/mmgO65i6-fA). Using NumPy leads to the exact same issue, whereas matlab implementation seems to work. This is a known problem previously reported [here](http://mail.scipy.org/pipermail/numpy-discussion/2009-February/040212.html). It seems that the slower alternative function from LAPACK called dgesvd is not affected by this problem. One possible solution would be to support both functions.
*Created by: laurentes*
The svd implementation is failing on some matrices, no convergence occuring. The sample matrix is available [here](http://www.idiap.ch/~ichingo/to_download/data_svd_fail.hdf5).
Similarly to NumPy, bob relies on the LAPACK function called dgesdd, as recommended by Netlib maintainers [here](https://groups.google.com/forum/#!topic/julia-dev/mmgO65i6-fA). Using NumPy leads to the exact same issue, whereas matlab implementation seems to work. This is a known problem previously reported [here](http://mail.scipy.org/pipermail/numpy-discussion/2009-February/040212.html). It seems that the slower alternative function from LAPACK called dgesvd is not affected by this problem. One possible solution would be to support both functions.
v2.0https://gitlab.idiap.ch/bob/bob/-/issues/169bob.core.random has many classes for different data types2016-08-04T09:32:16ZAndré Anjosbob.core.random has many classes for different data types*Created by: siebenkopf*
Having a look at the bob.core.random module, I can find several bindings of classes for different data types. Instead of having all these classes, I would suggest two solutions:
1. We have one class for each distribution type and a dtype-like parameter for the constructor.
2. We have only one class *overall*, having the dtype and the distribution type as parameters.
Either of the solutions will break the API, but I think we should avoid these data type specific classes and functions. In C++, these classes are templated, anyways...*Created by: siebenkopf*
Having a look at the bob.core.random module, I can find several bindings of classes for different data types. Instead of having all these classes, I would suggest two solutions:
1. We have one class for each distribution type and a dtype-like parameter for the constructor.
2. We have only one class *overall*, having the dtype and the distribution type as parameters.
Either of the solutions will break the API, but I think we should avoid these data type specific classes and functions. In C++, these classes are templated, anyways...v2.0https://gitlab.idiap.ch/bob/bob/-/issues/159PNG codec does not support image with indexed color2019-04-19T22:41:24ZAndré AnjosPNG codec does not support image with indexed color*Created by: matthiass2*
Given the attached PNG image with indexed color, the bob codec can't read it when using bob 1.2.0:
![image](https://f.cloud.github.com/assets/5189100/960468/362936be-04b8-11e3-8c57-18b69b4ee351.png)
```python
import bob
img=bob.io.load('image.png')
```
The error message is:
"RuntimeError: png codec does not support images with color spaces different than GRAY or RGB"*Created by: matthiass2*
Given the attached PNG image with indexed color, the bob codec can't read it when using bob 1.2.0:
![image](https://f.cloud.github.com/assets/5189100/960468/362936be-04b8-11e3-8c57-18b69b4ee351.png)
```python
import bob
img=bob.io.load('image.png')
```
The error message is:
"RuntimeError: png codec does not support images with color spaces different than GRAY or RGB"v2.0https://gitlab.idiap.ch/bob/bob/-/issues/150Turn within-class and between-class scatter matrices computation into a 'publ...2016-08-04T09:31:41ZAndré AnjosTurn within-class and between-class scatter matrices computation into a 'public' feature*Created by: laurentes*
The computation of the within-class and between-class scatter matrices are currently done in two different classes: FisherLDATrainer and WCCNTrainer. To avoid this duplication of code, we should move this feature into the math module of bob.*Created by: laurentes*
The computation of the within-class and between-class scatter matrices are currently done in two different classes: FisherLDATrainer and WCCNTrainer. To avoid this duplication of code, we should move this feature into the math module of bob.v1.2https://gitlab.idiap.ch/bob/bob/-/issues/145RPM Packages, OBS and Koji2016-08-04T12:27:46ZAndré AnjosRPM Packages, OBS and Koji*Created by: anjos*
> This issue was migrated from bug #104
Like we have Ubuntu packages being built for a variety of Ubuntu platforms, it would be nice to have packages built for OpenSuse and Fedora distros as well.
Here is a place to start:
For Fedora: http://koji.fedoraproject.org/koji/
For Suse: https://build.opensuse.org/
Furthermore, we already have a prototypical RPM skeleton for Bob at https://github.com/bioidiap/bob.rpm
The person that tackles this bug should develop that package with instructions and modifications so we can upload package build requests to one of the above services.*Created by: anjos*
> This issue was migrated from bug #104
Like we have Ubuntu packages being built for a variety of Ubuntu platforms, it would be nice to have packages built for OpenSuse and Fedora distros as well.
Here is a place to start:
For Fedora: http://koji.fedoraproject.org/koji/
For Suse: https://build.opensuse.org/
Furthermore, we already have a prototypical RPM skeleton for Bob at https://github.com/bioidiap/bob.rpm
The person that tackles this bug should develop that package with instructions and modifications so we can upload package build requests to one of the above services.https://gitlab.idiap.ch/bob/bob/-/issues/144Automatic VM generation after a release2019-02-13T14:33:28ZAndré AnjosAutomatic VM generation after a release*Created by: anjos*
> This request was migrated from #104
The idea is to be able to generated, in a completely unattended manner, a VM everytime we have a new release for Bob and that this VM can be used as a reference for other people.
One of the options is to use TinyCore - this distribution is blazing fast and boots quickly:
> 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.*Created by: anjos*
> This request was migrated from #104
The idea is to be able to generated, in a completely unattended manner, a VM everytime we have a new release for Bob and that this VM can be used as a reference for other people.
One of the options is to use TinyCore - this distribution is blazing fast and boots quickly:
> 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.https://gitlab.idiap.ch/bob/bob/-/issues/136Request for new Metrics2016-08-04T09:31:19ZAndré AnjosRequest for new Metrics*Created by: anjos*
A few that can be easily implemented and documented:
* precision and recall
* F1-score
These 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*Created by: anjos*
A few that can be easily implemented and documented:
* precision and recall
* F1-score
These 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