bob issueshttps://gitlab.idiap.ch/groups/bob/-/issues2016-08-04T12:27:46Zhttps://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 pl...*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/146bob-config.cmake2016-08-04T09:31:37ZAndré Anjosbob-config.cmake*Created by: neodark*
Hello,
It's a great idea to have the bob-config.cmake in the <install_folder>/lib/bob/bob-config.cmake
There's just a small bug at the generation of this 2 lines in the file (I have spotted the error with <This p...*Created by: neodark*
Hello,
It's a great idea to have the bob-config.cmake in the <install_folder>/lib/bob/bob-config.cmake
There's just a small bug at the generation of this 2 lines in the file (I have spotted the error with <This path is not correct>):
get_filename_component(bob_INCLUDE_DIRS "<This path is not correct>" ABSOLUTE)
get_filename_component(bob_LIBRARY_DIRS "<This path is not correct>" ABSOLUTE)
<This path is not correct> should be replaced by <path to installed bob folder>/include for the first line and <path to installed bob folder>/lib for the second line
Cheers,
Flaviov1.2https://gitlab.idiap.ch/bob/bob/-/issues/148Binding for color conversions in bob.ip2013-07-01T12:58:03ZAndré AnjosBinding for color conversions in bob.ip*Created by: siebenkopf*
Currently, we have color conversion functions bound to python, which are dependent on the data type. E.g. we have four different functions to convert RGB to Gray:
- rgb_to_gray(image, image)
- rgb_to_gray_f(fl...*Created by: siebenkopf*
Currently, we have color conversion functions bound to python, which are dependent on the data type. E.g. we have four different functions to convert RGB to Gray:
- rgb_to_gray(image, image)
- rgb_to_gray_f(float, float, float)
- rgb_to_gray_u8(int, int, int)
- rgb_to_gray_u16(int, int, int)
At least for the latter three functions I would rather consider a more pythonic way, like
- rgb_to_gray(float, float, float, dtype)
so that this function can be called with any data type. During binding, one could select the appropriate C++ implementation...
v1.2https://gitlab.idiap.ch/bob/bob/-/issues/149Simplification of exception raising/handling in Bob2013-07-08T08:16:10ZAndré AnjosSimplification of exception raising/handling in Bob*Created by: anjos*
The purpose of this issue is to keep track of work done in order to:
1. reduce the amount of custom exceptions which seem to serve no purpose
2. improve the readability of error messages, mainly from the python s...*Created by: anjos*
The purpose of this issue is to keep track of work done in order to:
1. reduce the amount of custom exceptions which seem to serve no purpose
2. improve the readability of error messages, mainly from the python side
The plan is to stop having custom exceptions for each little problem we have in the code and use `boost::format` in conjunction with `std::runtime_error` to throw customized exceptions every where.
Here is an example:
```c++
boost::format m("the value %f is not valid for parameter `foo'");
m % foo_value;
throw std::runtime_error(m.str());
```https://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...*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/151Making python bindings more consistent when using blitz arrays and std::vecto...2016-08-04T09:31:43ZAndré AnjosMaking python bindings more consistent when using blitz arrays and std::vector of blitz arrays*Created by: laurentes*
Our current python bindings that relies on C++ methods/functions that take blitz arrays as arguments are quite heterogeneous. Ideally, we should follow this way:
Given a class:
```c++
class Myclass {
publ...*Created by: laurentes*
Our current python bindings that relies on C++ methods/functions that take blitz arrays as arguments are quite heterogeneous. Ideally, we should follow this way:
Given a class:
```c++
class Myclass {
public:
void setW(const blitz::Array<double,1>& w) { m_w = w; }
const blitz::Array<double,1>& getW() { return m_w; }
private:
blitz::Array<double,1> m_w;
};
```
The python binding could be done as follows:
```c++
static void py_setW(bob::Myclass& m, bob::python::const_ndarray w) {
machine.setW(w.bz<double,1>());
}
class_<bob::Myclass, boost::shared_ptr<bob::Myclass> >("Myclass",
"This class implements ...", init<>())
.add_property("w", make_function(&bob::Myclass::getW, return_value_policy<copy_const_reference>()), &py_setW, "Paramaters for ...")
```
For the getter, this will make a copy of the array and cast it into a NumPy array.
For the setter, this allows various type (NumPy array, Python list) to be supported, and exceptions are managed by the bz<>() method.
For std::vector of blitz::Array's, the following could be done:
Given a class:
```c++
class Myclass {
public:
void setW(const std::vector<blitz::Array<double,1> >& w) { m_w = ... }
const std::vector<blitz::Array<double,1> >& getW() { return m_w; }
private:
std::vector<blitz::Array<double,1> > m_w;
};
```
The python binding could be done as follows:
```c++
static void py_setW(bob::Myclass& m, object w) {
stl_input_iterator<bob::python::const_ndarray> dbegin(w), dend;
std::vector<bob::python::const_ndarray> wdata(dbegin, dend);
std::vector<blitz::Array<double,1> > wb;
for(size_t i=0; i<wdata.size(); ++i)
wb.push_back(wdata[i].bz<double,1>());
machine.setW(wb);
}
static object py_getW(bob::Myclass& m) {
boost::python::list l;
const std::vector<double,1>& w = m.getW();
for(size_t i=0; i<w.size(); ++i)
l.append(w[i]);
return boost::python::tuple(l);
}
class_<bob::Myclass, boost::shared_ptr<bob::Myclass> >("Myclass",
"This class implements ...", init<>())
.add_property("w", &py_getW, &py_setW, "Paramaters for ...")
```
This way, the setter allows heterogeneous python type (NumPy array, python list) and the getters relies on the copy automagically done from blitz to NumPy.https://gitlab.idiap.ch/bob/bob/-/issues/152WhiteningTrainer documentation has to be improved2013-07-12T10:35:15ZAndré AnjosWhiteningTrainer documentation has to be improved*Created by: khoury*
The reference given doesn't correspond to the Cholesky Whitening we are doing. The formula given seems not totally correct.*Created by: khoury*
The reference given doesn't correspond to the Cholesky Whitening we are doing. The formula given seems not totally correct.https://gitlab.idiap.ch/bob/bob/-/issues/153No python tests for bob.ip.GaborWaveletTransform and related classes2015-08-18T16:19:09ZAndré AnjosNo python tests for bob.ip.GaborWaveletTransform and related classes*Created by: siebenkopf*
It seems that there are no python tests for the bob.ip.GaborWaveletTransform, bob.machine.GaborGraphMachine and bob.machine.GaborJetSimilarity. It would be nice to add some.*Created by: siebenkopf*
It seems that there are no python tests for the bob.ip.GaborWaveletTransform, bob.machine.GaborGraphMachine and bob.machine.GaborJetSimilarity. It would be nice to add some.v2.0https://gitlab.idiap.ch/bob/bob/-/issues/154bob.k and others are fun but unexpected2013-07-23T06:53:53ZAndré Anjosbob.k and others are fun but unexpected*Created by: khoury*
bob.k, bob.core.k, bob.core.random.k, bob.io.k, bob.ip.k, bob.sp.k, bob.measure.k and others are caused by the lines:
__all__ = [k for k in dir() if not k.startswith('_')]
This should likely be replaced by:
__all...*Created by: khoury*
bob.k, bob.core.k, bob.core.random.k, bob.io.k, bob.ip.k, bob.sp.k, bob.measure.k and others are caused by the lines:
__all__ = [k for k in dir() if not k.startswith('_')]
This should likely be replaced by:
__all__ = dir()https://gitlab.idiap.ch/bob/bob/-/issues/155visioner is not imported properly when compiled2016-08-04T09:31:48ZAndré Anjosvisioner is not imported properly when compiled*Created by: khoury*
When QT is available and the visioner is compiled, it is not imported by the python interpreter. This was likely caused by this [commit](https://github.com/idiap/bob/commit/ed341043a148393c9e6f1030151e3c9f4ff9e24d)....*Created by: khoury*
When QT is available and the visioner is compiled, it is not imported by the python interpreter. This was likely caused by this [commit](https://github.com/idiap/bob/commit/ed341043a148393c9e6f1030151e3c9f4ff9e24d). The inclusion might be done conditionally as before:
```python
try:
# the visioner is not built if Qt4 is not available
from . import visioner
has_visioner = True
except ImportError:
has_visioner = False
```https://gitlab.idiap.ch/bob/bob/-/issues/156Build should fail if pkg-config is not installed2019-04-19T22:41:24ZAndré AnjosBuild should fail if pkg-config is not installed*Created by: anjos*
The build should fail if CMake cannot find pkg-config:
```
-- Bob version '1.2.0' (macosx-x86_64-release)
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE
```*Created by: anjos*
The build should fail if CMake cannot find pkg-config:
```
-- Bob version '1.2.0' (macosx-x86_64-release)
-- Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE
```v2.0https://gitlab.idiap.ch/bob/bob/-/issues/157Python 3 support2016-08-04T09:31:51ZAndré AnjosPython 3 support*Created by: anjos*
Python 3 is already on version 3.4 (an alpha was just released). It is available on MacPorts. It is *already* the default python in ArchLinux. [It will be the default one in Ubuntu as of 14.04](https://wiki.ubuntu.co...*Created by: anjos*
Python 3 is already on version 3.4 (an alpha was just released). It is available on MacPorts. It is *already* the default python in ArchLinux. [It will be the default one in Ubuntu as of 14.04](https://wiki.ubuntu.com/Python/3) (that is April/2014).
We should slowly try to get the code compatible and ported. Unfortunately, Python 3 is not fully backward compatible with Python 2. So, let's keep in this bug report overall guidelines for porting the code. The idea is that, as much as possible, we try to keep the code in such a way that it is **valid in both Python 2 and Python 3**. In cases where that would not be possible, we may have to temporarily (until there is only Python 3) introduce `if` switches.
This work will start with Bob, but should soon propagate to the satellite packages. All help is welcome.
[Here is a quick guide of changes to get you started](http://docs.pythonsprints.com/python3_porting/py-porting.html).
I'll create an externals environment and post instructions for compiling against Python 3 at Idiap soon.v2.0https://gitlab.idiap.ch/bob/bob/-/issues/158The train() method of MAP_GMMTrainer segfaults when the prior is not set2016-08-04T09:31:53ZAndré AnjosThe train() method of MAP_GMMTrainer segfaults when the prior is not set*Created by: laurentes*
As reported on the mailing list, the train() method of the MAP_GMMTrainer causes a segmentation fault, when the prior GMM distribution is not set. There is a need to add a check, and to raises a runtime exception...*Created by: laurentes*
As reported on the mailing list, the train() method of the MAP_GMMTrainer causes a segmentation fault, when the prior GMM distribution is not set. There is a need to add a check, and to raises a runtime exception if this situation occurs.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)
```pyt...*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/160Build should fail if Blitz++ <0.10 is detected2016-08-04T09:31:58ZAndré AnjosBuild should fail if Blitz++ <0.10 is detected*Created by: anjos*
There seems to be on guard in case an older version of Blitz is installed at the system. This can be easily fixed by a pkg-config check.*Created by: anjos*
There seems to be on guard in case an older version of Blitz is installed at the system. This can be easily fixed by a pkg-config check.v2.0https://gitlab.idiap.ch/bob/bob/-/issues/161IP Scaling functionality far from optimal2019-07-16T14:50:50ZAndré AnjosIP Scaling functionality far from optimal*Created by: anjos*
The documentation and workflow of `bob.ip.scale` and `bob.ip.scale_as` as pretty bad as they currently stand.
1. If I read the doc of `scale_as`, I get the impression it will scale the input image, but actually it...*Created by: anjos*
The documentation and workflow of `bob.ip.scale` and `bob.ip.scale_as` as pretty bad as they currently stand.
1. If I read the doc of `scale_as`, I get the impression it will scale the input image, but actually it just generates a container for one.
2. The doc of `scale` does not precise the types of inputs it can handle, nor the type it outputs.
3. There is no easy handle to scale an image and return a freshly allocated container. I currently have to pass through `scale_as` to get a container and then be able to call `scale`.v2.0https://gitlab.idiap.ch/bob/bob.db.mnist/-/issues/2Package downloads M-NIST digit rec. DB at every iteration2017-10-19T14:04:35ZAndré AnjosPackage downloads M-NIST digit rec. DB at every iteration*Created by: anjos*
This package is downloading the M-NIST database from the respective URL (LeCun's site) at every iteration. The reason is that it has no way to know where it previously downloaded a copy (because it is using a tempora...*Created by: anjos*
This package is downloading the M-NIST database from the respective URL (LeCun's site) at every iteration. The reason is that it has no way to know where it previously downloaded a copy (because it is using a temporary directory to do so).
It would be more useful if the database was downloaded to a known directory.
I'd propose this database provided a "create" action that would allow it to be downloaded and installed within the package.https://gitlab.idiap.ch/bob/bob.db.voxforge/-/issues/1Use python script to download the data instead of ./download_and_untar.sh2017-10-22T18:34:52ZAndré AnjosUse python script to download the data instead of ./download_and_untar.sh*Created by: khoury*
It would be better to write a python script to download the data and untar.
This will make it compatible to Windows users.*Created by: khoury*
It would be better to write a python script to download the data and untar.
This will make it compatible to Windows users.https://gitlab.idiap.ch/bob/bob/-/issues/162ISVmachine can't save x2019-04-19T22:41:23ZAndré AnjosISVmachine can't save x*Created by: zongyuange*
while I have trained isv_machine and I use
file = bob.io.HDF5File(argv,'w');
isv_machine.save(file)
isv_machine.z is saved in a hdf5 file ,but isv_machine.x is gone forever. *Created by: zongyuange*
while I have trained isv_machine and I use
file = bob.io.HDF5File(argv,'w');
isv_machine.save(file)
isv_machine.z is saved in a hdf5 file ,but isv_machine.x is gone forever. https://gitlab.idiap.ch/bob/bob/-/issues/163ML_GMMTrainer and MAP_GMMTrainer documentation do not show defaults2019-07-16T14:50:50ZAndré AnjosML_GMMTrainer and MAP_GMMTrainer documentation do not show defaults*Created by: anjos*
This should be an easy fix on the bindings. Please make sure to correctly place the defaults for the input parameters there. As of today, these are not displayed:
http://www.idiap.ch/software/bob/docs/nightlies/la...*Created by: anjos*
This should be an easy fix on the bindings. Please make sure to correctly place the defaults for the input parameters there. As of today, these are not displayed:
http://www.idiap.ch/software/bob/docs/nightlies/last/bob/sphinx/html/trainer/generated/bob.trainer.ML_GMMTrainer.html?highlight=gmmtrainer#bob.trainer.ML_GMMTrainer
http://www.idiap.ch/software/bob/docs/nightlies/last/bob/sphinx/html/trainer/generated/bob.trainer.MAP_GMMTrainer.html?highlight=gmmtrainer#bob.trainer.MAP_GMMTrainer
Furthermore, it would be interesting to have somewhere the defaults for the inherited classes as well, such as, for example, the EMTrainer.max_iterations parameter. Finding the default (which is 10) can be a daunting quest for any person.v2.0