<img src='../assets/aktive-logo-128.png' style='float:right;'>

||||
|---|---|---|
|[Project ↗](../../README.md)|[Documentation ↗](../index.md)|[Developer Index ↗](index.md)|


# <a name='top'></a> Operator Specifications DSL

|Syntax				|Notes							|
|:---				|:---							|
|`operator NAME SPEC`		|Create a single named operator				|
|`operator NAMELIST SPEC`	|Create multiple named operators			|
|`operator VARLIST OPLIST SPEC`	|As before, with additional configuration information	|

The command names and specifies one or more (related) image processing
operators, using a suite of subordinate commands within its `spec`.

|Argument	|Notes							|
|:---		|:---							|
|`NAME`		|Name of operator, suitable as Tcl command name		|
|`NAMELIST`	|List of operator names sharing the `spec`		|
|`VARLIST`	|List of variable names to template the `spec` with	|
|`OPLIST`	|List of operator names and variable values (1)		|
|`SPEC`		|Specification, a Tcl script   	     			|

  1. The `oplist` starts with an operator name followed by values for
     all the variables in the `varlist`, followed by more sections of
     the same structure.

The `spec` has access to all specified variables (if any) as both
variables and template blocks.

## <a name='cmds'></a> Specification commands

[Up ↑](#top)

The commands used within specifications fall into 4 categories.
These are

  - [Generally usable](#general)
  - [Usable in and declaring a C-level operator](#clang)
  - [Usable in and declaring a Tcl-level operator](#tcllang)
  - [Usable in and declaring an external operator](#external)

Note that the commands for a specific kind of operator cannot be mixed
with the commands for a different kind of operator. The first use of a
command requiring a specific kind locks the operator to that kind.

### <a name='general'></a> General

[Up ↑](#cmds)

The generally usable commands are mainly focused on support, inputs,
parameters, documentation, and examples.

|Command			|Description	|
|:---				|:---		|
|[def](opspec.md#def)		|Define a named local text block	|
|[import](opspec.md#import)	|Import definitions into the operator	|
|[import?](opspec.md#import)	|See above, ignore a missing file	|
|[op](#cmd-op)			|Access to parts of the operator name	|

|Command			|Description	|
|:---				|:---		|
|[\<type\>](#cmd-param)		|Declaration of a required parameter	|
|[\<type\>?](#cmd-param)	|Declaration of an optional parameter	|
|[\<type\>...](#cmd-param)	|Declaration of a variadic parameter	|
|||
|[input](#cmd-input)		|Declaration of image input    		|
|[input...](#cmd-input)		|Declaration of variadic image input	|

|Command			|Description	|
|:---				|:---		|
|[example](#cmd-example)	|Define an operator example		|
|[note](#cmd-note)		|Operator description / documentation	|
|[section](#cmd-section)	|Documentation section for operator	|
|[strict](#cmd-strict)		|Strictness information	   		|

### <a name='clang'></a> C-level Operators

[Up ↑](#cmds)

The C-level operator commands further divide into

  - [Highlevel](#highlevel)
  - [Image result](#image)
  - [Non-image result](#nonimage)
  - [No result](#none)



#### <a name='highlevel'></a> Highlevel

[Up ↑](#clang)

|Command			|Description			|
|:---				|:---				|
|[cached](#cmd-cached)		|Declare a caching operator	|

The highlevel commands on the one hand extremely simplify the creation
of the operators of their kind, yet on the other hand are very
specialized and completely unusable outside of their domain.

Currently we have only a single such command, for the construction of
operators using a row- or column cache.

#### <a name='image'></a> Image result

[Up ↑](#clang)

|Command			|Description				|
|:---				|:---					|
|[blit](#cmd-blit)		|Blitter definition			|


|[pixels](#cmd-pixels)		|Operator implementation, runtime	|
|[simplify](#cmd-simplify)	|Declare simplification rule		|
|[state](#cmd-state)		|Operator implementation, definition	|

#### <a name='nonimage'></a> Non-image result

[Up ↑](#clang)

|Command			|Description		|
|:---				|:---			|
|[blit](#cmd-blit)		|Blitter definition	|


|[return](#cmd-return)		|Operator implementation|

#### <a name='none'></a> No result

[Up ↑](#clang)

|Command			|Description		|
|:---				|:---			|
|[blit](#cmd-blit)		|Blitter definition	|


|[void](#cmd-void)		|Operator implementation|

### <a name='tcllang'></a> Tcl-level Operators

[Up ↑](#cmds)

|Command			|Description		|

|Command			|Description	|
|:---				|:---		|
|[external!](#cmd-ext)		|Marker		|

External operators are not something outside of AKTIVE.

Here it refers to commands which are implemented outside of the
operator framework, i.e. as regular Tcl commands, be it in C or Tcl.

The specification only serves to pull them into the command hierarchy
set up by the generator, and as a means of providing both
documentation and examples.

## Command details

[Up ↑](#cmds)

### <a name='cmd-param'></a> Parameters

[Up ↑](#general)

|Syntax					|Notes		|
|:---					|---		|
|`<type> NAME [WORD...]`		|Required	|
|`<type>? DEFAULT NAME [WORD...]`	|Optional	|
|`<type...> NAME [WORD...]`		|Variadic	|

Each type defined via [type](opspec.md#cmd-type) provides these
commands to declare parameters of this type for operators.

Required parameters have to be set when constructing an instance of
the operator.  Optional parameter can be left unset, and take on their
default value.

The `default` can actually be any valid Tcl command. Any such command
has access to the values of all required parameters.

__BEWARE:__ When a variadic parameter is declared no further
parameters of any kind can be declared, nor image inputs.

It is not possible to declare a parameter if a variadic image input
was declared before. In other words, it is not possible to use any
kind of parameter together with variadic inputs.

When instantiating an operator with a variadic parameter this
parameter has to be specified last, as it takes all the arguments
after it for its value.

### <a name='cmd-input'></a> Image inputs

[Up ↑](#image)

|Syntax				|
|:---				|
|`input [NAME] [WORD...]`	|
|`input...`			|

The commands declare the presence of one or more image inputs for the
operator. The first form declares only a single image input, with
optional name and description. Multiple uses of this form accumulate.

The second form declares the presence of an arbitrary number of input
images, i.e. zero or more.

__BEWARE:__ After using the second form it is not possible declare
more image inputs, nor parameters. Conversely, declaration of any
parameter prevents the use of this form.

This is due the ordering of arguments expected by the generated
operator construction commands (inputs before parameters).

Regular image inputs without a user-specified name default to either
the name `src` (in case of a single input), or `srcN` with N an
integer counting up from `0` (in case of several inputs). When the
name `src` is assigned, a missing description is filled too, using a
default of `Source image`.

Variadic image inputs are given the name `args`, and a generic
description of `Source images`.

### <a name='cmd-example'></a> Examples

[Up ↑](#general)

|Syntax			|
|:---			|
|`example [SPEC]`	|

The command parses the spec and arranges for the execution of the
example and the capture of its results, for use in the generated
documentation.

Ignoring leading and trailing white space each line of the spec
defines a command to run as part of the example. A command may refer
to the results of a preceding command, using placeholders of the form
`@N`, with `N` counting from `1`. These results are used as they are,
their modifiers do not count for the command chain.

If the command in the __last line__, and only that line has no command
specified, just arguments (i.e. the word `aktive` is present), then
the operator under definition is used as the command.

Each line may contain display modifiers after the command, separated
from the command by a vertical bar, i.e. `|`. Modifiers come in the
form of options and formatting commands, the latter separated by
semicolons, i.e. `;`.

The accepted options are

|Option		|Meaning							|
|:---		|:---								|
|`-text`	|Command result is text						|
|`-matrix`	|Show result (image) as matrix (default 4 digits of precision)	|
|`-int`		|Modifier to `-matrix`, show as integers			|
|`-full`	|Modifier to `-matrix`, show with full double precision		|
|`-label TEXT`	|Override the default description of the command with `text`	|

If neither `-text` nor `-matrix` are specified then the result is
shown as image.

The set of currently supported commands, both to generate data and to
format result for display are available in
[support/esupport.tcl](/file?ci=trunk&name=support/esupport.tcl).

Some examples:

  - [affine](/file?ci=trunk&name=etc/transformer/structure/transform.tcl&ln=43-48)
  - [geometry](/file?ci=trunk&name=etc/accessor/attributes.tcl&ln=94-101)
  - [indexed](/file?ci=trunk&name=etc/generator/virtual/indexed.tcl&ln=9-10)
  - [labeled regions](/file?ci=trunk&name=etc/accessor/cc.tcl&ln=12-47)
  - [sdf](/file?ci=trunk&name=etc/generator/virtual/sdf.tcl&ln=103-106)
  - [wobble](/file?ci=trunk&name=etc/transformer/filter/effects.tcl&ln=12-15)

### <a name='cmd-note'></a> Documentation

[Up ↑](#general)

|Syntax			|
|:---			|
|`note [WORD...]`	|

The command records a piece of documentation for the operator.
The words are treated as the words of one or more sentences.

Multiple uses of the command accumulate.

The recorded text is placed into markdown files as is.  Use of
markdown syntax is allowed.

The custom `<!xref: ...>` instruction can be used to insert
cross-references into the text.

Currently two kinds of reference targets are supported.

  1. Full operators names of the forms

     - `aktive ...`,
     - `./aktive ...`, and
     - `../aktive ...`

     with the elements separated by space.

     As example, the operator `foo::bar` is referenced by

     - `<!xref: aktive foo bar>`,
     - `<!xref: ./aktive foo bar>`, or
     - `<!xref: ../aktive foo bar>`

     These references link to the operator documentation from
     different locations in the package documentation.  The
     specification is linked from the documentation.

     As example see [aktive query geometry](../ref/accessor_geometry.md#query_geometry).

     - Use `aktive ...` from within operator documentation.
     - Use `./aktive ...` from toplevel documentation.
     - Use `../aktive ...` from second level documentation (like here).

     All forms set a proper relative link.

  2. Source references of the form `src ...` where `...` is the label
     given to a source code location via the `!xref-mark` designator.
     See for example the [affine location marker](/file?ci=trunk&name=etc/transformer/structure/transform.tcl&ln=42).

     As example, the source code location labeled as `fox lair` is
     referenced by `<!xref: src fox lair>`.

References to unknown locations and operators are not touched.
As an example of that see the above examples.

### <a name='cmd-op'></a> Operator name access

[Up ↑](#general)

|Syntax			|
|:---			|
|`op -> VARNAME...`	|

The command splits the operator name into pieces (at the `::`
separators) and assigns them to the named variables / text blocks
([def](opspec.md#cmd-def) is used internally).

This makes the information available for templating of the operator.

### <a name='cmd-section'></a> Documentation section

[Up ↑](#general)

|Syntax			|
|:---			|
|`section WORD...`	|

The command declares the documentation section the operator belongs to.

The sequence of words describes the section hierarchy from the roots
down.

Each use of the command replaces the data from all preceding uses in
the same operator.

### <a name='cmd-strict'></a> Strictness

[Up ↑](#general)

|Syntax				|
|:---				|
|`strict IDS [WORD...]`	|

The command declares in what inputs the operator is strict in.

If the operator is not strict this command can be left out.

The words after the list of argument ids are additional text added to
the documentation, after the note about the strictness.

|Argument	|Notes							|
|:---		|:---							|
|`IDS`		|List of the strict arguments, or special values	|

Examples for `IDS`:

|Name	|Description							|
|:---	|---								|
|`KIND`	|What to cache, either `row` or `column`			|
|`LABEL`|Identifying label inserted into code, comments, and tracing	|
|`FUNC`	|Name of C function to call to fill the cache (1)		|

  1. The function has to have the signature of
     [aktive_iveccache_fill](/file?ci=trunk&name=runtime/iveccache.h&ln=74)
     or be cast-able to it.

     The `context` argument is assumed to be a
     [aktive_ivcache_context*](/file?ci=trunk&name=runtime/iveccache.h&ln=77-84),
     instead of the `void*` in the base signature.

     The argument type may be changed should no operators appear which
     do not fit into the currently emitted code.

Options:

|Name		|Description								|
|:---		|---									|
|`--`		|Stop option processing							|
|`-cdata CD`	|C expression delivering address of client data to use with `FUNC` (1)	|
|`-rsize RS`	|C expression delivering the operator's result size (2)			|
|`-fields F`	|C code fragment declaring additional runtime state fields		|
|`-setup S`	|C code fragment initializing the additional fields			|
|`-cleanup C`	|C code fragment scrubbing the additional fields			|

  1. The expression defines the value for the `.client` field of the
     internal `aktive_ivcache_context*` structure.

     For example, for row/column histograms this is a pointer to the
     `aktive_histogram` structure used by the `aktive_histogram_fill`
     function to collect interim results.

  1. This is for the result size along the uncached axis. As an
     example, for row histograms it is `param->bins` which becomes the
     width of the result.

Examples

 - [cumulation](/file?ci=trunk&name=etc/transformer/statistics/cumulation.tcl&ln=36)
 - [histogram](/file?ci=trunk&name=etc/transformer/statistics/histogram.tcl&ln=234-244)
 - [profile](/file?ci=trunk&name=etc/transformer/statistics/profile.tcl&ln=34)

### <a name='cmd-blit'></a> Blitting

[Up ↑](#image)

|Syntax			|
|:---			|
|`blit NAME SCANS FUNC`	|

__TODO FILL__



























### <a name='cmd-pixels'></a> Pixel fetching

[Up ↑](#image)

|Syntax						|
|:---						|
|`pixels [OPTION...] FETCH [(KEY VAL)...]`	|

__TODO FILL__ C code fragment context

Arguments:
|Name		|Description					|
|:---		|---						|
|`FETCH`	|C code fragment to serve a pixel request	|

Options:

|Name			|Description							|
|:---			|---								|
|`-fields FIELDS`	|C code fragment declaring the operator's runtime state fields	|
|`-setup SETUP`		|C code fragment initializing the runtime state fields		|
|`-cleanup CLEANUP`	|C code fragment scrubbing the runtime state fields		|

The optional additional `KEY`/`VAL` arguments are used to template all
fragments, i.e. `fetch` and the option values, beyond what is already
done based on the existing global and local text blocks.

#### Fields

The `FIELDS` fragment is inserted into a C structure definition and
has to follow its syntax. It declares fields to hold image state
necessary for and during the execution of image pipelines.

#### Setup

The `SETUP` fragment is called during startup of image pipelines and
has to initialize the pipline state structure from the image
structure.  It can be assured of the presence of the following C
definitions in its context:

|Name		|Content				|
|:---		|:---					|
|`istate`	|Image state fields, if any		|
|`param`	|Image parameters, if any		|
|`srcs`		|Image inputs as region vector, if any	|
|`state`	|Pixel state structure to initialize	|

All definitions are pointers.

#### Cleanup

The `CLEANUP` fragment is called during teardown of image pipelines
and is responsible for releasing any heap-allocated pixel state.  It
can be assured of the presence of the following C definitions in its
context:

|Name		|Content			|
|:---		|:---				|
|`state`	|Pixel state structure to clear	|

All definitions are pointers.

#### Fetch

The `FETCH` fragment implements the calculation of image pixels based
on the requested area. It can be assured of the presence of the
following C definitions in its context:

|Name		|Content				|
|:---		|:---					|
|`block`	|Block to store the fetched pixels into	|
|`dst`		|Rectangle, area of the block to write	|
|`idomain`	|Image domain, a geometry		|
|`istate`	|Image state fields, if any		|
|`param`	|Image parameters, if any		|
|`request`	|Rectangle, area of the image to fetch	|

All definitions are pointers.

### <a name='cmd-simplify'></a> Simplification rules

[Up ↑](#image)

|Syntax			|
|:---			|
|`simplify WORD....`	|

__TODO FILL__ sub language

### <a name='cmd-state'></a> State definitions

[Up ↑](#image)

|Syntax					|
|:---					|
|`state [OPTION...] [(KEY VAL)...]`	|



Options:

|Name			|Description								|
|:---			|---									|
|`-fields FIELDS`	|C code fragment declaring the operator's definition state fields	|
|`-setup SETUP`		|C code fragment initializing the definition state fields		|
|`-cleanup CLEANUP`	|C code fragment scrubbing the definition state fields			|

The optional additional `KEY`/`VAL` arguments are used to template all
fragments, i.e. all option values, beyond what is already done based
on the existing global and local text blocks.

#### Fields

The `FIELDS` fragment is inserted into a C structure definition and
has to follow its syntax. It declares fields to hold image state
shared across and generally static during the execution of image
pipelines.

Non-static fields require locking when accessed from image pipelines.

#### Setup

The `SETUP` fragment is called during construction of images and has
to initialize the image state structure.  It can be assured of the
presence of the following C definitions in its context:

|Name		|Content				|
|:---		|:---					|
|`domain`	|Image domain, a geometry, to initialize|
|`param`	|Image parameters, if any, to read	|
|`state`	|Image state structure to initialize	|

All definitions are pointers.

#### Cleanup

The `CLEANUP` fragment is called during destruction of images and is
responsible for releasing any heap-allocated image state.  It can be
assured of the presence of the following C definitions in its context:

|Name		|Content			|
|:---		|:---				|
|`state`	|Image state structure to clear	|

All definitions are pointers.

### <a name='cmd-return'></a> Non-image results

[Up ↑](#nonimage)

|Syntax					|
|:---					|
|`return TYPE SCRIPT [(KEY VAL)...]`	|

Implements an operator returning a value of the specified `type`,
which is not an image. Operators of this kind, taking one or more
inputs and returning a non-image result are generally called
`Accessors`.

The type has to have been declared before, via the
[type](opspec.md#cmd-type) command.

The `script` is a C code fragment implementing the operator.  The
fragment has to conform to the rules for a C function body, for usage
as such.

__Attention__: If the last statement in the fragment (i.e. the last
line) does not contain a `return` statement then the system will add a
`return` in front of the content of that line, under the assumption
that this line contains the statement or expression computing the
value to deliver.

In other words, instead of having to write
`return int { return foo(); }`
with its visual duplication of the `return` it is possible to write
`return int { foo(); }`
and the required `return` statement is added automatically.

The fragment has access to the following C variables:

|Name		|Type		|Content							|
|---		|---		|---								|
|`ip`		|Tcl_Interp*	|Interpreter receiving the result				|
|`<name>`	|aktive_image	|Where `name` references an explicitly named input image	|
|`src`		|aktive_image	|Default for unnamed input. Single input image. Optional	|
|`src<N>`	|aktive_image	|Ditto. One of serveral input images, `N` counting up from 0	|
|`param->P`	|		|Declared parameter `P`	       	   	       	    		|

Whether `src` or `src0`, `src1`, ... are accessible depends on the
number of input images and are used only for those which are not
explicitly named. `src` is made available in case of a single input
image. `src0`, etc. are made available if there is more than one input
image.

__BEWARE__: There is currently no support for a dynamic number of
input images, i.e. `input...` Or if there is (I may have forgotten)
then it is untested.

The optional additional `KEY`/`VAL` arguments after the C code
fragment are used to template that fragment, beyond what is already
done based on the existing global and local text blocks.

### <a name='cmd-void'></a> No results

[Up ↑](#none)

|Syntax				|
|:---				|
|`void SCRIPT [(KEY VAL)...]`	|

Implements an operator returning nothing. Operators of this kind,
taking one or more inputs without returning any result are generally
called `Sinks`. Any result they have is delivered through some kind of
side-effect. For example by writing to a channel or file.

The command is effectively a shorthand for `return void SCRIPT ...`.

The one difference in treatment is that the system will not
auto-insert a `return` command here.

### <a name='cmd-body'></a> Tcl implementations

[Up ↑](#tcllang)

|Syntax				|
|:---				|
|`body SCRIPT [(KEY VAL)...]`	|

Implements an operator in Tcl.

The `script` is a Tcl code fragment implementing the operator.  The
fragment has to conform to the rules for a Tcl procedure body, for
usage as such.

The fragment has access to the following Tcl variables:

|Name		|Content							|
|---		|---								|
|`<name>`	|Where `name` references an explicitly named input image	|
|`src`		|Default for unnamed inputs. Single input image. Optional	|
|`src<N>`	|Ditto. One of serveral input images, `N` counting up from 0	|
|`P`		|Declared parameter `P`						|

Whether `src` or `src0`, `src1`, ... are accessible depends on the
number of input images and are used only for those which are not
explicitly named. `src` is made available in case of a single input
image. `src0`, etc. are made available if there is more than one input
image.

__BEWARE__: There is currently no support for a dynamic number of
input images, i.e. `input...` Or if there is (I may have forgotten)
then it is untested.

The optional additional `KEY`/`VAL` arguments after the Tcl code
fragment are used to template that fragment, beyond what is already
done based on the existing global and local text blocks.

### <a name='cmd-pass'></a> Pass markers

[Up ↑](#tcllang)

|Syntax			|
|:---			|
|`pass CMDWORD...`	|

A prefix command which marks all parameters declared during the
execution of the prefixed command as pass-through.

All such parameters are added to the template block `passthrough`.
The block contains a Tcl code fragment alternating parameter names and
variable access for that parameter.

As example, for a pass through parameter `foo` the block will contain
`... foo $foo ...`.

This simplifies the use of parameters declared through a shared code
block without the body of the operator having to be aware of the exact
set of parameters.

See for example

  - [draw pass](/file?ci=trunk&name=etc/generator/virtual/draw.tcl&ln=77)
  - [wobble pass](/file?ci=trunk&name=etc/transformer/filter/effects.tcl&ln=25)

<img src='../assets/aktive-logo-128.png' style='float:right;'>

||||
|---|---|---|
|[Project ↗](../../README.md)|[Documentation ↗](../index.md)|[Developer Index ↗](index.md)|


# <a name='top'></a> Operator Specifications DSL

## Overview

AKTIVE uses a Tcl-based domain-specific language to simplify the
specification of image processing operators.

The implementation of the DSL translates the specifications into the

  - Boilerplate code (C and Tcl) embedding and linking the operator
    into AKTIVE's runtime framework.

  - Operator documentation in Markdown, including examples
    (and underlying example Tcl code).

## Implementation

[Up ↑](#top)

Files:

  - [Main](/file?ci=trunk&name=support/dsl.tcl)
  - [Reader Frontend](/file?ci=trunk&name=support/reader.tcl)
  - [Writer Backend](/file?ci=trunk&name=support/writer.tcl)
  - [Example Support](/file?ci=trunk&name=support/esupport.tcl)
  - [Blitter Generator](/file?ci=trunk&name=support/blit.tcl)
  - [Reductor Generator](/file?ci=trunk&name=support/reduce.tcl)
  - [Struct Parsing](/file?ci=trunk&name=support/structs.tcl)
  - [Xref Parsing](/file?ci=trunk&name=support/xref.tcl)

## <a name='cmds'></a> Main commands

[Up ↑](#top)

|Command			|Description								|
|:---				|:---									|
|[def](#cmd-def)		|Defines a sharable text block. Global or local to an operator		|
|[import](#cmd-import)		|Imports definitions from the specified file, fail for a mising file	|
|[import?](#cmd-import)		|See above, except it ignores a missing file   	      	       		|
|[nyi](#cmd-nyi)		|Disables the command it is a prefix of					|
|[operator](#cmd-operator)	|Defines a (set of) operators  	      	       	     			|
|[type](#cmd-type)		|Defines a type for use with parameters and results			|
|[vector](#cmd-vector)		|Declares which types require vector/slice support			|

### <a name='cmd-def'></a> `def`

[Up ↑](#cmds)

|Syntax					|
|:---					|
|`def NAME TEXT [(KEY VALUE)...]`	|

The command creates a named sharable block of `text`, either at global
level or local to an operator specification. The created block is
usable wherever templating is performed.

The command further creates a Tcl variable of the same `name` in the
calling scope, also containing the `text`.

__Note__ that this command applies templating to the `text` before it
is saved.  In other words, the definition of a block can reference
blocks defined before it.

Furthermore the optional set of `key` and `value` arguments serves as
map of ultra-local placeholders to use in the templating.

### <a name='cmd-import'></a> `import`, `import?`

[Up ↑](#cmds)

|Syntax		|
|:---		|
|`import PATH`	|
|`import? PATH`	|

Both commands read the referenced file and execute the commands in the
context of the import. This can be global or within an operator
specification.

The `import?` variant ignores a missing `PATH`, whereas `import` will
throw an error in that case.

### <a name='cmd-nyi'></a> `nyi`

[Up ↑](#cmds)

|Syntax			|
|:---			|
|`nyi [WORD...]`	|

The command is a prefix command whose use disables the command it is
made a prefix of.

The name stands for __not yet implemented__.

### <a name='cmd-operator'></a> `operator`

[Up ↑](#cmds)

|Syntax				|
|:---				|
|`operator NAME SPEC`		|
|`operator NAMELIST SPEC`	|
|`operator VARLIST OPLIST SPEC`	|

The command names and specifies one or more (related) image processing
operators, using a suite of subordinate commands within its `spec`.

The [full details](opspec-op.md) abbout operator arguments and
subordinate commands are found in [their own page](opspec-op.md).


### <a name='cmd-type'></a> `type`

[Up ↑](#cmds)

|Syntax				|
|:---				|
|`type ID CRITCL C CONVERTER`	|

The command declares a type the DSL can use for operator parameters and
results.

__Note__ that types have to be declared before their use.

The core types needed by AKTIVE's runtime framework itself are
declared in

  - [etc/runtime.tcl](/file?ci=trunk&name=etc/runtime.tcl)

Arguments:

|Name		|Description									|
|:---		|---										|
|`ID`		|Name the type is identified by when used in `vector` and `operator` commands	|
|`CRITCL`	|The associated Critcl type. `-` defaults to the `ID`				|
|`C`		|The associated C type. `-` defaults to the `CRITCL` name			|
|`CONVERTER`	|C code fragment to convert a C value of the type into a Tcl_Obj		|

Converter notes:

  - The fragment has to return a `Tcl_Obj*` value.

  - The fragment expects to have access to a C variable `value`
    holding a pointer to the C value to convert

### <a name='cmd-vector'></a> `vector`

[Up ↑](#cmds)

|Syntax			|
|:---			|
|`vector [NAME...]`	|

The command declares that we need vector/slice support for the named types.


In other words, it arranges for the generator to emit C code that
provides the types and functions for the management of __dynamic arrays__
for values of this type.

|Input|Description|
|:---|:---|
|src|Source image|

---
### [↑](#top) <a name='query_inputs'></a> aktive query inputs

Syntax: __aktive query inputs__ src [[→ definition](../../../../file?ci=trunk&ln=171&name=etc/accessor/attributes.tcl)]

Returns a list of the input's inputs.

For an image without inputs the result is the empty list.

|Input|Description|
|:---|:---|
|src|Source image|

---
### [↑](#top) <a name='query_params'></a> aktive query params

Syntax: __aktive query params__ src [[→ definition](../../../../file?ci=trunk&ln=196&name=etc/accessor/attributes.tcl)]

Returns a dictionary containing the input's parameters.

For an image without parameters the result is the empty dictionary.

|Input|Description|
|:---|:---|

    <td valign='top'>&nbsp;width 32 height 32 depth 1 first 0.0 last 1.0</td></tr>
</table>


---
### [↑](#top) <a name='query_setup'></a> aktive query setup

Syntax: __aktive query setup__ src [[→ definition](../../../../file?ci=trunk&ln=221&name=etc/accessor/attributes.tcl)]

Returns a dictionary containing the input's setup.

This includes type, geometry, and parameters, if any. The inputs however are excluded.

|Input|Description|
|:---|:---|

 - [aktive query ymax](#query_ymax)

## Operators

---
### [↑](#top) <a name='query_depth'></a> aktive query depth

Syntax: __aktive query depth__ src [[→ definition](../../../../file?ci=trunk&ln=141&name=etc/accessor/attributes.tcl)]

Returns the input's depth.

|Input|Description|
|:---|:---|
|src|Source image|

    <td valign='top'>&nbsp;0 0 32 32 1</td></tr>
</table>


---
### [↑](#top) <a name='query_height'></a> aktive query height

Syntax: __aktive query height__ src [[→ definition](../../../../file?ci=trunk&ln=141&name=etc/accessor/attributes.tcl)]

Returns the input's height.

|Input|Description|
|:---|:---|
|src|Source image|

    <td valign='top'>&nbsp;0 0</td></tr>
</table>


---
### [↑](#top) <a name='query_pitch'></a> aktive query pitch

Syntax: __aktive query pitch__ src [[→ definition](../../../../file?ci=trunk&ln=141&name=etc/accessor/attributes.tcl)]

Returns the input's pitch, the number of values in a row, i.e. width times depth.

|Input|Description|
|:---|:---|
|src|Source image|

    <td valign='top'>&nbsp;32</td></tr>
</table>


---
### [↑](#top) <a name='query_pixels'></a> aktive query pixels

Syntax: __aktive query pixels__ src [[→ definition](../../../../file?ci=trunk&ln=141&name=etc/accessor/attributes.tcl)]

Returns the input's number of pixels.

|Input|Description|
|:---|:---|
|src|Source image|

    <td valign='top'>&nbsp;1024</td></tr>
</table>


---
### [↑](#top) <a name='query_size'></a> aktive query size

Syntax: __aktive query size__ src [[→ definition](../../../../file?ci=trunk&ln=141&name=etc/accessor/attributes.tcl)]

Returns the input's size, i.e. the number of pixels times depth.

|Input|Description|
|:---|:---|
|src|Source image|

    <td valign='top'>&nbsp;1024</td></tr>
</table>


---
### [↑](#top) <a name='query_width'></a> aktive query width

Syntax: __aktive query width__ src [[→ definition](../../../../file?ci=trunk&ln=141&name=etc/accessor/attributes.tcl)]

Returns the input's width.

|Input|Description|
|:---|:---|
|src|Source image|

    <td valign='top'>&nbsp;32</td></tr>
</table>


---
### [↑](#top) <a name='query_x'></a> aktive query x

Syntax: __aktive query x__ src [[→ definition](../../../../file?ci=trunk&ln=113&name=etc/accessor/attributes.tcl)]

Returns the input's x location.

|Input|Description|
|:---|:---|
|src|Source image|

    <td valign='top'>&nbsp;0</td></tr>
</table>


---
### [↑](#top) <a name='query_xmax'></a> aktive query xmax

Syntax: __aktive query xmax__ src [[→ definition](../../../../file?ci=trunk&ln=113&name=etc/accessor/attributes.tcl)]

Returns the input's maximum x location.

|Input|Description|
|:---|:---|
|src|Source image|

    <td valign='top'>&nbsp;31</td></tr>
</table>


---
### [↑](#top) <a name='query_y'></a> aktive query y

Syntax: __aktive query y__ src [[→ definition](../../../../file?ci=trunk&ln=113&name=etc/accessor/attributes.tcl)]

Returns the input's y location.

|Input|Description|
|:---|:---|
|src|Source image|

    <td valign='top'>&nbsp;0</td></tr>
</table>


---
### [↑](#top) <a name='query_ymax'></a> aktive query ymax

Syntax: __aktive query ymax__ src [[→ definition](../../../../file?ci=trunk&ln=113&name=etc/accessor/attributes.tcl)]

Returns the input's maximum y location.

|Input|Description|
|:---|:---|
|src|Source image|

|:---|:---|:---|:---|
|src|image||Input queried|
|args|str...||Dict command arguments, except for dict value or variable.|

---
### [↑](#top) <a name='query_meta'></a> aktive query meta

Syntax: __aktive query meta__ src [[→ definition](../../../../file?ci=trunk&ln=245&name=etc/accessor/attributes.tcl)]

Returns a dictionary containing the input's meta data.

|Input|Description|
|:---|:---|
|src|Source image|

 - [aktive query values](#query_values)

## Operators

---
### [↑](#top) <a name='query_value_around'></a> aktive query value around

Syntax: __aktive query value around__ src ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=320&name=etc/accessor/attributes.tcl)]

Returns the input's pixel values for the region around the specified 2D point, within the manhattan `radius`.

The result is __not__ an image.

Beware that the coordinate domain is `0..width|height`, regardless of image location.

|x|int||Physical x-coordinate of the pixel to query|
|y|int||Physical y-coordinate of the pixel to query|
|radius|uint|1|Region radius, defaults to 1, i.e. a 3x3 region.|

---
### [↑](#top) <a name='query_value_at'></a> aktive query value at

Syntax: __aktive query value at__ src (param value)... [[→ definition](../../../../file?ci=trunk&ln=290&name=etc/accessor/attributes.tcl)]

Returns the input's pixel value(s) at the given 2D point.

The result is __not__ an image. It is a list of floating point numbers for a multi-band input, and a single floating point number otherwise.

Beware that the coordinate domain is `0..width|height`, regardless of image location.

    <td valign='top'>&nbsp;0.6666666666666666</td></tr>
</table>


---
### [↑](#top) <a name='query_values'></a> aktive query values

Syntax: __aktive query values__ src [[→ definition](../../../../file?ci=trunk&ln=264&name=etc/accessor/attributes.tcl)]

Returns a list containing the input's pixel values.

The values are provided in row-major order.

The list has length "[aktive query size](accessor_geometry.md#query_size) \<src\>".

---
### [↑](#top) <a name='warp_wobble'></a> aktive warp wobble

Syntax: __aktive warp wobble__  ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=5&name=etc/generator/virtual/warp/wobble.tcl)]

Returns the origin map for a wobble effect around the specified __center__, with base __amplitude__, __frequency__, __chirp__, and __attenuation__ powers.

The result is designed to be usable with the [aktive op warp bicubic](transform_structure_warp.md#op_warp_bicubic) operation and its relatives.

At the technical level the result is a 2-band image where each pixel declares its origin position.

The effect modulates the distance from the center based on the formula `sin (radius^chirp * frequency) * amplitude / (1+radius)^attenuation`, where `radius` is the original distance.

All parameters, including the center are optional.





|Parameter|Type|Default|Description|
|:---|:---|:---|:---|
|width|uint||Width of the returned image|
|height|uint||Height of the returned image|
|center|point|{}|Center of the wobble, relative to the origin. Defaults to the image center.|
|amplitude|double|500|Base amplitude of the displacement.|
|frequency|double|2|Base wave frequency.|

 - [aktive op draw triangle on](#op_draw_triangle_on)

## Operators

---
### [↑](#top) <a name='op_draw_box_rounded_on'></a> aktive op draw box-rounded on

Syntax: __aktive op draw box-rounded on__ background ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=96&name=etc/generator/virtual/draw.tcl)]

Returns an image where a box is drawn on the input image.

Beware, the location and size of the box are independent of image location and dimensions. The operator is perfectly fine computing the SDF of a box located completely outside of the image domain.

See also [aktive image draw box-rounded](generator_virtual_drawing.md#image_draw_box_rounded) and [aktive image sdf box-rounded](generator_virtual_sdf.md#image_sdf_box_rounded).

    <br>geometry(0 0 380 250 3)</td></tr>
</table>


---
### [↑](#top) <a name='op_draw_box_on'></a> aktive op draw box on

Syntax: __aktive op draw box on__ background ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=96&name=etc/generator/virtual/draw.tcl)]

Returns an image where a box is drawn on the input image.

Beware, the location and size of the box are independent of image location and dimensions. The operator is perfectly fine computing the SDF of a box located completely outside of the image domain.

See also [aktive image draw box](generator_virtual_drawing.md#image_draw_box) and [aktive image sdf box](generator_virtual_sdf.md#image_sdf_box).

    <br>geometry(0 0 380 250 3)</td></tr>
</table>


---
### [↑](#top) <a name='op_draw_circle_on'></a> aktive op draw circle on

Syntax: __aktive op draw circle on__ background ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=96&name=etc/generator/virtual/draw.tcl)]

Returns an image where a circle is drawn on the input image.

Beware, the location and size of the circle are independent of image location and dimensions. The operator is perfectly fine computing the SDF of a circle located completely outside of the image domain.

See also [aktive image draw circle](generator_virtual_drawing.md#image_draw_circle) and [aktive image sdf circle](generator_virtual_sdf.md#image_sdf_circle).

    <br>geometry(0 0 380 250 3)</td></tr>
</table>


---
### [↑](#top) <a name='op_draw_circles_on'></a> aktive op draw circles on

Syntax: __aktive op draw circles on__ background ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=96&name=etc/generator/virtual/draw.tcl)]

Returns an image where a set of circles is drawn on the input image.

Beware, the location and size of the set of circles are independent of image location and dimensions. The operator is perfectly fine computing the SDF of a set of circles located completely outside of the image domain.

See also [aktive image draw circles](generator_virtual_drawing.md#image_draw_circles) and [aktive image sdf circles](generator_virtual_sdf.md#image_sdf_circles).

    <br>geometry(0 0 380 250 3)</td></tr>
</table>


---
### [↑](#top) <a name='op_draw_line_on'></a> aktive op draw line on

Syntax: __aktive op draw line on__ background ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=96&name=etc/generator/virtual/draw.tcl)]

Returns an image where a line is drawn on the input image.

Beware, the location and size of the line are independent of image location and dimensions. The operator is perfectly fine computing the SDF of a line located completely outside of the image domain.

See also [aktive image draw line](generator_virtual_drawing.md#image_draw_line) and [aktive image sdf line](generator_virtual_sdf.md#image_sdf_line).

    <br>geometry(0 0 380 250 3)</td></tr>
</table>


---
### [↑](#top) <a name='op_draw_parallelogram_on'></a> aktive op draw parallelogram on

Syntax: __aktive op draw parallelogram on__ background ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=96&name=etc/generator/virtual/draw.tcl)]

Returns an image where a parallelogram is drawn on the input image.

Beware, the location and size of the parallelogram are independent of image location and dimensions. The operator is perfectly fine computing the SDF of a parallelogram located completely outside of the image domain.

See also [aktive image draw parallelogram](generator_virtual_drawing.md#image_draw_parallelogram) and [aktive image sdf parallelogram](generator_virtual_sdf.md#image_sdf_parallelogram).

    <br>geometry(0 0 380 250 3)</td></tr>
</table>


---
### [↑](#top) <a name='op_draw_polyline_on'></a> aktive op draw polyline on

Syntax: __aktive op draw polyline on__ background ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=96&name=etc/generator/virtual/draw.tcl)]

Returns an image where a set of lines is drawn on the input image.

Beware, the location and size of the set of lines are independent of image location and dimensions. The operator is perfectly fine computing the SDF of a set of lines located completely outside of the image domain.

See also [aktive image draw polyline](generator_virtual_drawing.md#image_draw_polyline) and [aktive image sdf polyline](generator_virtual_sdf.md#image_sdf_polyline).

    <br>geometry(0 0 380 250 3)</td></tr>
</table>


---
### [↑](#top) <a name='op_draw_rhombus_on'></a> aktive op draw rhombus on

Syntax: __aktive op draw rhombus on__ background ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=96&name=etc/generator/virtual/draw.tcl)]

Returns an image where a rhombus is drawn on the input image.

Beware, the location and size of the rhombus are independent of image location and dimensions. The operator is perfectly fine computing the SDF of a rhombus located completely outside of the image domain.

See also [aktive image draw rhombus](generator_virtual_drawing.md#image_draw_rhombus) and [aktive image sdf rhombus](generator_virtual_sdf.md#image_sdf_rhombus).

    <br>geometry(0 0 380 250 3)</td></tr>
</table>


---
### [↑](#top) <a name='op_draw_triangle_on'></a> aktive op draw triangle on

Syntax: __aktive op draw triangle on__ background ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=96&name=etc/generator/virtual/draw.tcl)]

Returns an image where a triangle is drawn on the input image.

Beware, the location and size of the triangle are independent of image location and dimensions. The operator is perfectly fine computing the SDF of a triangle located completely outside of the image domain.

See also [aktive image draw triangle](generator_virtual_drawing.md#image_draw_triangle) and [aktive image sdf triangle](generator_virtual_sdf.md#image_sdf_triangle).

 - [aktive effect wobble](#effect_wobble)

## Operators

---
### [↑](#top) <a name='effect_blur'></a> aktive effect blur

Syntax: __aktive effect blur__ src ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=219&name=etc/transformer/filter/effects.tcl)]

Returns blurred input, per the specified blur radius.

|Input|Description|
|:---|:---|
|src|Source image|

    <br>geometry(16 0 96 128 1)</td></tr>
</table>


---
### [↑](#top) <a name='effect_charcoal'></a> aktive effect charcoal

Syntax: __aktive effect charcoal__ src ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=264&name=etc/transformer/filter/effects.tcl)]

Returns a grey image with a charcoal-like sketch of the sRGB input.

|Input|Description|
|:---|:---|
|src|Source image|

    <br>geometry(0 0 380 250 1)</td></tr>
</table>


---
### [↑](#top) <a name='effect_emboss'></a> aktive effect emboss

Syntax: __aktive effect emboss__ src [[→ definition](../../../../file?ci=trunk&ln=183&name=etc/transformer/filter/effects.tcl)]

Returns embossed input.

|Input|Description|
|:---|:---|
|src|Source image|

    <br>geometry(1 1 126 126 1)</td></tr>
</table>


---
### [↑](#top) <a name='effect_jitter_gauss'></a> aktive effect jitter gauss

Syntax: __aktive effect jitter gauss__ src ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=141&name=etc/transformer/filter/effects.tcl)]

Returns the input with a jitter effect based on gaussian noise applied to it. Visually this looks like frosted glass.

The underlying operation is [aktive warp noise gauss](generator_virtual_warp.md#warp_noise_gauss).

|Input|Description|
|:---|:---|

    <br>geometry(0 0 380 250 3)</td></tr>
</table>


---
### [↑](#top) <a name='effect_jitter_uniform'></a> aktive effect jitter uniform

Syntax: __aktive effect jitter uniform__ src ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=99&name=etc/transformer/filter/effects.tcl)]

Returns the input with a jitter effect based on uniform noise applied to it. Visually this looks like frosted glass.

The underlying operation is [aktive warp noise uniform](generator_virtual_warp.md#warp_noise_uniform).

|Input|Description|
|:---|:---|

    <br>geometry(0 0 380 250 3)</td></tr>
</table>


---
### [↑](#top) <a name='effect_max_rgb'></a> aktive effect max-rgb

Syntax: __aktive effect max-rgb__ src [[→ definition](../../../../file?ci=trunk&ln=314&name=etc/transformer/filter/effects.tcl)]

Returns an image suppressing at each pixel of the input the bands not reaching the max of the bands at that location.

For a single-band input this is a no-op.

Despite the use of `rgb` in the operator name this operator works on all multi-band images, regardless of the exact number or their semantic interpretation.

    <br>geometry(0 0 380 250 3)</td></tr>
</table>


---
### [↑](#top) <a name='effect_min_rgb'></a> aktive effect min-rgb

Syntax: __aktive effect min-rgb__ src [[→ definition](../../../../file?ci=trunk&ln=314&name=etc/transformer/filter/effects.tcl)]

Returns an image suppressing at each pixel of the input the bands not falling to the min of the bands at that location.

For a single-band input this is a no-op.

Despite the use of `rgb` in the operator name this operator works on all multi-band images, regardless of the exact number or their semantic interpretation.

    <br>geometry(0 0 380 250 3)</td></tr>
</table>


---
### [↑](#top) <a name='effect_sharpen'></a> aktive effect sharpen

Syntax: __aktive effect sharpen__ src [[→ definition](../../../../file?ci=trunk&ln=202&name=etc/transformer/filter/effects.tcl)]

Returns sharpened input.

|Input|Description|
|:---|:---|
|src|Source image|

    <br>geometry(1 1 126 126 1)</td></tr>
</table>


---
### [↑](#top) <a name='effect_sketch'></a> aktive effect sketch

Syntax: __aktive effect sketch__ src [[→ definition](../../../../file?ci=trunk&ln=242&name=etc/transformer/filter/effects.tcl)]

Returns image with a general sketch of the input.

|Input|Description|
|:---|:---|
|src|Source image|

    <br>geometry(0 0 128 128 1)</td></tr>
</table>


---
### [↑](#top) <a name='effect_swirl'></a> aktive effect swirl

Syntax: __aktive effect swirl__ src ?(param value)...? [[→ definition](../../../../file?ci=trunk&ln=40&name=etc/transformer/filter/effects.tcl)]

Returns the input with a swirling effect applied to it.

This effect applies around the specified __center__, with fixed rotation __phi__, a base rotation __from__, and a __decay__ factor.

The rotation angle added to a pixel is given by `phi + from * exp(-radius * decay)`, where __radius__ is the distance of the pixel from the __center__. A large decay reduces the swirl at shorter radii. A decay of zero disables the decay.

|Input|Description|
|:---|:---|
|src|Source image|

|Parameter|Type|Default|Description|
|:---|:---|:---|:---|
|center|point|{}|Center of the wobble, relative to the origin. Defaults to the image center.|
|amplitude|double|500|Base amplitude of the displacement.|
|frequency|double|2|Base wave frequency.|
|chirp|double|0.5|Chirp (power) factor modulating the frequency.|
|attenuation|double|0.6|Power factor tweaking the base 1/x attenuation.|
|interpolate|str|bilinear|Interpolation method to use.|

#### <a name='effect_wobble__examples'></a> Examples

 - [aktive op sdf round](#op_sdf_round)

## Operators

---
### [↑](#top) <a name='op_sdf_2image_fit'></a> aktive op sdf 2image fit

Syntax: __aktive op sdf 2image fit__ src [[→ definition](../../../../file?ci=trunk&ln=297&name=etc/generator/virtual/sdf.tcl)]

Compresses the input SDF into the range 0..1 and returns the resulting grayscale image.

|Input|Description|
|:---|:---|
|src|Source image|

    <br>geometry(0 0 128 128 1)</td></tr></table></td></tr>
</table>


---
### [↑](#top) <a name='op_sdf_2image_pixelated'></a> aktive op sdf 2image pixelated

Syntax: __aktive op sdf 2image pixelated__ src [[→ definition](../../../../file?ci=trunk&ln=334&name=etc/generator/virtual/sdf.tcl)]

Converts the SDF into a black/white image with pixelated element borders.

|Input|Description|
|:---|:---|
|src|Source image|

    <br>geometry(0 0 128 128 1)</td></tr></table></td></tr>
</table>


---
### [↑](#top) <a name='op_sdf_2image_smooth'></a> aktive op sdf 2image smooth

Syntax: __aktive op sdf 2image smooth__ src [[→ definition](../../../../file?ci=trunk&ln=315&name=etc/generator/virtual/sdf.tcl)]

Converts the SDF into a grey-scale image with anti-aliased element borders.

|Input|Description|
|:---|:---|
|src|Source image|

    <br>geometry(0 0 128 128 1)</td></tr></table></td></tr>
</table>


---
### [↑](#top) <a name='op_sdf_outline'></a> aktive op sdf outline

Syntax: __aktive op sdf outline__ src [[→ definition](../../../../file?ci=trunk&ln=245&name=etc/generator/virtual/sdf.tcl)]

Replaces the input SDF with an outlined form, and returns the result.

This is implemented by taking the absolute of the input.

|Input|Description|
|:---|:---|

    <br>geometry(0 0 128 128 1)</td></tr></table></td></tr>
</table>


---
### [↑](#top) <a name='op_sdf_ring'></a> aktive op sdf ring

Syntax: __aktive op sdf ring__ src (param value)... [[→ definition](../../../../file?ci=trunk&ln=220&name=etc/generator/virtual/sdf.tcl)]

Combines outlining and rounding to replace the input SDF with an SDF tracing the border at some thickness and returns the result.

The result is annular, i.e. has a ring/onion-like structure.

Note that a thickness of zero devolves this operation to a plain outline.

    <br>geometry(0 0 128 128 1)</td></tr></table></td></tr>
</table>


---
### [↑](#top) <a name='op_sdf_round'></a> aktive op sdf round

Syntax: __aktive op sdf round__ src (param value)... [[→ definition](../../../../file?ci=trunk&ln=264&name=etc/generator/virtual/sdf.tcl)]

Replaces the input SDF with a more rounded form per the radius, and returns the result.

This is implemented by shifting the input SDF down by the radius.

For a radius > 0 this expands the SDF, making the encoded element rounder. A radius < 0 conversely shrinks the SDF.

 - [aktive op sdf xor-core](#op_sdf_xor_core)

## Operators

---
### [↑](#top) <a name='op_sdf_and'></a> aktive op sdf and

Syntax: __aktive op sdf and__ srcs... [[→ definition](../../../../file?ci=trunk&ln=137&name=etc/generator/virtual/sdf.tcl)]

Returns the intersection (`*`, `max`) of all input SDFs.

|Input|Description|
|:---|:---|
|args...|Source images|

    <br>geometry(0 0 128 128 1)</td></tr></table></td></tr>
</table>


---
### [↑](#top) <a name='op_sdf_or'></a> aktive op sdf or

Syntax: __aktive op sdf or__ srcs... [[→ definition](../../../../file?ci=trunk&ln=119&name=etc/generator/virtual/sdf.tcl)]

Returns the union (`+`, `min`) of all input SDFs.

|Input|Description|
|:---|:---|
|args...|Source images|

    <br>geometry(0 0 128 128 1)</td></tr></table></td></tr>
</table>


---
### [↑](#top) <a name='op_sdf_sub'></a> aktive op sdf sub

Syntax: __aktive op sdf sub__ a b [[→ definition](../../../../file?ci=trunk&ln=155&name=etc/generator/virtual/sdf.tcl)]

Returns the difference `A - B` of the two input SDFs. This is defined as `A * (not B)`.

|Input|Description|
|:---|:---|
|a|SDF A|
|b|SDF B|

    <br>geometry(0 0 128 128 1)</td></tr></table></td></tr>
</table>


---
### [↑](#top) <a name='op_sdf_xor'></a> aktive op sdf xor

Syntax: __aktive op sdf xor__ srcs... [[→ definition](../../../../file?ci=trunk&ln=176&name=etc/generator/virtual/sdf.tcl)]

Returns the symmetric difference of all input SDFs.

|Input|Description|
|:---|:---|
|args...|Source images|

    <br>geometry(0 0 128 128 1)</td></tr></table></td></tr>
</table>


---
### [↑](#top) <a name='op_sdf_xor_core'></a> aktive op sdf xor-core

Syntax: __aktive op sdf xor-core__ a b [[→ definition](../../../../file?ci=trunk&ln=196&name=etc/generator/virtual/sdf.tcl)]

Returns the symmetric difference of the two input SDFs. This is defined as `(A + B) - (A * B)`.

|Input|Description|
|:---|:---|
|a|SDF A|
|b|SDF B|

|Input|Description|
|:---|:---|
|src|Source image|

---
### [↑](#top) <a name='op_band_cumulative'></a> aktive op band cumulative

Syntax: __aktive op band cumulative__ src [[→ definition](../../../../file?ci=trunk&ln=41&name=etc/transformer/statistics/cumulation.tcl)]

Returns image with the input bands transformed into cumulative sums.

This means that each pixel in a band is the sum of the values in the bands before it, having the same row and column.

The result has the same geometry as the input. Only the contents change.