A fast, easy-to-use, production-ready inference server for computer vision supporting deployment of many popular model architectures and fine-tuned models.
In this PR we attempt to add suites of blocks serving for the following use cases:
there is detection followed by specialised classification model
there is need to construct outputs based on "switch-case" like statements
Found 3 different solutions for situation when we detect -> crop -> classify -> construct results based on comparison of aggregated cls results with reference:
SOLUTION A: put crops classification results into "class", "class_id" and "confidence" fields of detections
SOLUTION B: grab classification results into list of values (list of class names, following the order, maybe letting people configure what to extract - class names / confidences etc)
SOLUTION C: generalised SOLUTION B - step to transform each cls result to extract property, step to aggregate properties into lists based on dimensionality, step with expression
Implemented SOLUTION A as I find it most elegant
Two bugs fixed in this PR:
results of multi-label classification did not expose class_id which was present in model output, just not included into entity stating API responses
Execution Engine was broken whenever there were situations of empty results in dimensionality unwrapping (no detections -> crops, then "stitch" taking detections and cropped results, with some of upper-level data missing - fixed by producing None elements which will be filtered out if that's the wish of block)
List any dependencies that are required for this change.
Type of change
Please delete options that are not relevant.
[x] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] This change requires a documentation update
How has this change been tested, please provide a testcase or example of how you tested the change?
new tests
CI still green
todo - e2e tests before release, waiting for UI
Any specific deployment considerations
For example, documentation changes, usability, usage/costs, secrets, etc.
Description
In this PR we attempt to add suites of blocks serving for the following use cases:
Found 3 different solutions for situation when we detect -> crop -> classify -> construct results based on comparison of aggregated cls results with reference:
SOLUTION A: put crops classification results into "class", "class_id" and "confidence" fields of detectionsSOLUTION B: grab classification results into list of values (list of class names, following the order, maybe letting people configure what to extract - class names / confidences etc)SOLUTION C: generalisedSOLUTION B- step to transform each cls result to extract property, step to aggregate properties into lists based on dimensionality, step with expressionImplemented
SOLUTION Aas I find it most elegantTwo bugs fixed in this PR:
Noneelements which will be filtered out if that's the wish of block)List any dependencies that are required for this change.
Type of change
Please delete options that are not relevant.
How has this change been tested, please provide a testcase or example of how you tested the change?
Any specific deployment considerations
For example, documentation changes, usability, usage/costs, secrets, etc.
Docs