Back to Libvips

Libvips Arithmetic

doc/libvips-arithmetic.md

8.18.27.8 KB
Original Source

Title: Operator index > By section > Arithmetic

<!-- libvips/arithmetic -->

These operations perform pixel arithmetic, that is, they perform an arithmetic operation, such as addition, on every pixel in an image or a pair of images. All (except in a few cases noted below) will work with images of any type or any mixture of types, of any size and of any number of bands.

For binary operations, if the number of bands differs, one of the images must have one band. In this case, an n-band image is formed from the one-band image by joining n copies of the one-band image together, and then the two n-band images are operated upon.

In the same way, for operations that take an array constant, such as [[email protected]_const], you can mix single-element arrays or single-band images freely.

Arithmetic operations try to preserve precision by increasing the number of bits in the output image when necessary. Generally, this follows the ANSI C conventions for type promotion, so multiplying two [[email protected]] images together, for example, produces a [[email protected]] image, and taking the [[email protected]] of a [[email protected]] image produces [[email protected]] image.

After processing, use [[email protected]] and friends to take then format back down again.[[email protected]_uchar], for example, will cast any image down to 8-bit unsigned.

Images have an interpretation: a meaning for the pixel values. With [[email protected]], for example, the first three bands will be interpreted (for example, by a saver like [[email protected]]) as R, G and B, with values in 0 - 255, and any fourth band will be interpreted as an alpha channel.

After arithmetic, you may wish to change the interpretation (for example to save as 16-bit PNG). Use [[email protected]] to change the interpretation without changing pixels.

For binary arithmetic operations, type promotion occurs in two stages. First, the two input images are cast up to the smallest common format, that is, the type with the smallest range that can represent the full range of both inputs. This conversion can be represented as a table:

Smallest common format

@in2/@in1ucharcharushortshortuintintfloatdoublecomplexdouble complex
ucharushortshortushortshortuintintfloatdoublecomplexdouble complex
charshortshortshortshortintintfloatdoublecomplexdouble complex
ushortushortshortushortshortuintintfloatdoublecomplexdouble complex
shortshortshortshortshortintintfloatdoublecomplexdouble complex
uintuintintuintintuintintfloatdoublecomplexdouble complex
intintintintintintintfloatdoublecomplexdouble complex
floatfloatfloatfloatfloatfloatfloatfloatdoublecomplexdouble complex
doubledoubledoubledoubledoubledoubledoubledoubledoubledouble complexdouble complex
complexcomplexcomplexcomplexcomplexcomplexcomplexcomplexdouble complexcomplexdouble complex
double complexdouble complexdouble complexdouble complexdouble complexdouble complexdouble complexdouble complexdouble complexdouble complexdouble complex

In the second stage, the operation is performed between the two identical types to form the output. The details vary between operations, but generally the principle is that the output type should be large enough to represent the whole range of possible values, except that int never becomes float.

Functions

Enumerations

  • [enum@OperationMath]
  • [enum@OperationMath2]
  • [enum@OperationRound]
  • [enum@OperationRelational]
  • [enum@OperationBoolean]
  • [enum@OperationComplex]
  • [enum@OperationComplex2]
  • [enum@OperationComplexget]