Deepomatic Platform
v2.3.9
Search
⌃K

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.