bob issueshttps://gitlab.idiap.ch/groups/bob/-/issues2021-10-04T11:50:41Zhttps://gitlab.idiap.ch/bob/bob/-/issues/270Problem installing bob with conda2021-10-04T11:50:41ZGreg BurmanProblem installing bob with condaI've tried installing bob using the install instructions provided: https://www.idiap.ch/software/bob/docs/bob/docs/stable/install.html
However, when I run the `conda create` command under step 3) I get the following error:
```
$ conda ...I've tried installing bob using the install instructions provided: https://www.idiap.ch/software/bob/docs/bob/docs/stable/install.html
However, when I run the `conda create` command under step 3) I get the following error:
```
$ conda create --name bob_env1 --override-channels -c https://www.idiap.ch/software/bob/conda -c defaults python=3 bob.io.image bob.bio.face
Collecting package metadata (current_repodata.json): done
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: /
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abort.
failed
UnsatisfiableError: The following specifications were found to be incompatible with each other:
Output in format: Requested package -> Available versions
Package bob.io.image conflicts for:
bob.bio.face -> bob.io.image[version='>=2.4.1,<3.0a0|>=2.4.2,<3.0a0|>=2.4.3,<3.0a0|>=2.4.4,<3.0a0|>=2.4.5,<3.0a0|>=2.4.6,<3.0a0|>=2.5.0,<3.0a0']
bob.io.image
Package python conflicts for:
python=3
bob.bio.face -> python[version='>=2.7,<2.8.0a0|>=3.6,<3.7.0a0|>=3.7,<3.8.0a0|>=3.8,<3.9.0a0']
bob.bio.face -> matplotlib[version='>=3.3.2,<4.0a0'] -> python[version='>=3.5,<3.6.0a0|>=3.9,<3.10.0a0']
Package _libgcc_mutex conflicts for:
python=3 -> libgcc-ng[version='>=7.5.0'] -> _libgcc_mutex[version='*|0.1',build=main]
bob.io.image -> libgcc-ng[version='>=7.3.0'] -> _libgcc_mutex[version='*|0.1',build=main]The following specifications were found to be incompatible with your system:
- feature:/linux-64::__glibc==2.33=0
- feature:|@/linux-64::__glibc==2.33=0
- python=3 -> libgcc-ng[version='>=7.5.0'] -> __glibc[version='>=2.17']
Your installed version is: 2.33
```
It looks like there are several package conflicts for `bob.io.image` and `bob.bio.face`.
I have successfully managed to install bob using the Installation instructions several times before, so this issue seems to be pretty new.Conda-forge migrationhttps://gitlab.idiap.ch/bob/bob.devtools/-/issues/63Add pre-commit checks to the CI2021-10-01T13:45:46ZAmir MOHAMMADIAdd pre-commit checks to the CISome packages are starting to ship a `.pre-commit-config.yaml` file. It would be a good idea to check for this file and run the hooks automatically in the CI.Some packages are starting to ship a `.pre-commit-config.yaml` file. It would be a good idea to check for this file and run the hooks automatically in the CI.https://gitlab.idiap.ch/bob/bob.devtools/-/issues/79Using docutils>=0.17 unformats bulleted lists2021-10-01T13:45:27ZAndré AnjosUsing docutils>=0.17 unformats bulleted listsAs reported on this SO thread (https://stackoverflow.com/questions/67542699/readthedocs-sphinx-not-rendering-bullet-list-from-rst-file), there seems to be a problem with docutils 0.17. Our conda-build-config does not specify it, so the ...As reported on this SO thread (https://stackoverflow.com/questions/67542699/readthedocs-sphinx-not-rendering-bullet-list-from-rst-file), there seems to be a problem with docutils 0.17. Our conda-build-config does not specify it, so the latest (0.17.1) gets installed. Unfortunately, that is still broken.
@bob: this is affecting all sphinx documentation generated on the nightlies.https://gitlab.idiap.ch/bob/bob.devtools/-/issues/77Using .* with relational operator is superfluous and deprecated and will be r...2021-10-01T13:45:09ZAmir MOHAMMADIUsing .* with relational operator is superfluous and deprecated and will be removed in a future version of conda.We're getting warnings like:
```
Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 1.*, but conda is ignoring the .* and treating it as 1
Using .* with relatio...We're getting warnings like:
```
Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 1.*, but conda is ignoring the .* and treating it as 1
Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 2.*, but conda is ignoring the .* and treating it as 2
Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 3.*, but conda is ignoring the .* and treating it as 3
Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 2.*, but conda is ignoring the .* and treating it as 2
Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 4.*, but conda is ignoring the .* and treating it as 4
Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 0.23.*, but conda is ignoring the .* and treating it as 0.23
Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 3.*, but conda is ignoring the .* and treating it as 3
Using .* with relational operator is superfluous and deprecated and will be removed in a future version of conda. Your spec was 3.6.*, but conda is ignoring the .* and treating it as 3.6
```
e.g. https://gitlab.idiap.ch/bob/nightlies/-/jobs/237973
The `conda/meta.yaml` recipes of packages need to be updated and probably some other places.https://gitlab.idiap.ch/bob/bob.learn.libsvm/-/issues/12DEPRECATION2021-09-17T14:19:31ZTiago de Freitas PereiraDEPRECATIONThis package will be deprecatedThis package will be deprecatedBob 9.0.0Amir MOHAMMADIAmir MOHAMMADIhttps://gitlab.idiap.ch/bob/bob.learn.mlp/-/issues/11DEPRECATION2021-09-17T14:19:31ZTiago de Freitas PereiraDEPRECATIONThis package will be deprecated in favor of Tensorflow/PyTorchThis package will be deprecated in favor of Tensorflow/PyTorchBob 9.0.0Amir MOHAMMADIAmir MOHAMMADIhttps://gitlab.idiap.ch/bob/bob.bio.video/-/issues/13Videos should be loaded into memory frame by frame.2021-09-09T07:07:39ZAmir MOHAMMADIVideos should be loaded into memory frame by frame.Most of bob.bio.video classes accept framecontainers while in all cases only one frame at a time is needed to be processed.
Loading the whole video into memory is a time consuming and memory hungry task.
I wonder if we could come up with...Most of bob.bio.video classes accept framecontainers while in all cases only one frame at a time is needed to be processed.
Loading the whole video into memory is a time consuming and memory hungry task.
I wonder if we could come up with another scheme of handling videos which just
loads one frame at a time into the memory.
What do you think?https://gitlab.idiap.ch/bob/bob.bio.video/-/issues/10undefined variable in Algorithm wrapper2021-09-09T07:03:22ZAmir MOHAMMADIundefined variable in Algorithm wrapperHere it is: https://gitlab.idiap.ch/bob/bob.bio.video/blob/0ba8960898586974ad5da0b1d64d09406a672b12/bob/bio/video/algorithm/Wrapper.py#L312
Instead, it should be: `probe = [frame[1] for probe in probes for frame in probe]`.
It also need...Here it is: https://gitlab.idiap.ch/bob/bob.bio.video/blob/0ba8960898586974ad5da0b1d64d09406a672b12/bob/bio/video/algorithm/Wrapper.py#L312
Instead, it should be: `probe = [frame[1] for probe in probes for frame in probe]`.
It also needs a test case to make sure this part of the code is tested too.https://gitlab.idiap.ch/bob/bob.bio.video/-/issues/6Using super() for base class function calls2021-09-09T07:02:29ZManuel Günthersiebenkopf@googlemail.comUsing super() for base class function callsAfter bob.bio.base#64 is merged, we can go ahead and use super() to call base class functionality here, too. This mainly should affect constructor calls.After bob.bio.base#64 is merged, we can go ahead and use super() to call base class functionality here, too. This mainly should affect constructor calls.May 2017 Hackathonhttps://gitlab.idiap.ch/bob/bob.bio.video/-/issues/15Port Dask Pipelines2021-09-09T07:00:52ZTiago de Freitas PereiraPort Dask Pipelines* [x] wrappers for sciki-learn estimators
* [x] wrapper for BiometricAlgorithm
* [x] documentation
* [x] Remove FrameContainer, FrameSelector, and wrappers for old preprocessors, extractors, and algorithms
* [x] Port VideoBioFile to use ...* [x] wrappers for sciki-learn estimators
* [x] wrapper for BiometricAlgorithm
* [x] documentation
* [x] Remove FrameContainer, FrameSelector, and wrappers for old preprocessors, extractors, and algorithms
* [x] Port VideoBioFile to use VideoAsArray and VideoLikeContainer.Bob 9.0.0Amir MOHAMMADIAmir MOHAMMADIhttps://gitlab.idiap.ch/bob/bob.bio.video/-/issues/19Biometrics experiments are not automatically possible with this package2021-09-09T07:00:31ZTiago de Freitas PereiraBiometrics experiments are not automatically possible with this packageHi,
I've tried to run an experiment using Youtube face database and there's nothing binding our `VideoWrapper` with our FR baselines.
We need to:
1. create a wrapper that wraps the scikit-learn Pipeline with the Video Wrapper
2. A CL...Hi,
I've tried to run an experiment using Youtube face database and there's nothing binding our `VideoWrapper` with our FR baselines.
We need to:
1. create a wrapper that wraps the scikit-learn Pipeline with the Video Wrapper
2. A CLI command that allow us to use any baseline with video databases.
ping @mguenther @xzhangTiago de Freitas PereiraTiago de Freitas Pereirahttps://gitlab.idiap.ch/bob/bob.bio.video/-/issues/20Port Youtube faces2021-09-09T07:00:22ZTiago de Freitas PereiraPort Youtube facesyoutube faces need to be ported the to the new API.youtube faces need to be ported the to the new API.Tiago de Freitas PereiraTiago de Freitas Pereirahttps://gitlab.idiap.ch/bob/bob.bio.base/-/issues/160Databases with mutiple file extension (e.g. FRGC).2021-08-13T13:57:35ZLaurent COLBOISDatabases with mutiple file extension (e.g. FRGC).Hello,
In the current CSV-based implementation of database wrappers, we specify the extension of the files to load as an argument of the sample loader.
This poses problem for example in the particular case of [bob.bio.face.database.FRGC...Hello,
In the current CSV-based implementation of database wrappers, we specify the extension of the files to load as an argument of the sample loader.
This poses problem for example in the particular case of [bob.bio.face.database.FRGC](https://gitlab.idiap.ch/bob/bob.bio.face/-/blob/master/bob/bio/face/database/frgc.py#L41) which has some images stored as `.JPG` while some others are stored as `.jpg`. Currently trying to load the latter ones raises an error, as the loader looks only for a `.JPG` extensions.
I think the most straightforward fix would be for the sample loader to accept a list of valid extensions and try all of them at loading time. What do you think ?
Also, I wonder if this type of situation is very niche (i.e. I will implement a custom sample loader just for FRGC), or if it would make sense to update the default CSVToSampleLoaderBiometrics to generally handle this type of case ?
Another case were it could be useful is to implement some cross-database evaluation protocols (e.g. samples from database A as models and samples from database B as probes), where we could have different extensions as well. I had to do this kind of evaluation in the past when comparing FFHQ against Syn-Multi-PIE.
ping @tiago.pereiraLaurent COLBOISLaurent COLBOIShttps://gitlab.idiap.ch/bob/bob.bio.base/-/issues/157Issues in CSVToSampleLoaderVulnerability2021-08-13T12:57:12ZLaurent COLBOISIssues in CSVToSampleLoaderVulnerabilityHello,
There are some remaining issues with the [CSVToSampleLoaderVulnerability](https://gitlab.idiap.ch/bob/bob.bio.base/-/blob/master/bob/bio/base/database/csv_dataset.py#L154). Mainly:
1. Currently raises an error as the `reference_i...Hello,
There are some remaining issues with the [CSVToSampleLoaderVulnerability](https://gitlab.idiap.ch/bob/bob.bio.base/-/blob/master/bob/bio/base/database/csv_dataset.py#L154). Mainly:
1. Currently raises an error as the `reference_id` parameter is accidentally [fed twice](https://gitlab.idiap.ch/bob/bob.bio.base/-/blob/master/bob/bio/base/database/csv_dataset.py#L240) when creating the `DelayedSample` (once explicitly, once as an element of the `kwargs` dictionnary).
2. (Minor) When loading reference samples, it still attaches a list of `references` to which the Sample should be compared, which doesn't really make sense. I think it is still fine to leave it that way as I guess this metadata won't be used anyway when running `vanilla-biometrics`.
3. Major one : when `attack_type` is None (cf. [this snippet](https://gitlab.idiap.ch/bob/bob.bio.base/-/blob/master/bob/bio/base/database/csv_dataset.py#L220)), we are supposed to compare the probe sample to every biometric reference. However, I believe this won't currently work as the list of `all_references` is [built on the fly](https://gitlab.idiap.ch/bob/bob.bio.base/-/blob/master/bob/bio/base/database/csv_dataset.py#L209). So, when treating the first probes, this list of `all_references` could be almost empty. This should not pose problem if we call `db.references()` before ever calling `db.probes()`, but I think it is unsafe to rely on this assumption.
As I am planning to use this loader, I could work on fixing those aspects. 1) seems pretty straightforward to solve, however I am not sure how to approach 2) and 3) yet, so I am open to suggestions if you have some.
ping @ydayerhttps://gitlab.idiap.ch/bob/bob.pipelines/-/issues/25Better handling of file structures with CheckpointWrapper2021-08-13T11:13:09ZTiago de Freitas PereiraBetter handling of file structures with CheckpointWrapperSome databases have file structures very flat (with more than 30k files in a directory).
This is not good for the Idiap file structure and can let our I/O super slow.
We should implement a hash function in `CheckpointWrapper.make_path` ...Some databases have file structures very flat (with more than 30k files in a directory).
This is not good for the Idiap file structure and can let our I/O super slow.
We should implement a hash function in `CheckpointWrapper.make_path` that generates directory names given `sample.key` to limit the number of files in a directory to 1000 files.
ping @lcolbois (this touches experiments with IJB-C)https://gitlab.idiap.ch/bob/bob.bio.face/-/issues/58New release2021-07-28T15:18:03ZTiago de Freitas PereiraNew releaseWe have had several modifications since the last release. Can we have a new minor release of this one?
We would need to release `bob.bio.base` too (if not the whole bob).
ThanksWe have had several modifications since the last release. Can we have a new minor release of this one?
We would need to release `bob.bio.base` too (if not the whole bob).
Thankshttps://gitlab.idiap.ch/bob/bob.bio.face/-/issues/47Checkpoint cropped face images in .png files (by default) instead of .h5 files2021-07-09T12:30:44ZAmir MOHAMMADICheckpoint cropped face images in .png files (by default) instead of .h5 filesThe checkpoint files are basically .png images but saving them in .h5 files makes them inaccessible for opening and viewing.The checkpoint files are basically .png images but saving them in .h5 files makes them inaccessible for opening and viewing.Bob 9.0.0Amir MOHAMMADIAmir MOHAMMADIhttps://gitlab.idiap.ch/bob/bob.bio.face/-/issues/48images are assumed to be between 0 and 255 irrespective of their dtype2021-07-09T12:29:50ZAmir MOHAMMADIimages are assumed to be between 0 and 255 irrespective of their dtypeUsually, it is conventional that the dtype of the image determines the range of an image.
For example, when
* dtype is `uint8` image is assumed to be 0 and 255 and:
* `uint16` -> [0,65535]
* `float` -> [0,1]
This is expected in many Py...Usually, it is conventional that the dtype of the image determines the range of an image.
For example, when
* dtype is `uint8` image is assumed to be 0 and 255 and:
* `uint16` -> [0,65535]
* `float` -> [0,1]
This is expected in many Python libraries such as matplotlib and tensorflow.
However, in bob.bio.face, it is assumed that images are between 0 and 255 irrespective of their type:
- https://gitlab.idiap.ch/bob/bob.bio.face/-/blob/8c50e1ee70d866b6c39d7c228cdf1df475a63822/bob/bio/face/database/pola_thermal.py#L103
- https://gitlab.idiap.ch/bob/bob.bio.face/-/blob/8c50e1ee70d866b6c39d7c228cdf1df475a63822/bob/bio/face/embeddings/resnet50.py#L138
- https://gitlab.idiap.ch/bob/bob.bio.face/-/blob/8c50e1ee70d866b6c39d7c228cdf1df475a63822/bob/bio/face/embeddings/tf2_inception_resnet.py#L19
- https://gitlab.idiap.ch/bob/bob.bio.face/-/blob/8c50e1ee70d866b6c39d7c228cdf1df475a63822/bob/bio/face/embeddings/mobilenet_v2.py#L68
I think this problem has arisen due to unconventional conversion of the image dtype in:
https://gitlab.idiap.ch/bob/bob.bio.face/-/blob/8c50e1ee70d866b6c39d7c228cdf1df475a63822/bob/bio/face/preprocessor/Base.py#L102
where the range of the image is not changed during the conversion.
I think it is worth the effort to refactor the code and respect conventional image value ranges in bob.bio.face;
a function similar to https://www.tensorflow.org/api_docs/python/tf/image/convert_image_dtype?hl=en
could alleviate this problem.Amir MOHAMMADIAmir MOHAMMADIhttps://gitlab.idiap.ch/bob/bob/-/issues/266Bob 9.0.0rc12021-07-07T07:34:13ZTiago de Freitas PereiraBob 9.0.0rc1Hi guys,
Since we are in a consistent sequence of green nightlies, I think we can safely have a release candidate of Bob with the new stuff.
I would like to pin everything on `bob.nightlies` as `rc1` and release it on our stable channe...Hi guys,
Since we are in a consistent sequence of green nightlies, I think we can safely have a release candidate of Bob with the new stuff.
I would like to pin everything on `bob.nightlies` as `rc1` and release it on our stable channel.
I would appreciate your input on it.
ThanksBob 9.0.0https://gitlab.idiap.ch/bob/bob.db.base/-/issues/22Loading data from databases with minimal parameters provided2021-06-24T12:54:01ZAmir MOHAMMADILoading data from databases with minimal parameters providedAs of now it seems that we do not have a single way to load a sample in our databases.
The old db's load like this:
```python
db = Database(original_directory='/some/path')
sample = db.objects()[0]
data = sample.load(db.original_directo...As of now it seems that we do not have a single way to load a sample in our databases.
The old db's load like this:
```python
db = Database(original_directory='/some/path')
sample = db.objects()[0]
data = sample.load(db.original_directory, db.original_extension)
```
The current guide advices this:
```python
db = Database(original_directory='/some/path')
sample = db.objects()[0]
data = sample.load()
```
but this requires changes in all db interfaces because it suggests that each db sample object will carry a reference to `original_directory`.
I suggest we do like this:
```python
db = Database(original_directory='/some/path')
sample = db.objects()[0]
data = db.load(sample)
```
This is similar in how annotations are returned in high-level interfaces and hides away the fact that the database is a file-based one.
It can be easily implemented for all current databases that we have like this:
```python
class bob.db.base.Database:
def load(self, file):
return file.load(self.original_directory, self.original_extension)
```
What do you think?Bob 9.0.0