Deepomatic step library
Here is the list of all the steps that are available by default in the Deepomatic library and the syntax that allows to use them.
An inference step lets you use any model stored on the Deepomatic platform (especially all models trained on the Deepomatic platform) and execute an inference (neural network) on the regions given as inputs.
Inference step
steps:
- name: my inference step
type: Inference
inputs:
- image_input
args:
model_id: 12345
concepts:
- my objects
A region can be an entire image or bounding boxes from a previous detection neural network.
The
model_id
allows you to specify the model you wish to use. Check your model library on the Deepomatic platform to find the id of the model you want to use.When writing a workflow, you only refer to a model via its id, and not to a model version (see here for the difference between a model and a model version).
You must make sure that the model ids that you specify in your workflow have all been trained in the same organisation on the Deepomatic platform. When publishing the application, you need to use credentials from the same organisation.
The
concepts
is a name given to the output of the step and that you need when you want to use this output in other steps. There can be only one concept in the arguments of an Inference step.A multi inference step lets you use any model stored on the Deepomatic platform and execute inferences on many inputs, each input being a list of regions. The exact same inference is made on all inputs.
Multi inference step
steps:
- name: my multi inference step
type: MultipleInference
inputs:
- image_input_type_1
- image_input_type_2
args:
model_id: 12345
concepts:
- items 0
- items 1
Each input can be an image corresponding to an entry, or a list of regions corresponding to the output of a detection neural network.
model_id
and concepts
are exactly the same as the Inference step.The PredictionRouter step divides the input regions and redirects a subset of regions to another step according to the concepts predicted by your model in a previous inference step.
The order in which you write the steps in your workflow file does not matter. The execution graph is reconstructed at runtime based on the inputs and outputs of each step.
PredictionRouter step
steps:
- name: items_router
type: PredictionRouter
inputs:
- detector
args:
routing_name: items
routing_values:
- my_concept_1
- concept_2
- my_super_concept_3
This step doesn't necessarily follows an inference step (or a multi inference step) but there must have been one previously in the execution of the workflow to guarantee its coherence.
- The
routing_name
corresponds to theconcept
name of the inference step preceding the current step. - The
routing_values
must be coherent with the concept names that your model has been trained on. A PredictionRouter step is then only compatible with a specific set of models. - The last argument
top_prediction
is optional and lets you filter even more the regions generated by a preceding inference step, by using only the top prediction when relevant. By default,top_prediction
isFalse
. This argument is particularly useful for tagging or classification models, for which the model generates a prediction for all predicted concepts.
To use the output of a PredictionRouter step as input for another step, here is the syntax that you must use:
PredictionRouter step - Use output as input in another step
steps:
- name: detector
type: Inference
inputs:
- image_input
args:
models_id: 23456
concepts:
- items
- name: items_router
type: PredictionRouter
inputs:
- detector
args:
routing_name: items
routing_values:
- my_concept_1
- concept_2
- my_super_concept_3
top_prediction: False
- name: item_classification
type: Inference
inputs:
- items_router:2
args:
model_id: 54321
concepts:
- concept_2 type
In the above example, regions are created with the
detector
step. The items_router
step then creates branches for the different categories of items detected. Finally, for one of those categories, concept_2
, the bounding boxes are sent to another model to determine the type of concept_2.The RegionCounter step gives you the capacity to count the input regions. It creates a new workflow concept (named after the
concept_name
argument) with the resulting value in the default region of the corresponding entry (it assumes that all provided regions have the same entry).RegionCounter step
steps:
- name: item_counter
type: RegionCounter
inputs:
- item_detector
args:
concept_name: item_count
concept_names_to_count: [item] # Optional
This step accepts a list of regions as inputs (output of another node - generally an inference step on a detection model).
concept_name
: name of the concept with which the value is stored in the default region of the corresponding entryconcept_name_to_count
: a region is counted (once) if at least one of its concept has a name included inconcept_name_to_count
. If no concept names are provided, counts all the regions.
The PredictionCounter step gives you the capacity to count predictions within the input regions. It creates a new workflow concept (named after
concept_name
) with the resulting value in the default region of the corresponding entry (it assumes that all provided regions have the same entry).RegionCounter step
steps:
- name: item_counter
type: PredictionCounter
inputs:
- item_detector
args:
concept_name: item_count
concept_names_to_count: [item]
label_names_to_count: [my_nice_item] # Optional
This step accepts a list of regions as inputs (output of another node - generally an inference step on a detection model).
concept_name
: name of the concept with which the value is stored in the default region of the corresponding entry
It filters (i.e. counts only) the predictions on:
- the concept name of the predictions. Must be included in
concept_names_to_count
- the label names in the predictions. The predictions should at least have one of its label names included in
label_names_to_count
. If no label is provided, counts all the predictions.
ComparisonOperator
evaluates a comparison operator taking 2 input concepts and returns a concept with the result.ComparisonOperator step
steps:
- name: op
type: ComparisonOperator
inputs:
- item_counter
- expected_count
args:
concept_name: "different"
concept_names_of_operands:
- item_count
- expected_count
operator: "!="
The inputs correspond either to the name of the step that generated the value to use for the comparison, or to the name of an entry when the value to use is directly provided via an entry.
concept_name
: name of the concept with which the resulting value is stored in the default region of the first given entry (always a Boolean)concept_names_of_operands
: name of the concepts with which the values are stored. Each entry has a concept in the associated default region that has the same name as the entry to directly access the valueoperator
: an option from the list below"<"
- lower than"<="
- lower or equal"=="
- equal"!="
- not equal">"
- above">="
- above or equal
LogicalOperator
evaluates a logical operator taking 2 input concepts and returns a concept with the result.LogicalOperator step
steps:
- name: op_1
type: LogicalOperator
inputs:
- op_2
- op_3
args:
concept_name: "different_and_present"
concept_names_of_operands:
- different
- present
operator: "and"
The inputs correspond either to the name of the step that generated the value to use for the comparison, or to the name of an entry when the value to use is directly provided via an entry.
concept_name
: name of the concept with which the resulting value is stored in the default region of the first given entry (always a Boolean)concept_names_of_operands
: name of the concepts with which the values are stored. Each entry has a concept in the associated default region that has the same name as the entry to directly access the valueoperator
: an option from the list below"and"
or"&&"
- AND"or"
or"||"
- OR"not"
or"!"
- NOT"nand"
- NAND (False if all input values are False)"nor"
- NOR (True if all input values are False)
NegationOperator
negates the boolean concept provided in the given region.NegationOperator step
steps:
- name: op_1
type: NegationOperator
inputs:
- step_with_boolean_input
args:
concept_name: "the_boolean_value_i_need"
concept_name_to_negate: "initial_boolean_value"
The inputs correspond either to the name of the step that generated the value to use for the comparison, or to the name of an entry when the value to use is directly provided via an entry.
This step is not compatible with broadcast: it will only process the first region in the input list and ignore the others.
concept_name
: name of the concept with which the resulting value is stored in the default region of the given entry (always a Boolean)concept_names_to_negate
: name of the concept with which the Boolean value to negate is stored.
MathOperator
evaluates a mathematical operator taking two input concepts and returns a concept with the result.MathOperator step
steps:
- name: op_1
type: MathOperator
inputs:
- my_first_entry
- item_counter
args:
concept_name: "item_and_entry"
concept_names_of_operands:
- my_first_entry
- item_count
operator: "+"
The inputs correspond either to the name of the step that generated the value to use for the operation, or to the name of an entry when the value to use is directly provided via an entry.
concept_name
: name of the concept with which the resulting value is stored in the default region of the first given entry (always a Number)concept_names_of_operands
: name of the concepts with which the values are stored. Each entry has a concept in the associated default region that has the same name as the entry to directly access the valueoperator
: an option from the list below"+"
- add"-"
- substract"*"
- multiply"/"
- true div"**"
OR"pow"
- power"%"
- modulo
HasLabel
steps indicate if a label is predicted in the given region. It creates a concept named after concept_name
in the input region with value True
if a label was found, False
otherwise.HasLabel step
steps:
- name: check_item
type: HasLabel
inputs:
- detector
args:
concept_name: item_present
label_names_to_find: [thing]
concept_names_to_find: [stuff] # Optional
This step accepts a list of regions as inputs (output of another node - generally an inference step).
This step is not compatible with broadcast: it will only process the first region in the input list and ignore the others.
concept_name
: name of the concept with which the value is stored in the default region of the corresponding entry- It retrieves the predictions of the given region and checks if at least one of the labels is included in
label_names_to_find
. - If
concept_names_to_find
is provided, the predictions whose concept name is not included in concept_names_to_find are ignored.
HasWorkflowConcept
steps indicate if a workflow concept exists in the given region. It creates a concept named after concept_name
in the input region with value True
if a label was found, False
otherwise.HasWorkflowConcept step
steps:
- name: check_item
type: HasWorkflowConcept
inputs:
- detector
args:
concept_name: item_present
concept_names_to_find: [stuff]
This step accepts a list of regions as inputs (output of another node - generally an inference step).
This step is not compatible with broadcast: it will only process the first region in the input list and ignore the others.
concept_name
: name of the concept with which the value is stored in the default region of the corresponding entry- If
concept_names_to_find
is provided, the predictions whose concept name is not included in concept_names_to_find are ignored.
FlowController
stops a branch execution according to a concept value. It retrieves the concept named after concept_name
in the first input region. If its value is different from expected_value
, the branch execution is stopped. Otherwise, an input is forwarded (the second one if there are two inputs, the only one if there is only one).FlowController step
steps:
- name: Context PMZ router
type: FlowController
inputs:
- context
- image_input
args:
concept_name: context
expected_value: PMZ
The step accepts one or two inputs.
- The condition will be enforced using the first input (by checking the value of the
concept_name
concept) - The second input is optional and will be the one that is forwarded if the check is passed.
concept_name
: indicates the name of the concept to look for in the first input.expected_value
: value that is expected to enforce the condition for the concept that is retrieved.
Last modified 1mo ago