bob issueshttps://gitlab.idiap.ch/groups/bob/-/issues2018-10-07T10:04:56Zhttps://gitlab.idiap.ch/bob/bob.extension/-/issues/30Automatic CHANGE LOG2018-10-07T10:04:56ZTiago de Freitas PereiraAutomatic CHANGE LOGWe have a lot of software and it is becoming difficult to track the patches of everything.
To make it easy this task we can make the `bob_new_version` script write the file CHANGELOG, before tagging, with the output of the command.
...We have a lot of software and it is becoming difficult to track the patches of everything.
To make it easy this task we can make the `bob_new_version` script write the file CHANGELOG, before tagging, with the output of the command.
```
git log [last-tag]..HEAD --oneline > CHANGELOG
```
What do you think?
https://gitlab.idiap.ch/bob/bob.db.replaymobile/-/issues/2db.sql3 files should not exist in the git repository.2018-09-12T22:01:18ZAmir MOHAMMADIdb.sql3 files should not exist in the git repository.You should remove that file, and uncomment `#db.sql3` in `.gitignore` too.
The way to download that file is `bin/bob_dbmanage.py replaymobile download`
The way to upload the file (if you change it) is `bin/bob_dbmanage.py replaymob...You should remove that file, and uncomment `#db.sql3` in `.gitignore` too.
The way to download that file is `bin/bob_dbmanage.py replaymobile download`
The way to upload the file (if you change it) is `bin/bob_dbmanage.py replaymobile upload` (while being at idiap machines)https://gitlab.idiap.ch/bob/bob.learn.em/-/issues/20KmeansTrainer, Change the default initialization to RANDOM_NO_DUPLICATES2017-08-12T07:46:06ZTiago de Freitas PereiraKmeansTrainer, Change the default initialization to RANDOM_NO_DUPLICATESToday the default is RANDOMToday the default is RANDOMTiago de Freitas PereiraTiago de Freitas Pereirahttps://gitlab.idiap.ch/bob/bob.learn.em/-/issues/21Input check2017-08-12T07:46:06ZTiago de Freitas PereiraInput checkToday we don't do any check in the inputs.
Would be handy to have some checks (NaN, Inf) before the training.Today we don't do any check in the inputs.
Would be handy to have some checks (NaN, Inf) before the training.Tiago de Freitas PereiraTiago de Freitas Pereirahttps://gitlab.idiap.ch/bob/bob.bio.face/-/issues/11Nightly builds are failing2017-10-20T02:30:35ZTiago de Freitas PereiraNightly builds are failingThe new detection implemented and merged here https://gitlab.idiap.ch/bob/bob.ip.facedetect/merge_requests/1
is making the builds failing. Look the nightlies https://gitlab.idiap.ch/bob/bob.nightlies/builds/21684
We need to update the u...The new detection implemented and merged here https://gitlab.idiap.ch/bob/bob.ip.facedetect/merge_requests/1
is making the builds failing. Look the nightlies https://gitlab.idiap.ch/bob/bob.nightlies/builds/21684
We need to update the unit tests.Tiago de Freitas PereiraTiago de Freitas Pereirahttps://gitlab.idiap.ch/bob/bob.learn.em/-/issues/22Documentation of this package sucks.2017-08-12T07:46:06ZManuel Günthersiebenkopf@googlemail.comDocumentation of this package sucks.There are many cases inside this package, where functions or parameters are documented insufficiently. There are already questions asked about this:
https://groups.google.com/forum/#!topic/bob-devel/wUCFYfuFQvs
It would be very nice if...There are many cases inside this package, where functions or parameters are documented insufficiently. There are already questions asked about this:
https://groups.google.com/forum/#!topic/bob-devel/wUCFYfuFQvs
It would be very nice if someone, who knows what the functions are doing (@tiago.pereira) could add some documentation for these.May 2017 HackathonTiago de Freitas PereiraTiago de Freitas Pereirahttps://gitlab.idiap.ch/bob/bob.bio.base/-/issues/49dependency to gridtk2018-06-03T12:14:15ZManuel Günthersiebenkopf@googlemail.comdependency to gridtkI was wondering, why this package is now -- by default -- dependent on gridtk?
GridTK is not required to use this package -- not even to run the tests (there is an actual flag that tests if gridtk is installed and skips the tests that ...I was wondering, why this package is now -- by default -- dependent on gridtk?
GridTK is not required to use this package -- not even to run the tests (there is an actual flag that tests if gridtk is installed and skips the tests that require gridtk). I can understand that we have gridtk inside ``test_requirements.txt``, but bob.bio packages do not require gridtk to run (not even ``bob.bio.gmm``). I can understand that it is a nice addition to have, but I don't see, why this is a default requirement.https://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.bio.spear/-/issues/18Error while running experiment using amicorpus database2017-10-25T00:08:37ZAlain KOMATYError while running experiment using amicorpus databaseI am trying to run the following experiment on ami database
./bin/verify.py -d 'ami' -p 'energy-2gauss' -e 'mfcc-60' --algorithm 'gmm' -s ami_ubm_gmm --groups {dev,eval} -R '/idiap/user/akomaty/AMI-test/' -T '/idiap/temp/akomaty/AMI-tes...I am trying to run the following experiment on ami database
./bin/verify.py -d 'ami' -p 'energy-2gauss' -e 'mfcc-60' --algorithm 'gmm' -s ami_ubm_gmm --groups {dev,eval} -R '/idiap/user/akomaty/AMI-test/' -T '/idiap/temp/akomaty/AMI-test/' -vvv
The error I am getting is:
energy_array = e(rate_wavsample[1])
TypeError: `bob.ap.Energy' only supports 1D 64-bit float arrays for input array `input'.
While debugging I found that
rate_wavsample[1] =
array([[ 0., 0.],
[ -2., -2.],
[ 0., 0.],
...,
[-26., -26.],
[-27., -27.],
[-28., -28.]])
A screenshot is attached.
Someone could have an idea why I am getting a 2D array instead of 1D? I could't trace the origin of this problem.
![Energy_2Gauss.py](/uploads/4173019c128fcac6d178911130e82bb5/Energy_2Gauss.py.png)https://gitlab.idiap.ch/bob/bob.bio.video/-/issues/4Nightly build is failing2017-10-21T16:05:51ZTiago de Freitas PereiraNightly build is failingThe new detection implemented and merged here bob/bob.ip.facedetect!1 is making the builds failing. Look the nightlies https://gitlab.idiap.ch/bob/bob.nightlies/builds/21684
We need to update the unit tests.The new detection implemented and merged here bob/bob.ip.facedetect!1 is making the builds failing. Look the nightlies https://gitlab.idiap.ch/bob/bob.nightlies/builds/21684
We need to update the unit tests.Tiago de Freitas PereiraTiago de Freitas Pereirahttps://gitlab.idiap.ch/bob/bob.db.base/-/issues/10Missing documentation parts (annotations, objects)2017-09-30T18:11:14ZAndré AnjosMissing documentation parts (annotations, objects)After the migration from `bob.db.verification.utils` of some classes, we still miss the documentation bits.
@amohammadi, since you did this work, could you please patch-up the docs as well?After the migration from `bob.db.verification.utils` of some classes, we still miss the documentation bits.
@amohammadi, since you did this work, could you please patch-up the docs as well?Refactoring 2016 and gitlab migration milestoneAmir MOHAMMADIAmir MOHAMMADIhttps://gitlab.idiap.ch/bob/bob.db.kboc16/-/issues/1Dependency on deprecated antispoofing.utils and bob.db.verification.utils pac...2018-09-10T21:41:22ZPavel KORSHUNOVDependency on deprecated antispoofing.utils and bob.db.verification.utils packagesThis package still depends on the deprecated bob.db.verification.utils. The dependency should be removed.This package still depends on the deprecated bob.db.verification.utils. The dependency should be removed.André AnjosAndré Anjoshttps://gitlab.idiap.ch/bob/bob.db.msu_mfsd_mod/-/issues/4Dependency on deprecated antispoofing.utils package2018-09-13T04:18:41ZPavel KORSHUNOVDependency on deprecated antispoofing.utils packageThis package still depends on the deprecated `antispoofing.utils`. The dependency should be removed.This package still depends on the deprecated `antispoofing.utils`. The dependency should be removed.Sushil BHATTACHARJEESushil BHATTACHARJEEhttps://gitlab.idiap.ch/bob/nightlies/-/issues/15Automatic release of packages in the nightlies2018-07-12T07:52:31ZAmir MOHAMMADIAutomatic release of packages in the nightliesIdeally, when we merge a pull request or do a quick fix, we want to release that package **after** the tests are passing in the nightlies.
This means, we should be releasing packages with nightlies. I was thinking in the commit messag...Ideally, when we merge a pull request or do a quick fix, we want to release that package **after** the tests are passing in the nightlies.
This means, we should be releasing packages with nightlies. I was thinking in the commit message of `bob.anypackage` we put `commit message blah [nightlies release 2.1.0]`and nightlies would handle the rest.
How about that? @andre.anjos @tiago.pereira @pkorshunov @mguentherhttps://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.bio.face/-/issues/12What is the FaceBioFile good for?2017-10-20T02:30:35ZManuel Günthersiebenkopf@googlemail.comWhat is the FaceBioFile good for?I have just came across the `FaceBioFile`, which simply derives from `bob.bio.base.database.file.BioFile` without adding any functionality: https://gitlab.idiap.ch/bob/bob.bio.face/blob/master/bob/bio/face/database/database.py#L13
Why d...I have just came across the `FaceBioFile`, which simply derives from `bob.bio.base.database.file.BioFile` without adding any functionality: https://gitlab.idiap.ch/bob/bob.bio.face/blob/master/bob/bio/face/database/database.py#L13
Why do we have this extra level of abstraction/inheritance? Can't we simply use the `bob.bio.base.database.file.BioFile` directly, wherever we use `FaceBioFIle` now?
ping @andre.anjos @amohammadi @tiago.pereira @sebastien.marcelTiago de Freitas PereiraTiago de Freitas Pereirahttps://gitlab.idiap.ch/bob/bob.bio.base/-/issues/50Why is the BioDatabase.model_ids_with_protocol function required?2018-06-03T12:14:15ZManuel Günthersiebenkopf@googlemail.comWhy is the BioDatabase.model_ids_with_protocol function required?I am trying to implement a new database interface for one of our local databases, which uses the `BioFileSet` interface. I have created a class derived from `BioDatabase`, and I am implementing the functions.
While implementing the data...I am trying to implement a new database interface for one of our local databases, which uses the `BioFileSet` interface. I have created a class derived from `BioDatabase`, and I am implementing the functions.
While implementing the database, I was stumbling upon a *pure virtual* function that I don't understand: `model_ids_with_protocol`. Why do I have to implement this function, and why can't I just simply implement the `model_ids` function?
When I see it correctly, the `model_ids_with_protocol` function is called from within `model_ids`: https://gitlab.idiap.ch/bob/bob.bio.base/blob/master/bob/bio/base/database/database.py#L378
passing a the member variable `self.protocol` as the protocol.
This is IMHO completely useless. The `self.protocol` is available in the derived class as well, and it can be used inside there, without needing to pass it as a parameter. The exact same is true for the functions `objects`: https://gitlab.idiap.ch/bob/bob.bio.base/blob/master/bob/bio/base/database/database.py#L381, `object_sets`: https://gitlab.idiap.ch/bob/bob.bio.base/blob/master/bob/bio/base/database/database.py#L565 and the `tmodel_ids_with_protocol`: https://gitlab.idiap.ch/bob/bob.bio.base/blob/master/bob/bio/base/database/database.py#L732
So, is there any reasoning behind having the `protocol` parameters in these functions, other than 'It has been that way in the bob.db.verification.database interface' (where it was required)?
@amohammadihttps://gitlab.idiap.ch/bob/bob.bio.base/-/issues/51--execute-only command line option does not work2018-06-03T12:14:15ZManuel Günthersiebenkopf@googlemail.com--execute-only command line option does not workThere is a small bug in the implementation of the `--execute-only` flag that disallows it to work.There is a small bug in the implementation of the `--execute-only` flag that disallows it to work.Manuel Günthersiebenkopf@googlemail.comManuel Günthersiebenkopf@googlemail.comhttps://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.measure/-/issues/19load_scores extremely memory hungry2021-06-18T12:58:49ZManuel Günthersiebenkopf@googlemail.comload_scores extremely memory hungryThe new implementation of score loading is memory hungry, as it stores the whole score file in memory. For large score files that have long `client_id`'s and `label`'s, this might easily be too much for a normal desktop machine.
To spli...The new implementation of score loading is memory hungry, as it stores the whole score file in memory. For large score files that have long `client_id`'s and `label`'s, this might easily be too much for a normal desktop machine.
To split the score file into positives and negatives, most of the information (for example, the `label`s) is completely irrelevan.
I remember that I have had this problem with an older version of `bob.measure`, and this is why I have implemented the score reading using a generator function (i.e., `yield`'ing the file line by line) instead of keeping all information of the score file at the same time.
I will provide a better alternative of the 'load_scores' function as a generator function, which does not store the whole score file in memory.Manuel Günthersiebenkopf@googlemail.comManuel Günthersiebenkopf@googlemail.com