bob issueshttps://gitlab.idiap.ch/groups/bob/-/issues2016-08-04T09:29:58Zhttps://gitlab.idiap.ch/bob/bob/-/issues/98Syntax error in VideoWriter2.cc2016-08-04T09:29:58ZAndré AnjosSyntax error in VideoWriter2.cc*Created by: ozancaglayan*
In src/io/cxx/VideoWriter2.cc, line 127 lacks a terminating comma(,):
```
float framerate, float bitrate, size_t gop
```
should be
```
float framerate, float bitrate, size_t gop,
```*Created by: ozancaglayan*
In src/io/cxx/VideoWriter2.cc, line 127 lacks a terminating comma(,):
```
float framerate, float bitrate, size_t gop
```
should be
```
float framerate, float bitrate, size_t gop,
```https://gitlab.idiap.ch/bob/bob/-/issues/97BMP codec implementation has several limitations2016-08-04T09:29:56ZAndré AnjosBMP codec implementation has several limitations*Created by: laurentes*
In order to remove ImageMagick dependency, I had to introduce a BMP codec. Strangely, there are not that many open-source implementations, and I had finally decided to implement my own codec.
As BMP consists in ...*Created by: laurentes*
In order to remove ImageMagick dependency, I had to introduce a BMP codec. Strangely, there are not that many open-source implementations, and I had finally decided to implement my own codec.
As BMP consists in a set of multiple formats/headers, this implementation does not support all types of BMP images. In particular, there are the following limitations:
- Only OS2 v1 (14 bytes DIB header) and Windows v1/4/5 (40/108/124 bytes DIB header) DIB headers are supported
- Only non-compressed BMP images are supported
Looking at the BMP samples here: http://vaxa.wvnet.edu/vmswww/bmp.html, this implies that the following images can not be read:
- "The image below is a 4 bit compressed BMP. "
- "The image below is a 8 bit compressed BMP. "
- "The image below is a 4 bit OS/2 version 2 BMP. "
- ~~"The image below is a 32 bit 888 bitfield version 4 BMP. "~~
- ~~"The image below is a 32 bit version 5 BMP. "~~
- ~~"The image below is a 32 bit transparent version 4 BMP. "~~
The remaining ones should be read with success.https://gitlab.idiap.ch/bob/bob/-/issues/96Problem in writing to HDF5 file using set() with compression>02016-08-04T09:29:54ZAndré AnjosProblem in writing to HDF5 file using set() with compression>0*Created by: nerdogmus*
The following code works just fine:
file_hdf5 = bob.io.HDF5File('myFile.hdf5', 'w')
file_hdf5.set('data',numpy.zeros(5),compression=0)
del file_hdf5
whereas setting the compression to a value higher than 0, giv...*Created by: nerdogmus*
The following code works just fine:
file_hdf5 = bob.io.HDF5File('myFile.hdf5', 'w')
file_hdf5.set('data',numpy.zeros(5),compression=0)
del file_hdf5
whereas setting the compression to a value higher than 0, gives the following error:
Call to HDF5 C-function 'H5Dcreate2' returned '-1'. HDF5 error statck follows:
H5Dcreate2() @ H5D.c+170: unable to create dataset
H5D__create_named() @ H5Dint.c+430: unable to create and link to dataset
H5L_link_object() @ H5L.c+1638: unable to create new link to object
H5L_create_real() @ H5L.c+1882: can't insert link
H5G_traverse() @ H5Gtraverse.c+861: internal path traversal failed
H5G_traverse_real() @ H5Gtraverse.c+641: traversal operator failed
H5L_link_cb() @ H5L.c+1685: unable to create object
H5O_obj_create() @ H5O.c+3015: unable to open object
H5O_dset_create() @ H5Doh.c+298: unable to create dataset
H5D_create() @ H5Dint.c+991: filters can only be used with chunked layout
On the other hand, using 'append' creates no such problems:
file_hdf5 = bob.io.HDF5File('myFile.hdf5', 'a')
file_hdf5.append('data',numpy.zeros(5),compression=5)
del file_hdf5
https://gitlab.idiap.ch/bob/bob/-/issues/95problem with visualizing .pgm files written by bob2016-08-04T09:29:52ZAndré Anjosproblem with visualizing .pgm files written by bob*Created by: ivana7c*
The format of the .pgm files written by bob are not supported by some applications like GNOME image viewer or Gimp etc. However, it is possible to correctly read them back using bob. The difference between an .pgm ...*Created by: ivana7c*
The format of the .pgm files written by bob are not supported by some applications like GNOME image viewer or Gimp etc. However, it is possible to correctly read them back using bob. The difference between an .pgm image written with bob and other .pgm image is in the header (P7 for bob, P5 for other image).
Here is how to reproduce the error:
import bob
import numpy
img=numpy.random.randint(0,255,size=(100,100)).astype(numpy.uint8)
bob.io.save(img, 'test.pgm')
https://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.db.atnt/-/issues/1Broken links in PyPI2018-09-23T22:29:59ZAndré AnjosBroken links in PyPI*Created by: tiagofrepereira2012*
There are two broken links in the PyPI web page.
The first one links to (https://github.com/bioidiap/xbob.db.nuaa)
The second one, in the "Home Page" sub item links to (https://github.com/bioidiap...*Created by: tiagofrepereira2012*
There are two broken links in the PyPI web page.
The first one links to (https://github.com/bioidiap/xbob.db.nuaa)
The second one, in the "Home Page" sub item links to (https://github.com/bioidiap/bob.db.nuaa)https://gitlab.idiap.ch/bob/bob/-/issues/93ImageMagick shipped with Ubuntu 12.10 Quantal (alpha) causes crashes2016-08-04T09:29:47ZAndré AnjosImageMagick shipped with Ubuntu 12.10 Quantal (alpha) causes crashes*Created by: laurentes*
Running the testsuite on the upcoming Ubuntu distribution, we have noticed two problems with the following tests:
```sh
user@ubuntu64--12-04:~/bob/builddebug$ ./bin/nosetests -x bob.io.test.test_examples -v
...*Created by: laurentes*
Running the testsuite on the upcoming Ubuntu distribution, we have noticed two problems with the following tests:
```sh
user@ubuntu64--12-04:~/bob/builddebug$ ./bin/nosetests -x bob.io.test.test_examples -v
test01_video2frame (bob.io.test.test_examples.ExampleTest) ... python2.7: magick/cache-view.c:477: GetCacheViewAuthenticPixels: Assertion `id < (int) cache_view->number_threads' failed.
Aborted (core dumped)
```
```sh
user@ubuntu64--12-04:~/bob/builddebug$ ./bin/nosetests -x bob.visioner.test.test_scripts -v
test01_face_detect (bob.visioner.test.test_scripts.VisionerScriptTest) ... ok
test02_face_detect (bob.visioner.test.test_scripts.VisionerScriptTest) ... python2.7: magick/cache-view.c:477: GetCacheViewAuthenticPixels: Assertion `id < (int) cache_view->number_threads' failed.
Aborted (core dumped)
```
This seems to be related to an ImageMagick [bug](http://www.imagemagick.org/discourse-server/viewtopic.php?f=23&t=21741) on version 6.7.7.*, which is (unfortunately) the version (6.7.7.10-2) that will be shipped with Ubuntu Quantal. However this has been fixed in [commit](http://trac.imagemagick.org/changeset?reponame=&new=8762%40ImageMagick%2Ftrunk%2FMagickCore%2Fcache-view.c&old=8759%40ImageMagick%2Ftrunk%2FMagickCore%2Fcache-view.c) and integrated in current releaases of ImageMagick.
This is related to multithreading. We need to investigate further and see if we can find a workaround.https://gitlab.idiap.ch/bob/bob/-/issues/91ImageMagick and PNM image support2016-08-04T09:29:44ZAndré AnjosImageMagick and PNM image support*Created by: laurentes*
We are constantly facing problems across [ImageMagick](http://www.imagemagick.org/) versions shipped with various Ubuntu distributions. In particular, we were not able to find a good way to deal with the portable...*Created by: laurentes*
We are constantly facing problems across [ImageMagick](http://www.imagemagick.org/) versions shipped with various Ubuntu distributions. In particular, we were not able to find a good way to deal with the portable anymap format (PNM) image formats (pbm, pgm and ppm), because [ImageMagick](http://www.imagemagick.org/) behaviour is version dependent.
Furthermore, we are planning to rely on the (hopefully) more stable library [libnetpbm](http://netpbm.sourceforge.net/) to deal with these image formats.
As we have recently noticed behavior changes with the jpeg codec, we are also considering to get rid of the Imagemagick dependency for the IO codecs, in favor of more specific image libraries (such as libpng and libjpeg).https://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/87KMeansTrainer python overloading is buggy2016-08-04T09:29:38ZAndré AnjosKMeansTrainer python overloading is buggy*Created by: laurentes*
There is a bug when overloading C++ methods of the KMeansTrainer from python. This might also affect the GMMTrainer.
The following program higlights the problem.
```python
#!/usr/bin/env python
import b...*Created by: laurentes*
There is a bug when overloading C++ methods of the KMeansTrainer from python. This might also affect the GMMTrainer.
The following program higlights the problem.
```python
#!/usr/bin/env python
import bob, numpy
import logging
logger = logging.getLogger("bob.c++")
logger.setLevel(logging.DEBUG)
machine = bob.machine.KMeansMachine(2,1)
data = numpy.array([[-3],[-2],[-1],[0.],[1.],[2.],[3.]])
print data.shape
class MyKMeansTrainer(bob.trainer.overload.KMeansTrainer):
"""Simple example of python trainer: """
def __init__(self):
bob.trainer.overload.KMeansTrainer.__init__(self)
def initialization(self, machine, data):
bob.trainer.overload.KMeansTrainer.initialization(self, machine, data)
machine.means = numpy.array([[-0.5], [ 0.5]])
print machine.means
trainer = MyKMeansTrainer()
trainer.convergence_threshold = 0.0005
max_iterations = 1 # Just do one iteration of the E-step and M-step
trainer.max_iterations = max_iterations;
# This does not work as expected
trainer.train(machine, data)
# After the call of initialization() the means are still [0.,0.] (at the C++ level, whereas the values printed from python are correct)
# This means that the E-step is started with two identical means, and leads
# to unexpected NaN values.
print machine.means
# This works as expected
trainer.initialization(machine, data)
print machine.means
trainer.e_step(machine, data)
trainer.m_step(machine, data)
print machine.means
~
```
After some debugging, it seems that in the first case, the addresses of the KMeansMachine's respectively passed as arguments to the initialization() and e_step() methods differ. In contrast, using the second approach, they are the same, which is the expected behavior. I'm wondering if this is not due to the fact that we are passing non-const references of KMeansMachine back and forth from python to C++.
It would be nice to fix this issue for the next release 1.1, or otherwise, to disable this feature.https://gitlab.idiap.ch/bob/bob.db.casia_fasd/-/issues/1Problem with the cross_valid_foldobjects method2017-10-24T05:59:01ZAndré AnjosProblem with the cross_valid_foldobjects method*Created by: tiagofrepereira2012*
There is a problem when you try to fetch the data using the method cross_valid_foldobjects with the argument types=None (the default value provided). The line above makes the script stop. This method on...*Created by: tiagofrepereira2012*
There is a problem when you try to fetch the data using the method cross_valid_foldobjects with the argument types=None (the default value provided). The line above makes the script stop. This method only accepts a tuple in the "type" argument.
import xbob.db.casia_fasd
db = xbob.db.casia_fasd.Database()
a,b = db.cross_valid_foldobjects(cls='attack', types=None, fold_no=1)
This method should work similar to the method "objects"m which accepts None in the "types" argument.
https://gitlab.idiap.ch/bob/bob.db.arface/-/issues/1Probe samples may vary for a given protocol2018-07-10T19:03:32ZAndré AnjosProbe samples may vary for a given protocol*Created by: laurentes*
As previously discussed, I'm currently refactoring this database, making a better usage of the classes from models.py.
There are currently 5 protocols:
- 'all'
- 'expression'
- 'illumination'
- 'occlusion'...*Created by: laurentes*
As previously discussed, I'm currently refactoring this database, making a better usage of the classes from models.py.
There are currently 5 protocols:
- 'all'
- 'expression'
- 'illumination'
- 'occlusion'
- 'occlusion_and_illumination'
However, it seems that depending on the parameters 'sessions', 'expressions', 'illuminations', 'occlusions', 'genders', the list of probe files will change (and the one of training files as well which is fine).
To my mind, this is a bad idea. We should define more specific protocols, for which enrollment and probe lists are fixed, whatever the parameters are.
I propose to make these parameters world related. In this case, we would need to define more protocols to keep similar features. Which ones would you like?
The second question is what should be the default world data for each protocol.https://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.db.xm2vts/-/issues/1Data organization2018-06-05T07:53:07ZAndré AnjosData organization*Created by: laurentes*
There are two distinct problems:
1. The current API only allows the user to deal with still images of the database.
2. The current API assumes that the data of the database is stored in subdirectories, one for ea...*Created by: laurentes*
There are two distinct problems:
1. The current API only allows the user to deal with still images of the database.
2. The current API assumes that the data of the database is stored in subdirectories, one for each identity. It would be better to organize data in the same way as it is currently shipped when you order the database.
To solve both problems, this would require me to have the original CDs/DVDs of the database or at least to know the directory structure and the files contained in each subdirectory. Unfortunately, this is not the case, as the data we have at Idiap have very likely been reorganized over the years.
Could anyone provides me the file hierarchy for both image and/or audio data, in order to fix this issue?
Thanks in advance.
https://gitlab.idiap.ch/bob/bob.db.banca/-/issues/1Data organization2020-04-24T07:38:35ZAndré AnjosData organization*Created by: laurentes*
There are two distinct problems:
1. The current API only allows the user to deal with still images of the English part.
2. The current API assumes that the data of the BANCA database is stored in a single directo...*Created by: laurentes*
There are two distinct problems:
1. The current API only allows the user to deal with still images of the English part.
2. The current API assumes that the data of the BANCA database is stored in a single directory. It would be better to organize data in subdirectories, in the same way as it is currently shipped.
To solve both problems, this would require me to have the original CDs/DVDs of the database or at least to know the directory structure and the files contained in each subdirectory. Unfortunately, this is not the case, as the data we have at Idiap have very likely been reorganized over the years.
Wrt. still images, the data shipped might be organized into the following directories:
en_video_sc1_1/
en_video_sc1_2/
en_video_sc1_3/
en_video_sc1_4/
en_video_sc2_1/
en_video_sc2_2/
en_video_sc2_3/
en_video_sc2_4/
en_video_sc3_1/
en_video_sc3_2/
en_video_sc3_3/
en_video_sc3_4/
en_video_wm_sc1/
en_video_wm_sc2/
en_video_wm_sc3/
Could anyone provides me the file hierarchy for both image and/or audio data, in order to fix this issue?
Thanks in advance.https://gitlab.idiap.ch/bob/bob/-/issues/85Information messages during time-requiring training procedures2016-08-04T09:29:32ZAndré AnjosInformation messages during time-requiring training procedures*Created by: laurentes*
The stream bob::core::info was previously used to display information messages during iterative time-requiring training procedures, such as in the EMTrainer. Since recent changes occur in the way bob deals with I...*Created by: laurentes*
The stream bob::core::info was previously used to display information messages during iterative time-requiring training procedures, such as in the EMTrainer. Since recent changes occur in the way bob deals with I/O streams, these messages are not displayed anymore (at least through the python interpreter).
It would be nice to design guidelines for these kinds of procedures, explaining the way we should print such messages or at least providing the user an option to display them. We clearly lack of consistency accross the training submodule.https://gitlab.idiap.ch/bob/bob/-/issues/84GradientMaps orientation is wrong (This affects HOG descriptors)2012-09-18T10:17:13ZAndré AnjosGradientMaps orientation is wrong (This affects HOG descriptors)*Created by: laurentes*
There is a bug when computing the orientation maps using the bob::ip::GradientMaps class.
This currently affects the computation of HOG descriptors.
This was originally caused by a mistake in the blitz++ docume...*Created by: laurentes*
There is a bug when computing the orientation maps using the bob::ip::GradientMaps class.
This currently affects the computation of HOG descriptors.
This was originally caused by a mistake in the blitz++ documentation available at late www.oonumerics.org. A copy of this documentation can be found here, with the mistake: http://www-cecpv.u-strasbg.fr/Documentations/blitz/blitz_3.html#SEC89. The signature of the blitz::atan2 reduction is indeed wrong. The correct version is blitz::atan2(y,x) instead of the blitz::atan2(x,y). The fixed version is consistent with the signature of the standard function atan2(y,x) (http://www.cplusplus.com/reference/std/valarray/atan2/).v1.1https://gitlab.idiap.ch/bob/bob/-/issues/83bob.daq.test.test_all.DaqTest with synchronization problems?2016-08-04T09:29:29ZAndré Anjosbob.daq.test.test_all.DaqTest with synchronization problems?*Created by: anjos*
The test unit "test_VideoReaderCamera" will fail with a segmentation fault if the following conditions are met:
1. Compile in *Debug* mode
2. Change `lib/python2.6/site-packages/bob/core/__init__.py` so that:
``...*Created by: anjos*
The test unit "test_VideoReaderCamera" will fail with a segmentation fault if the following conditions are met:
1. Compile in *Debug* mode
2. Change `lib/python2.6/site-packages/bob/core/__init__.py` so that:
```python
#cxx_logger.setLevel(logging.WARNING)
```
Is commented out as indicated. Notice this is a temporary change. If you run `make` again, it will be gone. If you wish to have a less temporary modification, change `<src>/python/bob/core/__init__.py` instead and re-run cmake. In this case, *remember to not commit* this modification.
3. Run the specific test that triggers the segmentation fault:
```sh
$ ./bin/nosetests -v bob.daq
This bug is not 100% reproducible. Sometimes the program may work. Specially if the messaging service is not used (or if you set the logging level to a different value that is less verbose than `logging.INFO`). I could reproduce this problem in different platforms, so I think it is platform independent.
You should see something like:
```
test_VideoReaderCamera (bob.daq.test.test_all.DaqTest) ... bob.c++@2012-09-18 11:02:51,518|INFO: Frame 0 received (0 sec) not recording
bob.c++@2012-09-18 11:02:51,579|INFO: Frame 1 received (0.04 sec) not recording
bob.c++@2012-09-18 11:02:51,613|INFO: Frame 2 received (0.08 sec) not recording
bob.c++@2012-09-18 11:02:51,646|INFO: Frame 3 received (0.12 sec) not recording
bob.c++@2012-09-18 11:02:51,679|INFO: Frame 4 received (0.16 sec) not recording
bob.c++@2012-09-18 11:02:51,713|INFO: Frame 5 received (0.2 sec) not recording
bob.c++@2012-09-18 11:02:51,746|INFO: Frame 6 received (0.24 sec) not recording
bob.c++@2012-09-18 11:02:51,779|INFO: Frame 7 received (0.28 sec) not recording
bob.c++@2012-09-18 11:02:51,812|INFO: Frame 8 received (0.32 sec) not recording
bob.c++@2012-09-18 11:02:51,825|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:51,884|INFO: Frame 9 received (0.36 sec) not recording
bob.c++@2012-09-18 11:02:51,918|INFO: Frame 10 received (0.4 sec) not recording
bob.c++@2012-09-18 11:02:51,952|INFO: Frame 11 received (0.44 sec) not recording
bob.c++@2012-09-18 11:02:51,986|INFO: Frame 12 received (0.48 sec) not recording
bob.c++@2012-09-18 11:02:52,020|INFO: Frame 13 received (0.52 sec) not recording
bob.c++@2012-09-18 11:02:52,062|INFO: Frame 14 received (0.56 sec) not recording
bob.c++@2012-09-18 11:02:52,097|INFO: Frame 15 received (0.6 sec) not recording
bob.c++@2012-09-18 11:02:52,131|INFO: Frame 16 received (0.64 sec) not recording
bob.c++@2012-09-18 11:02:52,134|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:52,194|INFO: Frame 17 received (0.68 sec) not recording
bob.c++@2012-09-18 11:02:52,229|INFO: Frame 18 received (0.72 sec) not recording
bob.c++@2012-09-18 11:02:52,263|INFO: Frame 19 received (0.76 sec) not recording
bob.c++@2012-09-18 11:02:52,297|INFO: Frame 20 received (0.8 sec) not recording
bob.c++@2012-09-18 11:02:52,332|INFO: Frame 21 received (0.84 sec) not recording
bob.c++@2012-09-18 11:02:52,367|INFO: Frame 22 received (0.88 sec) not recording
bob.c++@2012-09-18 11:02:52,401|INFO: Frame 23 received (0.92 sec) not recording
bob.c++@2012-09-18 11:02:52,435|INFO: Frame 24 received (0.96 sec) not recording
bob.c++@2012-09-18 11:02:52,447|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:52,508|INFO: Frame 25 received (1 sec) not recording
bob.c++@2012-09-18 11:02:52,567|INFO: Frame 26 received (1.04 sec) recording
bob.c++@2012-09-18 11:02:52,628|INFO: Frame 27 received (1.08 sec) recording
bob.c++@2012-09-18 11:02:52,689|INFO: Frame 28 received (1.12 sec) recording
bob.c++@2012-09-18 11:02:52,749|INFO: Frame 29 received (1.16 sec) recording
bob.c++@2012-09-18 11:02:52,757|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:52,816|INFO: Frame 30 received (1.2 sec) recording
bob.c++@2012-09-18 11:02:52,877|INFO: Frame 31 received (1.24 sec) recording
bob.c++@2012-09-18 11:02:52,938|INFO: Frame 32 received (1.28 sec) recording
bob.c++@2012-09-18 11:02:52,997|INFO: Frame 33 received (1.32 sec) recording
bob.c++@2012-09-18 11:02:53,059|INFO: Frame 34 received (1.36 sec) recording
bob.c++@2012-09-18 11:02:53,069|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:53,129|INFO: Frame 35 received (1.4 sec) recording
bob.c++@2012-09-18 11:02:53,190|INFO: Frame 36 received (1.44 sec) recording
bob.c++@2012-09-18 11:02:53,251|INFO: Frame 37 received (1.48 sec) recording
bob.c++@2012-09-18 11:02:53,310|INFO: Frame 38 received (1.52 sec) recording
bob.c++@2012-09-18 11:02:53,371|INFO: Frame 39 received (1.56 sec) recording
bob.c++@2012-09-18 11:02:53,374|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:53,436|INFO: Frame 40 received (1.6 sec) recording
bob.c++@2012-09-18 11:02:53,497|INFO: Frame 41 received (1.64 sec) recording
bob.c++@2012-09-18 11:02:53,558|INFO: Frame 42 received (1.68 sec) recording
bob.c++@2012-09-18 11:02:53,619|INFO: Frame 43 received (1.72 sec) recording
bob.c++@2012-09-18 11:02:53,679|INFO: Frame 44 received (1.76 sec) recording
bob.c++@2012-09-18 11:02:53,694|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:53,755|INFO: Frame 45 received (1.8 sec) recording
bob.c++@2012-09-18 11:02:53,815|INFO: Frame 46 received (1.84 sec) recording
bob.c++@2012-09-18 11:02:53,875|INFO: Frame 47 received (1.88 sec) recording
bob.c++@2012-09-18 11:02:53,936|INFO: Frame 48 received (1.92 sec) recording
bob.c++@2012-09-18 11:02:53,997|INFO: Frame 49 received (1.96 sec) recording
bob.c++@2012-09-18 11:02:54,002|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:54,062|INFO: Frame 50 received (2 sec) recording
bob.c++@2012-09-18 11:02:54,122|INFO: Frame 51 received (2.04 sec) recording
bob.c++@2012-09-18 11:02:54,183|INFO: Frame 52 received (2.08 sec) recording
bob.c++@2012-09-18 11:02:54,242|INFO: Frame 53 received (2.12 sec) recording
bob.c++@2012-09-18 11:02:54,303|INFO: Frame 54 received (2.16 sec) recording
bob.c++@2012-09-18 11:02:54,308|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:54,369|INFO: Frame 55 received (2.2 sec) recording
bob.c++@2012-09-18 11:02:54,429|INFO: Frame 56 received (2.24 sec) recording
bob.c++@2012-09-18 11:02:54,489|INFO: Frame 57 received (2.28 sec) recording
bob.c++@2012-09-18 11:02:54,550|INFO: Frame 58 received (2.32 sec) recording
bob.c++@2012-09-18 11:02:54,608|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:54,611|INFO: Frame 59 received (2.36 sec) recording
bob.c++@2012-09-18 11:02:54,670|INFO: Frame 60 received (2.4 sec) recording
bob.c++@2012-09-18 11:02:54,731|INFO: Frame 61 received (2.44 sec) recording
bob.c++@2012-09-18 11:02:54,790|INFO: Frame 62 received (2.48 sec) recording
bob.c++@2012-09-18 11:02:54,851|INFO: Frame 63 received (2.52 sec) recording
bob.c++@2012-09-18 11:02:54,902|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:54,963|INFO: Frame 64 received (2.56 sec) recording
bob.c++@2012-09-18 11:02:55,022|INFO: Frame 65 received (2.6 sec) recording
bob.c++@2012-09-18 11:02:55,083|INFO: Frame 66 received (2.64 sec) recording
bob.c++@2012-09-18 11:02:55,145|INFO: Frame 67 received (2.68 sec) recording
bob.c++@2012-09-18 11:02:55,194|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:55,255|INFO: Frame 68 received (2.72 sec) recording
bob.c++@2012-09-18 11:02:55,315|INFO: Frame 69 received (2.76 sec) recording
bob.c++@2012-09-18 11:02:55,377|INFO: Frame 70 received (2.8 sec) recording
bob.c++@2012-09-18 11:02:55,437|INFO: Frame 71 received (2.84 sec) recording
bob.c++@2012-09-18 11:02:55,492|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:55,553|INFO: Frame 72 received (2.88 sec) recording
bob.c++@2012-09-18 11:02:55,613|INFO: Frame 73 received (2.92 sec) recording
bob.c++@2012-09-18 11:02:55,673|INFO: Frame 74 received (2.96 sec) recording
bob.c++@2012-09-18 11:02:55,731|INFO: Frame 75 received (3 sec) recording
bob.c++@2012-09-18 11:02:55,788|INFO: Face detect result: detected
bob.c++@2012-09-18 11:02:55,791|INFO: Frame 76 received (3.04 sec) recording
bob.c++@2012-09-18 11:02:55,850|INFO: Frame 77 received (3.08 sec) recording
bob.c++@2012-09-18 11:02:55,910|INFO: Frame 78 received (3.12 sec) recording
bob.c++@2012-09-18 11:02:55,970|INFO: Frame 79 received (3.16 sec) recording
bob.c++@2012-09-18 11:02:56,028|INFO: Frame 80 received (3.2 sec) recording
bob.c++@2012-09-18 11:02:56,093|INFO: Frame 81 received (3.24 sec) recording
Segmentation fault (core dumped)
```https://gitlab.idiap.ch/bob/bob/-/issues/82No Windows port2019-06-24T13:44:12ZAndré AnjosNo Windows port*Created by: anjos*
Currently, we have no Windows port of Bob. This is a major problem as most researchers still use Windows. Let's put here information on how to create one and close this once a port is available.
Current status:
> T...*Created by: anjos*
Currently, we have no Windows port of Bob. This is a major problem as most researchers still use Windows. Let's put here information on how to create one and close this once a port is available.
Current status:
> The most promising solution for a *quicker* porting is to use [cygwin](http://www.cygwin.com/).v2.0