user: Describe Compositing Space from the Blender manual or Python API, including usage steps and snippets.

assistant: ### Image Domain

The compositor is designed in such a way as to allow compositing in an infinite compositing space.
Consequently, images are not only represented by their size, but also by their transformation in
that space, much like 3D objects have transformations. An identity transformation represents an
image that is centered in space. The rectangular area occupied by an image in that space as defined
by its transformation and size is called the *Domain* of the image. The figure below demonstrates
the domains of two example images.

[image reference removed]

The domains of two example images are illustrated on the compositing space. One of the images is
centered in space and the other is scaled down and translated such that it lies in the upper
right quadrant of the space. Notice that both images have similar sizes in pixels, yet their
apparent sizes are different.

Images can be transformed using nodes like the [Transform](types/transform/transform.xhtml#bpy-types-compositornodetransform),
[Translate](types/transform/translate.xhtml#bpy-types-compositornodetranslate), and [Rotate](types/transform/rotate.xhtml#bpy-types-compositornoderotate) nodes.

### Operation Domain

[Compositor Nodes](index.xhtml#compositor-nodes) operate on a specific rectangular area of the compositing
space called the *Operation Domain*. The nodes only consider the area of the input images that
overlap the operation domain and ignores the rest of the images. If an input image doesn’t
completely overlap the operation domain, the rest of the operation domain for that input will be
assumed to be a zero value, a zero vector, or a transparent zero color depending on the type.

For instance, the figure below illustrates a case where the operation domain of a node is the large
blue area and the domain of an input image is the small red area. In that case, the input image
doesn’t completely overlap the operation domain, so the rest of the blue area for that input image
is assumed to be zero.

[image reference removed]

An example case where the operation domain of a node is shown in blue and the domain of an input
image is shown in red. Since the input image doesn’t completely cover the operation domain of the
node, the rest of the blue area for that input image is assumed to be zero.

The previous illustration is a representation of a real world example where one uses the [Alpha
Over](types/color/alpha_over.xhtml#bpy-types-compositornodealphaover) node to overlay a small logo on an image, as shown in the
figure below. In that case, the operation domain covers the entirety of the viewport — as will later
be demonstrated, but the logo covers only a small area of it, so the rest of the area is assumed to
be a zero transparent color, which is convenient for the use case.

[image reference removed]

A real world example where the Alpha Over node is used to over a small logo on an image. The logo
only covers a small area of the operation domain, which is the whole viewport in this case, so
the rest of the area is assumed to be a zero transparent color.

#### Interpolation

If an input image to a node is not perfectly aligned with the operation domain of the node or have a
different size in pixels, the node would typically need to do a process called Interpolation, where
the input image is read at the exact positions of the pixels of the operation domain. This can be
done using different interpolation methods, including Nearest-Neighbor, Bilinear, and Bicubic
interpolations. Those interpolation methods are demonstrated in the following
[Wikipedia gallery](https://en.wikipedia.org/wiki/Comparison_gallery_of_image_scaling_algorithms).
Transformation nodes like the [Transform](types/transform/transform.xhtml#bpy-types-compositornodetransform) and [Rotate](types/transform/rotate.xhtml#bpy-types-compositornoderotate) nodes include an interpolation option to set how they prefer their
output image to be read and interpolated.

#### Determining Operation Domain

The question remains on how nodes determine their operation domain. Different node types can have
different mechanisms for determining their operation domain. But generally, three classes of nodes
exist when it comes to the mechanism of determining the operation domain, each of which is presented
in one of the following sections.

##### Input Nodes

The operation domain of input nodes like the [Image node](types/input/image.xhtml#bpy-types-compositornodeimage) is a
domain with an identity transformation and the same size as their outputs, so for the *Image* node,
the operation domain will be the domain whose size is the size of the image and whose transformation
is an identity one.

##### Output Nodes

The operation domain of output nodes like the [Viewer node](types/output/viewer.xhtml#bpy-types-compositornodeviewer) is
a domain with an identity transformation and the same size as the final compositor output. For
[viewport compositing](../editors/3dview/display/shading.xhtml#bpy-types-view3dshading-use-compositor), that size would be the viewport size, and for
final render compositing, that size would be the scene render size.

##### Other Nodes

Unless stated otherwise in their respective documentation pages, all other nodes use the following
mechanism. One of the inputs of the nodes is designated as the *Domain Input* of the node, and the
operation domain of the node is identical to the domain of that designated input. For many nodes,
the domain input can be intuitively identified as the main input of the node, for instance, the
domain input for the [Filter node](types/filter/filter.xhtml#bpy-types-compositornodefilter) is the *Image* input. But
there are some caveats to note, which requires a deeper understanding of the mechanism.

Each input in the node has the so called *Domain Priority* property, the operation domain of the
node is the domain of the non single value input with the highest domain priority. So for instance,
the [Filter node](types/filter/filter.xhtml#bpy-types-compositornodefilter) has two inputs, the domain priority of the
*Image* input is higher than that of the *Factor* input, and there are four possible configurations:

- Both the *Image* and factor inputs are connected to images. In this case, the *Image* input is the
  domain input because it has the highest priority and is connected to an image.
- The *Image* input is connected to an image, but the *Factor* input isn’t. In this case, the
  *Image* input is the domain input because it is the only input connected to an image regardless
  of its priority.
- The *Image* input is not connected to an image but the *Factor* input is. In this case, the
  *Factor* input is the domain input because it is the only input connected to an image regardless
  of its priority.
- Neither the *Image* nor the *Factor* inputs are connected to images, in this case, there isn’t
  a domain input because the node is evaluated on single values.

#### Considerations

The aforementioned mechanism for determining the operation domain has a number of consequences that
needs to be considered as they might be undesirable, each of which is presented in one of the
following sections.

##### Clipping

The output of nodes will be intuitively clipped to the operation domain, or rather, the domain of
the domain input. For instance, if the *Foreground* input is bigger than the *Background* input in
the [Alpha Over node](types/color/alpha_over.xhtml#bpy-types-compositornodealphaover), the output will be clipped to the
*Background* input because it is the domain input, as shown in the following figure.

[image reference removed]

The *Foreground* input is bigger than the *Background* input in the *Alpha Over* node, so the
output is intuitively clipped to the *Background* input because it is the domain input.

The [Alpha Over node](types/color/alpha_over.xhtml#bpy-types-compositornodealphaover) currently does not support changing
the domain priority for its inputs, so as a workaround,
one can use a [Mix node](types/color/mix_color.xhtml) to achieved the desired behavior,
noting that the first *Image* input in the *Mix* node has the highest domain priority,
as shown in the following figure.

[image reference removed]

Working around the clipping behavior of the *Alpha Over* node using a Mix node, noting that the
first *Image* input in the *Mix* node has the highest domain priority