The libvips enums¶

This module contains the various libvips enums as Python classes.

Enums values are represented in pyvips as strings. These classes contain the valid strings for each enum.

class pyvips.enums.BandFormat[source]¶

BandFormat.

The format used for each band element.

Each corresponds to a native C type for the current machine. For example, #VIPS_FORMAT_USHORT is <type>unsigned short</type>.

NOTSET¶

invalid setting

Type: str

UCHAR¶

unsigned char format

Type: str

CHAR¶

char format

Type: str

USHORT¶

unsigned short format

Type: str

SHORT¶

short format

Type: str

UINT¶

unsigned int format

Type: str

INT¶

int format

Type: str

FLOAT¶

float format

Type: str

COMPLEX¶

complex (two floats) format

Type: str

DOUBLE¶

double float format

Type: str

DPCOMPLEX¶

double complex (two double) format

Type: str

class pyvips.enums.BlendMode[source]¶

BlendMode.

The various Porter-Duff and PDF blend modes. See vips_composite(), for example.

The Cairo docs have a nice explanation of all the blend modes:

https://www.cairographics.org/operators

The non-separable modes are not implemented.

CLEAR¶

where the second object is drawn, the first is removed

Type: str

SOURCE¶

the second object is drawn as if nothing were below

Type: str

OVER¶

the image shows what you would expect if you held two semi-transparent slides on top of each other

Type: str

IN¶

the first object is removed completely, the second is only drawn where the first was

Type: str

OUT¶

the second is drawn only where the first isn’t

Type: str

ATOP¶

this leaves the first object mostly intact, but mixes both objects in the overlapping area

Type: str

DEST¶

leaves the first object untouched, the second is discarded completely

Type: str

DEST_OVER¶

like OVER, but swaps the arguments

Type: str

DEST_IN¶

like IN, but swaps the arguments

Type: str

DEST_OUT¶

like OUT, but swaps the arguments

Type: str

DEST_ATOP¶

like ATOP, but swaps the arguments

Type: str

XOR¶

something like a difference operator

Type: str

ADD¶

a bit like adding the two images

Type: str

SATURATE¶

a bit like the darker of the two

Type: str

MULTIPLY¶

at least as dark as the darker of the two inputs

Type: str

SCREEN¶

at least as light as the lighter of the inputs

Type: str

OVERLAY¶

multiplies or screens colors, depending on the lightness

Type: str

DARKEN¶

the darker of each component

Type: str

LIGHTEN¶

the lighter of each component

Type: str

COLOUR_DODGE¶

brighten first by a factor second

Type: str

COLOUR_BURN¶

darken first by a factor of second

Type: str

HARD_LIGHT¶

multiply or screen, depending on lightness

Type: str

SOFT_LIGHT¶

darken or lighten, depending on lightness

Type: str

DIFFERENCE¶

difference of the two

Type: str

EXCLUSION¶

somewhat like DIFFERENCE, but lower-contrast

Type: str

class pyvips.enums.Coding[source]¶

Coding.

How pixels are coded.

Normally, pixels are uncoded and can be manipulated as you would expect. However some file formats code pixels for compression, and sometimes it’s useful to be able to manipulate images in the coded format.

The gaps in the numbering are historical and must be maintained. Allocate new numbers from the end.

NONE¶

pixels are not coded

Type: str

LABQ¶

pixels encode 3 float CIELAB values as 4 uchar

Type: str

RAD¶

pixels encode 3 float RGB as 4 uchar (Radiance coding)

Type: str

class pyvips.enums.Interpretation[source]¶

Interpretation.

How the values in an image should be interpreted. For example, a three-band float image of type #VIPS_INTERPRETATION_LAB should have its pixels interpreted as coordinates in CIE Lab space.

RGB and sRGB are treated in the same way. Use the colourspace functions if you want some other behaviour.

The gaps in numbering are historical and must be maintained. Allocate new numbers from the end.

MULTIBAND¶

generic many-band image

Type: str

B_W¶

some kind of single-band image

Type: str

HISTOGRAM¶

a 1D image, eg. histogram or lookup table

Type: str

XYZ¶

the first three bands are CIE XYZ

Type: str

LAB¶

pixels are in CIE Lab space

Type: str

CMYK¶

the first four bands are in CMYK space

Type: str

LABQ¶

implies #VIPS_CODING_LABQ

Type: str

RGB¶

generic RGB space

Type: str

CMC¶

a uniform colourspace based on CMC(1:1)

Type: str

LCH¶

pixels are in CIE LCh space

Type: str

LABS¶

CIE LAB coded as three signed 16-bit values

Type: str

SRGB¶

pixels are sRGB

Type: str

YXY¶

pixels are CIE Yxy

Type: str

FOURIER¶

image is in fourier space

Type: str

RGB16¶

generic 16-bit RGB

Type: str

GREY16¶

generic 16-bit mono

Type: str

MATRIX¶

a matrix

Type: str

SCRGB¶

pixels are scRGB

Type: str

HSV¶

pixels are HSV

Type: str

class pyvips.enums.DemandStyle[source]¶

DemandStyle.

See vips_image_pipelinev(). Operations can hint to the VIPS image IO system about the kind of demand geometry they prefer.

These demand styles are given below in order of increasing restrictiveness. When demanding output from a pipeline, vips_image_generate() will use the most restrictive of the styles requested by the operations in the pipeline.

#VIPS_DEMAND_STYLE_THINSTRIP — This operation would like to output strips the width of the image and a few pels high. This is option suitable for point-to-point operations, such as those in the arithmetic package.

This option is only efficient for cases where each output pel depends upon the pel in the corresponding position in the input image.

#VIPS_DEMAND_STYLE_FATSTRIP — This operation would like to output strips the width of the image and as high as possible. This option is suitable for area operations which do not violently transform coordinates, such as vips_conv().

#VIPS_DEMAND_STYLE_SMALLTILE — This is the most general demand format. Output is demanded in small (around 100x100 pel) sections. This style works reasonably efficiently, even for bizzare operations like 45 degree rotate.

#VIPS_DEMAND_STYLE_ANY — This image is not being demand-read from a disc file (even indirectly) so any demand style is OK. It’s used for things like vips_black() where the pixels are calculated.