bob issueshttps://gitlab.idiap.ch/bob/bob/-/issues2017-08-07T12:16:53Zhttps://gitlab.idiap.ch/bob/bob/-/issues/244Documentation of bob builds documentation of all core bob packages2017-08-07T12:16:53ZAmir MOHAMMADIDocumentation of bob builds documentation of all core bob packagesThis takes a lot of time. I know @tiago.pereira that this is important but we are going to tackle that through here: https://gitlab.idiap.ch/bob/bob.admin/issues/2This takes a lot of time. I know @tiago.pereira that this is important but we are going to tackle that through here: https://gitlab.idiap.ch/bob/bob.admin/issues/2May 2017 HackathonAmir MOHAMMADIAmir MOHAMMADIhttps://gitlab.idiap.ch/bob/bob/-/issues/243"Core" documentation is too complex and should be reorganised2017-08-07T12:16:53ZGuillaume HEUSCH"Core" documentation is too complex and should be reorganisedDear all,
I found it confusing for a newcomer to follow all the documentation (install, tutorial, development, database...) attached to this package, and displayed on the same page.
Here's what I suggest for the installation instructio...Dear all,
I found it confusing for a newcomer to follow all the documentation (install, tutorial, development, database...) attached to this package, and displayed on the same page.
Here's what I suggest for the installation instruction:
* minimal instructions on how to install bob (i.e. core packages) using conda (and only this). This means:
- merge the binary installation / detailed installation instructions into a single, simple set of commented instructions
- remove stable bob installation instructions
- move the compiling from source section to another page (people willing to do that should be able to dig a bit deeper into the doc)
The tutorials should be placed elsewhere too (installing and using are not the same thing, not to mention developing). Moreover, from Bob's homepage, clicking on install or on documentation will redirect you to basically the same page.
Again, in my opinion, the tutorial should be separated from the installation instructions, and should only contain more or less basic stuff - just a few examples (such as loading an image) . Then, a list of packages with a small desciption on what it does shoul dbe displayed, with link to the package documentation.
Another, different page should be set up with instruction for package development too.
What do you think ?
ping @bobMay 2017 HackathonAmir MOHAMMADIAmir MOHAMMADIhttps://gitlab.idiap.ch/bob/bob/-/issues/241draw a clear line between installing bob packages for using only and installi...2017-08-07T12:16:53ZAmir MOHAMMADIdraw a clear line between installing bob packages for using only and installing with buildout for development.We have to draw a clear line between installing bob packages for using only and installing with buildout for development.
Now that we are advertising people to use conda and pip for installation, we need to reflect that in our documentat...We have to draw a clear line between installing bob packages for using only and installing with buildout for development.
Now that we are advertising people to use conda and pip for installation, we need to reflect that in our documentation too.
For example, all the commands in the documentations start with `./bin/` which is not really necessary and confusing to
people not using buildout. Example: https://www.idiap.ch/software/bob/docs/latest/bioidiap/bob.db.voxforge/master/index.html#getting-the-dataMay 2017 HackathonAlain KOMATYAlain KOMATYhttps://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 Hackathon