bob issueshttps://gitlab.idiap.ch/groups/bob/-/issues2017-08-07T13:07:35Zhttps://gitlab.idiap.ch/bob/bob.bio.base/-/issues/69bob.io.image is a test dependency but it is imported (and not used) in bob/b...2017-08-07T13:07:35ZAmir MOHAMMADIbob.io.image is a test dependency but it is imported (and not used) in bob/bio/base/script/preprocess.pyMay 2017 HackathonAmir MOHAMMADIAmir MOHAMMADIhttps://gitlab.idiap.ch/bob/bob.bio.base/-/issues/68ROC, and CMC curves do not follow the standard of the Handbook of Face Recogn...2017-08-07T13:07:35ZManuel Günthersiebenkopf@googlemail.comROC, and CMC curves do not follow the standard of the Handbook of Face RecognitionIn the above mentioned book, the axis are given between `min_far` and 1, while we plot in percentages.
Also, there is no way to provide a lowest FAR value other than `0.01%` (or `1e-4` without percentages) for plotting ROC curves.
For ...In the above mentioned book, the axis are given between `min_far` and 1, while we plot in percentages.
Also, there is no way to provide a lowest FAR value other than `0.01%` (or `1e-4` without percentages) for plotting ROC curves.
For the DET and EPC curves, we also use percentages. However, these plots are not given in the Handbook, so we can use them freely. I would suggest to remove the percentages there, too, just to be consistent.Manuel Günthersiebenkopf@googlemail.comManuel Günthersiebenkopf@googlemail.comhttps://gitlab.idiap.ch/bob/bob.bio.base/-/issues/64Base classes are not new-style classes2017-08-07T13:07:35ZManuel Günthersiebenkopf@googlemail.comBase classes are not new-style classesThe base classes for the Preprocessor, Extractor and Algorithm are not new-style classes (i.e., the do not derive from `object`). Hence, calling `super` does not work with them:, it generates the same error message as here: http://stacko...The base classes for the Preprocessor, Extractor and Algorithm are not new-style classes (i.e., the do not derive from `object`). Hence, calling `super` does not work with them:, it generates the same error message as here: http://stackoverflow.com/questions/1713038/super-fails-with-error-typeerror-argument-1-must-be-type-not-classobj
Also, calling of base class functions (including constructors) do not use `super` yet.
* [x] base classes derive from object
* [x] derived classes use `super`Manuel Günthersiebenkopf@googlemail.comManuel Günthersiebenkopf@googlemail.comhttps://gitlab.idiap.ch/bob/bob.bio.base/-/issues/63New release2017-08-07T13:07:35ZTiago de Freitas PereiraNew releaseHey guys, we need to release this stack of software.
Shall we?? Any objections?
ThanksHey guys, we need to release this stack of software.
Shall we?? Any objections?
ThanksSébastien MARCELSébastien MARCELhttps://gitlab.idiap.ch/bob/bob.bio.base/-/issues/62preprocessing, extraction and projection will not stop if files are missing2017-08-07T13:07:35ZManuel Günthersiebenkopf@googlemail.compreprocessing, extraction and projection will not stop if files are missingWhen there is an issue preprocessing the file or extracting/projecting features and the tool returns `None`, a message is written, but the file is silently skipped. This should be the default behavior when the `--allow-missing-files` fla...When there is an issue preprocessing the file or extracting/projecting features and the tool returns `None`, a message is written, but the file is silently skipped. This should be the default behavior when the `--allow-missing-files` flag is set. However, even without the flag, currently the processing just emits an error message, but continues. This is especially annoying when running in the grid and, thus, getting the error messages written into log files instead of to console.
The problem is that the `continue`: https://gitlab.idiap.ch/bob/bob.bio.base/blob/master/bob/bio/base/tools/extractor.py#L129 is not what we want.
I think, when the processing fails and `None` is returned, we should raise an exception rather than skipping.https://gitlab.idiap.ch/bob/bob.bio.base/-/issues/61FAIL: bob.bio.base.test.test_algorithms.test_plda2017-08-07T13:07:35ZAmir MOHAMMADIFAIL: bob.bio.base.test.test_algorithms.test_plda```
======================================================================
FAIL: bob.bio.base.test.test_algorithms.test_plda
----------------------------------------------------------------------
Traceback (most recent call last):
File...```
======================================================================
FAIL: bob.bio.base.test.test_algorithms.test_plda
----------------------------------------------------------------------
Traceback (most recent call last):
File "/home/gitlab-runner/builds/0d638152/2/bob/bob.bio.base/build-prefix/lib/python2.7/site-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
File "/home/gitlab-runner/builds/0d638152/2/bob/bob.bio.base/build-prefix/lib/python2.7/site-packages/bob/bio/base/test/test_algorithms.py", line 340, in test_plda
assert plda1.plda_base.is_similar_to(plda3.plda_base)
AssertionError:
-------------------- >> begin captured logging << --------------------
bob.bio.base: INFO: -> Training LinearMachine using PCA
bob.bio.base: INFO: -> limiting PCA subspace to 10 dimensions
bob.bio.base: INFO: -> Training PLDA base machine
bob.learn.em: INFO: Iteration = 0/1
--------------------- >> end captured logging << ---------------------
----------------------------------------------------------------------
```
@tiago.pereira could this because of our changes in bob.math? related to https://gitlab.idiap.ch/bob/bob.math/issues/10Tiago de Freitas PereiraTiago de Freitas Pereirahttps://gitlab.idiap.ch/bob/bob.bio.base/-/issues/59strange behaviour when retrieving objects from bob.bio.base filelist database...2017-08-07T13:07:35ZGuillaume HEUSCHstrange behaviour when retrieving objects from bob.bio.base filelist database queryHi Guys,
In the objects method of query.py (bob.bio.database.filelist), I encountered something really strange when performing nosetests. As far as I can tell, there is a problem when the method is called two times with the same group...Hi Guys,
In the objects method of query.py (bob.bio.database.filelist), I encountered something really strange when performing nosetests. As far as I can tell, there is a problem when the method is called two times with the same groups and purposes arguments, but with a different protocol:
```python
assert len(db.objects(protocol='public_MC_NIR', groups='dev', purposes='probe')) == 500
assert len(db.objects(protocol='public_UD_NIR', groups='dev', purposes='probe')) == 1000
```
Running this, I get a value of 500 for both tests ... which corresponds to the value expected in the first test. And if I just change the order of the lines, I get a value of 1000 for both tests.
So, my guess is that something is not re-initialized properly (but I was not able to find it yet) ...Manuel Günthersiebenkopf@googlemail.comManuel Günthersiebenkopf@googlemail.comhttps://gitlab.idiap.ch/bob/bob.bio.base/-/issues/57Little typo in bob.bio.base.utils2017-08-07T13:07:35ZChristopher FINELLILittle typo in bob.bio.base.utilsIn the "__init__.py" file, there is a typo in the method "score_fusion_strategy" on the default value of the parameter "strategy_name": should be "average" instead of "avarage".
This could cause some unexpected exceptions if the paramete...In the "__init__.py" file, there is a typo in the method "score_fusion_strategy" on the default value of the parameter "strategy_name": should be "average" instead of "avarage".
This could cause some unexpected exceptions if the parameter is not specified when the method is called.https://gitlab.idiap.ch/bob/bob.bio.base/-/issues/56It is not possible to use PLDA in the current execution chain2017-08-07T13:07:35ZTiago de Freitas PereiraIt is not possible to use PLDA in the current execution chainIf I use PLDA on top of simple features (let's say LBP histograms) I got the following exception.
```
input_dimension = training_features[0].shape[1]
AttributeError: 'list' object has no attribute 'shape'
```
The execution chain provi...If I use PLDA on top of simple features (let's say LBP histograms) I got the following exception.
```
input_dimension = training_features[0].shape[1]
AttributeError: 'list' object has no attribute 'shape'
```
The execution chain provides to `bob.bio.base.algorithm.PLDA.train_enroller` the data organized by client (which is correct) in the following format:
```
[ [numpy.array],[numpy.array],[numpy.array]], # client1
[ [numpy.array],[numpy.array],[numpy.array] ], # client2
....
[ [numpy.array],[numpy.array],[numpy.array] ], # client n
```
The train_enroller **MUST** stack the features per client (like LDA does in https://gitlab.idiap.ch/bob/bob.bio.base/blob/master/bob/bio/base/algorithm/LDA.py#L151), but this is not being done.
I will implement something similar to the procedures implemented in the LDA.Tiago de Freitas PereiraTiago de Freitas Pereirahttps://gitlab.idiap.ch/bob/bob.bio.base/-/issues/81Config variables which are not lower case are reported2017-08-07T13:07:34ZAndré AnjosConfig variables which are not lower case are reportedIt seems uncoventional to me that any variable in lower case that is not a valid option issues a warning when scanning config files. Python has a standard for "visibility": if a variable starts with `_` (underscore), then it is considere...It seems uncoventional to me that any variable in lower case that is not a valid option issues a warning when scanning config files. Python has a standard for "visibility": if a variable starts with `_` (underscore), then it is considered private. I wonder if we should not "respect" this here instead of pushing for an upper-case standard.André AnjosAndré Anjoshttps://gitlab.idiap.ch/bob/bob/-/issues/238Moving the documentation to readthedocs and making it more simple2017-08-07T12:16:54ZAmir MOHAMMADIMoving the documentation to readthedocs and making it more simpleRight now, this package's documentation is very hard to handle. It copies all core bob packages and builds all of them.
Readthedocs supports the concept of sub-projects and you can search within them as well:
https://docs.readthedocs.i...Right now, this package's documentation is very hard to handle. It copies all core bob packages and builds all of them.
Readthedocs supports the concept of sub-projects and you can search within them as well:
https://docs.readthedocs.io/en/latest/faq.html#how-do-i-host-multiple-projects-on-one-cname
So I imagine if we move to readthedocs, we can simplify the dos of this package and include it in the nightlies.https://gitlab.idiap.ch/bob/bob/-/issues/237Move the tutorials to bob's documentatoin2017-08-07T12:16:54ZAmir MOHAMMADIMove the tutorials to bob's documentatoincurrently, we have two tutorials:
* https://gitlab.idiap.ch/bob/bob/wikis/Tutorials
* https://gitlab.idiap.ch/bob/bob/wikis/Bob-Starter-Course
How about we move this into bob's docs? The first page of bob's documentation really need...currently, we have two tutorials:
* https://gitlab.idiap.ch/bob/bob/wikis/Tutorials
* https://gitlab.idiap.ch/bob/bob/wikis/Bob-Starter-Course
How about we move this into bob's docs? The first page of bob's documentation really needs a tutorial.https://gitlab.idiap.ch/bob/bob/-/issues/236Problem to save a linear machine2017-08-07T12:16:54ZChristopher FINELLIProblem to save a linear machineI had a problem to save a linear machine otained by CGLogRegTrainer using the function "save(HDF5File)". I got the following error:
"""
Warning! ***HDF5 library version mismatched error***
The HDF5 header files used to compile this appli...I had a problem to save a linear machine otained by CGLogRegTrainer using the function "save(HDF5File)". I got the following error:
"""
Warning! ***HDF5 library version mismatched error***
The HDF5 header files used to compile this application do not match
the version used by the HDF5 library to which this application is linked.
Data corruption or segmentation faults may occur if the application continues.
This can happen when an application was compiled by one version of HDF5 but
linked with a different version of static or shared HDF5 library.
You should recompile the application or check your shared library related
settings such as 'LD_LIBRARY_PATH'.
You can, at your own risk, disable this warning by setting the environment
variable 'HDF5_DISABLE_VERSION_CHECK' to a value of '1'.
Setting it to 2 or higher will suppress the warning messages totally.
Headers are 1.8.16, library is 1.8.17
SUMMARY OF THE HDF5 CONFIGURATION
=================================
General Information:
-------------------
HDF5 Version: 1.8.17
Configured on: Mon May 30 18:15:07 UTC 2016
Configured by: root@99f755eee234
Configure mode: production
Host system: x86_64-unknown-linux-gnu
Uname information: Linux 99f755eee234 3.13.0-86-generic #131-Ubuntu SMP Thu May 12 23:33:13 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Byte sex: little-endian
Libraries: static, shared
Installation point: /idiap/home/cfinelli/.conda/envs/biowave
Compiling Options:
------------------
Compilation Mode: production
C Compiler: /opt/rh/devtoolset-2/root/usr/bin/gcc ( gcc (GCC) 4.8.2 20140120 )
CFLAGS:
H5_CFLAGS: -std=c99 -pedantic -Wall -Wextra -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Winline -Wfloat-equal -Wmissing-format-attribute -Wmissing-noreturn -Wpacked -Wdisabled-optimization -Wformat=2 -Wunreachable-code -Wendif-labels -Wdeclaration-after-statement -Wold-style-definition -Winvalid-pch -Wvariadic-macros -Winit-self -Wmissing-include-dirs -Wswitch-default -Wswitch-enum -Wunused-macros -Wunsafe-loop-optimizations -Wc++-compat -Wstrict-overflow -Wlogical-op -Wlarger-than=2048 -Wvla -Wsync-nand -Wframe-larger-than=16384 -Wpacked-bitfield-compat -Wstrict-overflow=5 -Wjump-misses-init -Wdouble-promotion -Wsuggest-attribute=const -Wtrampolines -Wstack-usage=8192 -Wvector-operation-performance -Wsuggest-attribute=pure -Wsuggest-attribute=noreturn -Wsuggest-attribute=format -O3
AM_CFLAGS:
CPPFLAGS:
H5_CPPFLAGS: -D_GNU_SOURCE -D_POSIX_C_SOURCE=200112L -DNDEBUG -UH5_DEBUG_API
AM_CPPFLAGS: -I/idiap/home/cfinelli/.conda/envs/biowave/include
Shared C Library: yes
Static C Library: yes
Statically Linked Executables: no
LDFLAGS:
H5_LDFLAGS:
AM_LDFLAGS: -L/idiap/home/cfinelli/.conda/envs/biowave/lib
Extra libraries: -lrt -lz -ldl -lm
Archiver: ar
Ranlib: ranlib
Debugged Packages:
API Tracing: no
Languages:
----------
Fortran: no
C++: yes
C++ Compiler: /opt/rh/devtoolset-2/root/usr/bin/g++ ( g++ (GCC) 4.8.2 20140120 )
C++ Flags:
H5 C++ Flags:
AM C++ Flags:
Shared C++ Library: yes
Static C++ Library: yes
Features:
---------
Parallel HDF5: no
High Level library: yes
Threadsafety: no
Default API Mapping: v18
With Deprecated Public Symbols: yes
I/O filters (external): deflate(zlib)
MPE: no
Direct VFD: no
dmalloc: no
Clear file buffers before write: yes
Using memory checker: no
Function Stack Tracing: no
Strict File Format Checks: no
Optimization Instrumentation: no
Bye...
Aborted
"""
From my point of view, I would say I have to update the bob version I have. Am I correct?https://gitlab.idiap.ch/bob/bob/-/issues/235bob verification databases do not use the `original_directory` and `original_...2017-08-07T12:16:54ZManuel Günthersiebenkopf@googlemail.combob verification databases do not use the `original_directory` and `original_extension` parametersSorry that I saw this soo late, after the new database packages have been published already.
I think, during the reimplementation of the databases, something got lost. In the old `bob.db.verification.database.Database` interface, at lea...Sorry that I saw this soo late, after the new database packages have been published already.
I think, during the reimplementation of the databases, something got lost. In the old `bob.db.verification.database.Database` interface, at least two parameters were accepted: `original_directory` and `original_extension`, and there was a method called `original_file_names`, which was using these parameters.
Now, this functionality seems to be completely lost. For example, `bob.db.mobio` has no way of getting the original file names, i.e., the `original_directory` and `original_extension` are not stored in the database anymore. On the other hand, you can still specify these parameters in the constructor:
https://gitlab.idiap.ch/bob/bob.db.mobio/blob/master/bob/db/mobio/query.py#L40
but they are not used anywhere in the code.
I know that most of this functionality was moved to `bob.bio.base.database.BioDatabase`. Hence, I see two different ways of handling this:
> 1. Leave the implementation in `bob.bio.base` and remove the unused keywords in the `bob.db` Database constructors. In this way, the `bob.db` databases do not have the capability to query their original data files.
> 2. Move the functionality of the old `bob.db.verification.utils.Database` into `bob.db.base` (and remove it from `bob.bio.base`). In this way, the databases themselves know their original data.
In a similar manner, the `annotations` function inside the databases are arbitrary. When annotation files are read from file (for example in `bob.db.mobio`), an implementation is provided in `bob.bio.base.database.BioDatabase`: https://gitlab.idiap.ch/bob/bob.bio.base/blob/master/bob/bio/base/database/database.py#L265, as well as in `bob.db.mobio`: https://gitlab.idiap.ch/bob/bob.db.mobio/blob/master/bob/db/mobio/query.py#L602, both of which use the same basic functionality: https://gitlab.idiap.ch/bob/bob.db.base/blob/master/bob/db/base/annotations.py#L35
Hence, to be consistent with option 1. above, we would probably want to *remove* this functionality from `bob.db.mobio`. In fact, in `bob.bio.face`, the `annotations` functionality inside `bob.db.mobio` is not used at all.
On the other hand, there are databases, which store the annotations internally, such as `bob.db.gbu`: https://gitlab.idiap.ch/bob/bob.db.gbu/blob/master/bob/db/gbu/models.py#L51 Hence, for these databases, the `bob.bio.base.database.BioDatabase.annotations`:https://gitlab.idiap.ch/bob/bob.bio.base/blob/master/bob/bio/base/database/database.py#L265 functions need to be overwritten, i.e., in order to use the annotations from those databases. However, I cannot see this happening, e.g., in `bob.bio.face.database.GBUBioDatabase` https://gitlab.idiap.ch/bob/bob.bio.face/blob/master/bob/bio/face/database/gbu.py#L16
Hence, for these databases there is currently **no way** to obtain the annotations from the original `bob.db` databases. Again, there are two solutions:
> A. provide a default implementation for these cases in `bob.bio.base.database.BioDatabase.annotations`, i.e., by checking if the low-level database has an `annotations` function.
> B. Provide these implementations in all derived classes from `BioDatabase`, where the low-level database has annotations stored internally.
I can check, which of the `bob.db` databases are affected and open according issues there. But first, we have to decide, which way to go. I personally would vote for options `1.` and `A.`, as they would require the least modifications, But I can also see the benefits of options `2.` and `B.`, which require more work, as `2.` would add more information to the low-level `bob.db` databases, and `B.` would be cleaner.
@amohammadi @andre.anjos @tiago.pereira @sebastien.marcel What is your opinion? Did I miss something here? Is `bob.db.gbu` (and others) really currently not working?May 2017 Hackathonhttps://gitlab.idiap.ch/bob/bob/-/issues/234Bob documentation still uses the old style2017-08-07T12:16:54ZAndré AnjosBob documentation still uses the old styleWe need to update the `conf.py` from this package to introduce the new theme (RTD). It is much better for visualization on a portable device such as a phone or tablet.We need to update the `conf.py` from this package to introduce the new theme (RTD). It is much better for visualization on a portable device such as a phone or tablet.Tiago de Freitas PereiraTiago de Freitas Pereirahttps://gitlab.idiap.ch/bob/bob/-/issues/233Keeping track of pulls called "[Automatic] update links and the ci mostly"2017-08-07T12:16:54ZAmir MOHAMMADIKeeping track of pulls called "[Automatic] update links and the ci mostly"@bob please don't merge them, I'll do that. If you questions or comments, put it here.@bob please don't merge them, I'll do that. If you questions or comments, put it here.Refactoring 2016 and gitlab migration milestoneAmir MOHAMMADIAmir MOHAMMADIhttps://gitlab.idiap.ch/bob/bob/-/issues/232Integrated doctest on bob are failing for pyrthon 22017-08-07T12:16:54ZTiago de Freitas PereiraIntegrated doctest on bob are failing for pyrthon 2I don't know why this is happening, but since the doctests are made in the dependent packages, I just ignore the doctests for this package.
Follow the logs:
https://gitlab.idiap.ch/bob/bob/pipelines/4068#test
https://gitlab.idia...I don't know why this is happening, but since the doctests are made in the dependent packages, I just ignore the doctests for this package.
Follow the logs:
https://gitlab.idiap.ch/bob/bob/pipelines/4068#test
https://gitlab.idiap.ch/bob/bob/builds/15849
```
Exception occurred:
File "/local/conda/envs/bob-devel-py27/lib/python2.7/site-packages/Sphinx-1.4.1-py2.7.egg/sphinx/ext/doctest.py", line 384, in run_setup_cleanup
doctest_encode(testcode.code, self.env.config.source_encoding), '',
AttributeError: 'str' object has no attribute 'code'
The full traceback has been saved in /tmp/sphinx-err-ds9DNU.log, if you want to report the issue to the developers.
Please also report this if it was a user error, so that a better error message can be provided next time.
A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks!
(15:48:34) Error: Command Failed "/local/gitlab-runner/builds/6b02994f/0/bob/bob/env/bin/python /local/conda/envs/bob-devel-py27/bin/sphinx-build -b doctest /local/gitlab-runner/builds/6b02994f/0/bob/bob/doc bob/sphinx"
```https://gitlab.idiap.ch/bob/bob/-/issues/231Please add bob.ip.flandmark to core bob packages2017-08-07T12:16:54ZAmir MOHAMMADIPlease add bob.ip.flandmark to core bob packagesI am trying to remove extra packages from conda-forge (removing pure python ones) and keep only core bob packages.
however, `bob.ip.flandmark` remains a CPP package which is not part of core bob.
What do you think about adding `bob.ip....I am trying to remove extra packages from conda-forge (removing pure python ones) and keep only core bob packages.
however, `bob.ip.flandmark` remains a CPP package which is not part of core bob.
What do you think about adding `bob.ip.flandmark` to `bob` core packages?
ping @bob https://gitlab.idiap.ch/bob/bob/-/issues/230bob.extension is not in the requirements.txt2017-08-07T12:16:54ZAmir MOHAMMADIbob.extension is not in the requirements.txtTiago de Freitas PereiraTiago de Freitas Pereirahttps://gitlab.idiap.ch/bob/bob/-/issues/229CI integration2017-08-07T12:16:54ZAndré AnjosCI integrationThis package needs to get its own CI build file. This issue is here to keep track of it.This package needs to get its own CI build file. This issue is here to keep track of it.