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.
Inference
Single Inference
Description
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.
YAML Schema
Inference step
    steps:
        - name: my inference step
          type: Inference
          inputs:
              - image_input
          args:
              model_id: 12345
              concepts:
                  - my objects
Inputs
A region can be an entire image or bounding boxes from a previous detection neural network.
Arguments
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.
Multi Inference
Description
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.
YAML Schema
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
Inputs
Each input can be an image corresponding to an entry, or a list of regions corresponding to the output of a detection neural network.
Arguments
model_id and concepts are exactly the same as the Inference step.
PredictionRouter
Description
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.
YAML Schema
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
Inputs
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.
Arguments
The routing_name corresponds to the concept 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_predictionis 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 is False. 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.
Counter
RegionCounter
Description
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).
YAML Schema
RegionCounter step
    steps:
        - name: item_counter
          type: RegionCounter
          inputs:
              - item_detector
          args:
              concept_name: item_count
              concept_names_to_count: [item] # Optional
              
Inputs
This step accepts a list of regions as inputs (output of another node - generally an inference step on a detection model).
Arguments
concept_name: name of the concept with which the value is stored in the default region of the corresponding entry
concept_name_to_count: a region is counted (once) if at least one of its concept has a name included in concept_name_to_count. If no concept names are provided, counts all the regions.
PredictionCounter
Description
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).
YAML Schema
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
Inputs
This step accepts a list of regions as inputs (output of another node - generally an inference step on a detection model).
Arguments
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.
Operator
Comparison operator
Description
ComparisonOperator evaluates a comparison operator taking 2 input concepts and returns a concept with the result.
YAML Schema
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: "!="
Inputs
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.
Arguments
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 value
operator: an option from the list below
 "<" - lower than
"<=" - lower or equal
"==" - equal
"!=" - not equal
">" - above
">=" - above or equal
Logical operator
Description
LogicalOperator evaluates a logical operator taking 2 input concepts and returns a concept with the result.
YAML Schema
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"
Inputs
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.
Arguments
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 value
operator: 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)
Negation operator
Description
NegationOperator negates the boolean concept provided in the given region.
YAML Schema
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"
Inputs
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.
Arguments
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.
Math operator
Description
MathOperator evaluates a mathematical operator taking two input concepts and returns a concept with the result.
YAML Schema
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: "+"
Inputs
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.
Arguments
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 value
operator: an option from the list below
 "+" - add
"-" - substract
"*" - multiply
"/" - true div
"**" OR "pow" - power
"%" - modulo
Check
Has label
Description
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.
YAML Schema
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
Inputs
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.
Arguments
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.
Has workflow concept
Description
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.
YAML Schema
HasWorkflowConcept step
    steps:
        - name: check_item
          type: HasWorkflowConcept
          inputs:
              - detector
          args:
              concept_name: item_present
              concept_names_to_find: [stuff]
Inputs
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.
Arguments
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.
Flow
FlowController
Description
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).
YAML Schema
FlowController step
    steps:
        - name: Context PMZ router
          type: FlowController
          inputs:
              - context
              - image_input
          args:
              concept_name: context
              expected_value: PMZ
Inputs
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.
Arguments
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.
Assembling workflows
Custom step
Last modified 2mo ago