LabelBOT

[gkourie]

TODO

Backend

• Adjust request format for storing image annotations: The store method in ImageAnnotationController requires a label_id in the request, but when LabelBOT is active, a request with a feature vector should be accepted without label_id.
• Attach additional labels to the response: Since LabelBOT may suggest multiple labels, these labels should be included in the response appropriately.
• Check if HNSW index exists before running ANN if not, switch to KNN.
• Temporarily drop the HNSW index and rollback the transaction: When switching to exact KNN, the HNSW index must be temporarily dropped, and the transaction should be rolled back.

Frontend

• If Label Tree doesn't contain any labels, then UI should show an appropriate message (LabelBOT can't be activated).

[mzur]

Please don't implement all the logic as helper methods. Since the logic is used only in the single controller (for now), implement it as (protected) controller methods there.

Also please us camelCase for variable names.

Finally, please fix the failing checks (except the test-current check which fails because biigle/largo is not there). The lint checks can be run locally with composer lint and composer fix.

[mzur]

Just minor comments left now. We have to make sure that we get the exact queries here. Maybe you can dump the two queries as I explained below and post them here for comparison?

[mzur]

Looks fine so far (ignoring the missing TODOs). Please go ahead 😉

[gkourie]

@mzur what do you think about the last three points of TODO?

[mzur]

The query must always be limited to the label trees of the project. Otherwise users might see labels of other users which they are not allowed to see. If no labels exist, the result is empty and that's ok. The UI will show an appropriate message if no label exists (i.e. LabelBOT can't be activated).

If the label tree contains only one label then the existing search will automatically return this label, right? No need to implement a special case for this.

[mzur]

The label_tree_id index is always there. It is created in a migration. You can just assume that it is there. Also the index name is fixed (by Laravel conventions). It should not be configurable.

[mzur]

The HNSW index will also be created in a migration and the name will be fixed. After the update, the migration is run and you can assume that the index exists.

[gkourie]

okay, thanks.