Lines Matching full:channels
56 <p class="text-center"><a href="porting.php#imv7">ImageMagick Version 7</a> ? <a href="porting.php#hdri">High Dynamic Range Imaging</a> ? <a href="porting.php#channels">Pixel Channels</a> ? <a href="porting.php#alpha">Alpha</a> ? <a href="porting.php#grayscale">Grayscale</a> ? <a href="porting.php#mask">Masks</a> ? <a href="porting.php#core">MagickCore API</a> ? <a href="porting.php#headers">Header Files</a> ? <a href="porting.php#deprecate">Deprecated Features Removed</a> ? <a href="porting.php#cli">Command-line Interface</a> ? <a href="porting.php#summary">Version 7 Change Summary</a> </p>
58 <p class="lead magick-description">The design of ImageMagick is an evolutionary process, with the design and implementation efforts serving to influence and guide further progress in the other. With ImageMagick version 7 we aim to improve the design based on lessons learned from the version 6 implementation. ImageMagick was originally designed to display RGB images to an X Windows server. Over time we extended support to RGBA images and then to the CMYK and CMYKA image format. With ImageMagick version 7, we extend support to arbitrary colorspaces with an arbitrary number of pixel channels. Other design changes are in the works and we will document them here so be sure to revisit periodically.</p>
60 <p>To support variable pixel channels in the MagickCore API, pixel handling has changed when getting or setting the pixel channels. You can access channels as an array, <var>pixel[i]</var>, or use an accessor method such as GetPixelRed() or SetPixelRed(). There are some modest changes to the MagickCore and MagickWand API's. The Magick++ and PerlMagick API's have not changed and matches that of the ImageMagick version 6.</p>
81 <h2 class="magick-header"><a id="channels"></a>Pixel Channels</h2>
82 <p>A pixel is comprised of one or more color values, or <var>channels</var> (e.g. red pixel channel).</p>
83 <p>Prior versions of ImageMagick (4-6), support 4 to 5 pixel channels (RGBA or CMYKA). The first 4 channels are accessed with the PixelPacket data structure. The structure includes 4 members of type Quantum (typically 16-bits) of red, green, blue, and opacity. The black channel or colormap indexes are supported by a separate method and structure, IndexPacket. As an example, here is a code snippet from ImageMagick version 6 that negates the color components (but not the alpha component) of the image pixels:</p>
119 <p>ImageMagick version 7 supports any number of channels from 1 to 32 (and beyond) and simplifies access with a single method that returns an array of pixel channels of type Quantum. Source code that compiles against prior versions of ImageMagick requires refactoring to work with ImageMagick version 7. We illustrate with an example. Let's naively refactor the version 6 code snippet from above so it works with the ImageMagick version 7 API:</p>
193 <p>Note, how we use GetPixelChannels() to advance to the next set of pixel channels.</p>
197 <p>As a consequence of using an array structure for variable pixel channels, auto-vectorization compilers have additional opportunities to speed up pixel loops.</p>
200 <p>You can access pixel channel as array elements (e.g. <code>pixel[1]</code>) or use convenience accessors to get or set pixel channels:</p>
255 <p>For convenience you can set the active trait for a set of pixel channels with a channel mask and this method:</p>
271 <h4>Pixel User Channels</h4>
272 <p>In version 7, we introduce pixel user channels. Traditionally we utilize 4 channels, red, green, blue, and alpha. For CMYK we also have a black channel. User channels are designed to contain whatever additional channel information that makes sense for your application. Some examples include extra channels in TIFF or PSD images or perhaps you require a channel with infrared information for the pixel. You can associate traits with the user channels so that they when they are acted upon by an image processing algorithm (e.g. blur) the pixels are copied, acted upon by the algorithm, or even blended with the alpha channel if that makes sense.</p>
300 <p>Previously, grayscale images were Rec601Luminance and consumed 4 channels: red, green, blue, and alpha. With version 7, grayscale consumes only 1 channel requiring far less resources as a result.</p>
318 <li>Image signatures have changed to account for variable pixel channels.</li>
377 channels. Most operators will blend alpha the other color channels, but other
379 currently done by removing alpha from teh active channels via
385 be applied to expand the one channel into separate RGB (or other) channels.
458 <p>exchange, extract, or copy one or more image channels.</p>
460 <p>The expression consists of one or more channels, either mnemonic or numeric (e.g. red or 0, green or 1, etc.), separated by certain operation symbols as follows:</p>
463 <=> exchange two channels (e.g. red<=>blue)
466 , write new image with channels in the specified order (e.g. red, green)
471 <p>For example, to create 3 grayscale images from the red, green, and blue channels of an image, use:</p>
535 <dd>currently negates all channels, including alpha if present. As such you
597 <li>Pixels are no longer addressed with PixelPacket structure members (e.g. red, green, blue, opacity) but as an array of channels (e.g. pixel[PixelRedChannel]).</li>
598 <li>Use convenience macros to access pixel channels (e.g. GetPixelRed(), SetPixelRed()).</li>
601 <li>Use GetPixelChannels() to advance to the next set of pixel channels.</li>
625 <li>To account for variable pixel channels, images may now return a different signature.</li>
