DuplexTransferPixelViewIterator() iterates over three pixel views in parallel and calls your transfer method for each scanline of the view. The source and duplex pixel region is not confined to the image canvas-- that is you can include negative offsets or widths or heights that exceed the image dimension. However, the destination pixel view is confined to the image canvas-- that is no negative offsets or widths or heights that exceed the image dimension are permitted.

Use this pragma:

#pragma omp critical

to define a section of code in your callback transfer method that must be executed by a single thread at a time.

GetPixelViewIterator() iterates over the pixel view in parallel and calls your get method for each scanline of the view. The pixel region is not confined to the image canvas-- that is you can include negative offsets or widths or heights that exceed the image dimension. Any updates to the pixels in your callback are ignored.

Use this pragma:

#pragma omp critical

to define a section of code in your callback get method that must be executed by a single thread at a time.

MagickClipPathImage() clips along the named paths from the 8BIM profile, if present. Later operations take effect inside the path. Id may be a number if preceded with #, to work on a numbered path, e.g., "#1" to use the first path.

DrawPopGraphicContext() destroys the current drawing wand and returns to the previously pushed drawing wand. Multiple drawing wands may exist. It is an error to attempt to pop more drawing wands than have been pushed, and it is proper form to pop all drawing wands which have been pushed.

DrawPushGraphicContext() clones the current drawing wand to create a new drawing wand. The original drawing wand(s) may be returned to by invoking PopDrawingWand(). The drawing wands are stored on a drawing wand stack. For every Pop there must have already been an equivalent Push.

MagickColorFloodfillImage() changes the color value of any pixel that matches target and is an immediate neighbor. If the method FillToBorderMethod is specified, the color value is changed for any neighbor pixel that does not match the bordercolor member of image.

By default target must match a particular pixel color exactly. However, in many cases two colors may differ by a small amount. The fuzz member of image defines how much tolerance is acceptable to consider two colors as the same. For example, set fuzz to 10 and the color red at intensities of 100 and 102 respectively are now interpreted as the same color for the purposes of the floodfill.

MagickGetImagePixels() extracts pixel data from an image and returns it to you. The method returns MagickTrue on success otherwise MagickFalse if an error is encountered. The data is returned as char, short int, int, ssize_t, float, or double in the order specified by map.

Suppose you want to extract the first scanline of a 640x480 image as character data in red-green-blue order:

Define the data type of the pixels. Float and double types are expected to be normalized [0..1] otherwise [0..QuantumRange]. Choose from these types: CharPixel, DoublePixel, FloatPixel, IntegerPixel, LongPixel, QuantumPixel, or ShortPixel.

pixels

This array of values contain the pixel components as defined by map and type. You must preallocate this array where the expected length varies depending on the values of width, height, map, and type.

MagickMatteFloodfillImage() changes the transparency value of any pixel that matches target and is an immediate neighbor. If the method FillToBorderMethod is specified, the transparency value is changed for any neighbor pixel that does not match the bordercolor member of image.

the level of transparency: 1.0 is fully opaque and 0.0 is fully transparent.

fuzz

By default target must match a particular pixel color exactly. However, in many cases two colors may differ by a small amount. The fuzz member of image defines how much tolerance is acceptable to consider two colors as the same. For example, set fuzz to 10 and the color red at intensities of 100 and 102 respectively are now interpreted as the same color for the purposes of the floodfill.

By default target must match a particular pixel color exactly. However, in many cases two colors may differ by a small amount. The fuzz member of image defines how much tolerance is acceptable to consider two colors as the same. For example, set fuzz to 10 and the color red at intensities of 100 and 102 respectively are now interpreted as the same color for the purposes of the floodfill.

MagickPaintFloodfillImage() changes the color value of any pixel that matches target and is an immediate neighbor. If the method FillToBorderMethod is specified, the color value is changed for any neighbor pixel that does not match the bordercolor member of image.

By default target must match a particular pixel color exactly. However, in many cases two colors may differ by a small amount. The fuzz member of image defines how much tolerance is acceptable to consider two colors as the same. For example, set fuzz to 10 and the color red at intensities of 100 and 102 respectively are now interpreted as the same color for the purposes of the floodfill.

By default target must match a particular pixel color exactly. However, in many cases two colors may differ by a small amount. The fuzz member of image defines how much tolerance is acceptable to consider two colors as the same. For example, set fuzz to 10 and the color red at intensities of 100 and 102 respectively are now interpreted as the same color for the purposes of the floodfill.

the level of transparency: 1.0 is fully opaque and 0.0 is fully transparent.

fuzz

By default target must match a particular pixel color exactly. However, in many cases two colors may differ by a small amount. The fuzz member of image defines how much tolerance is acceptable to consider two colors as the same. For example, set fuzz to 10 and the color red at intensities of 100 and 102 respectively are now interpreted as the same color for the purposes of the floodfill.

MagickRecolorImage() apply color transformation to an image. The method permits saturation changes, hue rotation, luminance to alpha, and various other effects. Although variable-sized transformation matrices can be used, typically one uses a 5x5 matrix for an RGBA image and a 6x6 for CMYKA (or RGBA with offsets). The matrix is similar to those used by Adobe Flash except offsets are in column 6 rather than 5 (in support of CMYKA images) and offsets are normalized (divide Flash offset by 255).

MagickReduceNoiseImage() smooths the contours of an image while still preserving edge information. The algorithm works by replacing each pixel with its neighbor closest in value. A neighbor is defined by radius. Use a radius of 0 and ReduceNoise() selects a suitable radius for you.

the level of transparency: 1.0 is fully opaque and 0.0 is fully transparent.

fuzz

By default target must match a particular pixel color exactly. However, in many cases two colors may differ by a small amount. The fuzz member of image defines how much tolerance is acceptable to consider two colors as the same. For example, set fuzz to 10 and the color red at intensities of 100 and 102 respectively are now interpreted as the same color for the purposes of the floodfill.

MagickSetImagePixels() accepts pixel datand stores it in the image at the location you specify. The method returns MagickFalse on success otherwise MagickTrue if an error is encountered. The pixel data can be either char, short int, int, ssize_t, float, or double in the order specified by map.

Suppose your want to upload the first scanline of a 640x480 image from character data in red-green-blue order:

Define the data type of the pixels. Float and double types are expected to be normalized [0..1] otherwise [0..QuantumRange]. Choose from these types: CharPixel, ShortPixel, IntegerPixel, LongPixel, FloatPixel, or DoublePixel.

pixels

This array of values contain the pixel components as defined by map and type. You must preallocate this array where the expected length varies depending on the values of width, height, map, and type.

SetPixelViewIterator() iterates over the pixel view in parallel and calls your set method for each scanline of the view. The pixel region is confined to the image canvas-- that is no negative offsets or widths or heights that exceed the image dimension. The pixels are initiallly undefined and any settings you make in the callback method are automagically synced back to your image.

Use this pragma:

#pragma omp critical

to define a section of code in your callback set method that must be executed by a single thread at a time.

TransferPixelViewIterator() iterates over two pixel views in parallel and calls your transfer method for each scanline of the view. The source pixel region is not confined to the image canvas-- that is you can include negative offsets or widths or heights that exceed the image dimension. However, the destination pixel view is confined to the image canvas-- that is no negative offsets or widths or heights that exceed the image dimension are permitted.

Use this pragma:

#pragma omp critical

to define a section of code in your callback transfer method that must be executed by a single thread at a time.

UpdatePixelViewIterator() iterates over the pixel view in parallel and calls your update method for each scanline of the view. The pixel region is confined to the image canvas-- that is no negative offsets or widths or heights that exceed the image dimension are permitted. Updates to pixels in your callback are automagically synced back to the image.

Use this pragma:

#pragma omp critical

to define a section of code in your callback update method that must be executed by a single thread at a time.