From 10d5f99dce7ec0c6758e7396a8f9d8a54e4fdde3 Mon Sep 17 00:00:00 2001 From: cristy Date: Thu, 7 May 2015 17:52:30 +0000 Subject: [PATCH] --- www/architecture.html | 30 ++++++------- www/contact.html | 2 +- www/magick++.html | 4 +- www/magick-core.html | 102 +++++++++++++++++++++--------------------- www/magick-wand.html | 18 ++++---- www/magick.html | 4 +- www/sponsors.html | 6 +-- 7 files changed, 83 insertions(+), 83 deletions(-) diff --git a/www/architecture.html b/www/architecture.html index e3511a9d3..ab8f2d8a4 100644 --- a/www/architecture.html +++ b/www/architecture.html @@ -140,10 +140,10 @@ if (image == (Image *) NULL)

Once the pixel cache is associated with an image, you typically want to get, update, or put pixels into it. We refer to pixels inside the image region as authentic pixels and outside the region as virtual pixels. Use these methods to access the pixels in the cache:

Here is a typical MagickCore code snippet for manipulating pixels in the pixel cache. In our example, we copy pixels from the input image to the output image and decrease the intensity by 10%:

@@ -184,9 +184,9 @@ if (y < (ssize_t) source->rows) { /* an exception was thrown */ } -

When we first create the destination image by cloning the source image, the pixel cache pixels are not copied. They are only copied when you signal your intentions to modify or set the pixel cache by calling GetAuthenticPixels() or QueueAuthenticPixels(). Use QueueAuthenticPixels() if you want to set new pixel values rather than update existing ones. You could use GetAuthenticPixels() to set pixel values but it is slightly more efficient to use QueueAuthenticPixels() instead. Finally, use SyncAuthenticPixels() to ensure any updated pixels are pushed to the pixel cache.

+

When we first create the destination image by cloning the source image, the pixel cache pixels are not copied. They are only copied when you signal your intentions to modify or set the pixel cache by calling GetAuthenticPixels() or QueueAuthenticPixels(). Use QueueAuthenticPixels() if you want to set new pixel values rather than update existing ones. You could use GetAuthenticPixels() to set pixel values but it is slightly more efficient to use QueueAuthenticPixels() instead. Finally, use SyncAuthenticPixels() to ensure any updated pixels are pushed to the pixel cache.

-

Recall how we mentioned that the indexes of a colormapped image or the black channel of a CMYK image are stored separately. Use GetVirtualIndexQueue() (to read the indexes) or GetAuthenticIndexQueue() (to update the indexes) to gain access to this channel. For example, to print the colormap indexes, use:

+

Recall how we mentioned that the indexes of a colormapped image or the black channel of a CMYK image are stored separately. Use GetVirtualIndexQueue() (to read the indexes) or GetAuthenticIndexQueue() (to update the indexes) to gain access to this channel. For example, to print the colormap indexes, use:

const IndexPacket
   *indexes;
@@ -214,7 +214,7 @@ if (y < (ssize_t) source->rows)
 
Virtual Pixels

 
 
There are a plethora of image processing algorithms that require a neighborhood of pixels about a pixel of interest.  The algorithm typically includes a caveat concerning how to handle pixels around the image boundaries, known as edge pixels.  With virtual pixels, you do not need to concern yourself about special edge processing other than choosing  which virtual pixel method is most appropriate for your algorithm.

- 
Access to the virtual pixels are controlled by the SetImageVirtualPixelMethod() method from the MagickCore API or the ‑virtual‑pixel option from the command line.  The methods include:

+ 
Access to the virtual pixels are controlled by the SetImageVirtualPixelMethod() method from the MagickCore API or the ‑virtual‑pixel option from the command line.  The methods include:

 
 

 
background

@@ -292,7 +292,7 @@ Resource limits:
   Time: unlimited
-

You can set these limits either as a policy (see policy.xml), with an environment variable, with the -limit command line option, or with the SetMagickResourceLimit() MagickCore API method. As an example, our online web interface to ImageMagick, ImageMagick Studio, includes these policy limits to help prevent a denial-of-service:

+

You can set these limits either as a policy (see policy.xml), with an environment variable, with the -limit command line option, or with the SetMagickResourceLimit() MagickCore API method. As an example, our online web interface to ImageMagick, ImageMagick Studio, includes these policy limits to help prevent a denial-of-service:

 <policymap>
   <policy domain="resource" name="temporary-path" value="/tmp"/>
@@ -341,7 +341,7 @@ Resource limits:
 
 
Cache Views

 
-
GetVirtualPixels(), GetAuthenticPixels(), QueueAuthenticPixels(), and SyncAuthenticPixels(), from the MagickCore API, can only deal with one pixel cache area per image at a time.  Suppose you want to access the first and last scanline from the same image at the same time?  The solution is to use a cache view.  A cache view permits you to access as many areas simultaneously in the pixel cache as you require.  The cache view methods are analogous to the previous methods except you must first open a view and close it when you are finished with it. Here is a snippet of MagickCore code that permits us to access the first and last pixel row of the image simultaneously:

+
GetVirtualPixels(), GetAuthenticPixels(), QueueAuthenticPixels(), and SyncAuthenticPixels(), from the MagickCore API, can only deal with one pixel cache area per image at a time.  Suppose you want to access the first and last scanline from the same image at the same time?  The solution is to use a cache view.  A cache view permits you to access as many areas simultaneously in the pixel cache as you require.  The cache view methods are analogous to the previous methods except you must first open a view and close it when you are finished with it. Here is a snippet of MagickCore code that permits us to access the first and last pixel row of the image simultaneously:

 
 
CacheView
   *view_1,
@@ -414,7 +414,7 @@ convert image.mpc -crop 100x100+200+0 +repage 3.png
 
 
ImageMagick provides for streaming pixels as they are read from or written to an image.  This has several advantages over the pixel cache.  The time and resources consumed by the pixel cache scale with the area of an image, whereas the pixel stream resources scale with the width of an image.  The disadvantage is the pixels must be consumed as they are streamed so there is no persistence.

 
-
Use ReadStream() or WriteStream() with an appropriate callback method in your MagickCore program to consume the pixels as they are streaming.  Here's an abbreviated example of using ReadStream:

+
Use ReadStream() or WriteStream() with an appropriate callback method in your MagickCore program to consume the pixels as they are streaming.  Here's an abbreviated example of using ReadStream:

 
 
static size_t StreamPixels(const Image *image,const void *pixels,const size_t columns)
 {
@@ -449,7 +449,7 @@ image=ReadStream(image_info,&StreamPixels,exception);
 
(void) printf("image width: %lu, height: %lu\n",image->columns,image->rows);
 

 
-
For a great majority of image properties, such as an image comment or description, we use the GetImageProperty() and SetImageProperty() methods.  Here we set a property and fetch it right back:

+
For a great majority of image properties, such as an image comment or description, we use the GetImageProperty() and SetImageProperty() methods.  Here we set a property and fetch it right back:

 
 
const char
   *comment;
@@ -462,7 +462,7 @@ if (comment == (const char *) NULL)
 
 
ImageMagick supports artifacts with the GetImageArtifact() and SetImageArtifact() methods.  Artifacts are stealth properties that are not exported to image formats (e.g. PNG).

 
-
Image profiles are handled with GetImageProfile(), SetImageProfile(), and ProfileImage() methods.  Here we set a profile and fetch it right back:

+
Image profiles are handled with GetImageProfile(), SetImageProfile(), and ProfileImage() methods.  Here we set a profile and fetch it right back:

 
 
StringInfo
   *profile;
@@ -520,7 +520,7 @@ convert -limit memory 2mb -limit map 2mb -limit disk 2gb \
 
 
Threads of Execution

 
-
Many of ImageMagick's internal algorithms are threaded to take advantage of speed-ups offered by the multicore processor chips. However, you are welcome to use ImageMagick algorithms in your threads of execution with the exception of the MagickCore's GetVirtualPixels(), GetAuthenticPixels(), QueueAuthenticPixels(), or SyncAuthenticPixels() pixel cache methods.  These methods are intended for one thread of execution only with the exception of an OpenMP parallel section.  To access the pixel cache with more than one thread of execution, use a cache view.  We do this for the CompositeImage() method, for example.  Suppose we want to composite a single image over a different image in each thread of execution.  If we use GetVirtualPixels(), the results are unpredictable because multiple threads would likely be asking for different areas of the pixel cache simultaneously.  Instead we use GetCacheViewVirtualPixels() which creates a unique view for each thread of execution ensuring our program behaves properly regardless of how many threads are invoked.  The other program interfaces, such as the MagickWand API, are completely thread safe so there are no special precautions for threads of execution.

+
Many of ImageMagick's internal algorithms are threaded to take advantage of speed-ups offered by the multicore processor chips. However, you are welcome to use ImageMagick algorithms in your threads of execution with the exception of the MagickCore's GetVirtualPixels(), GetAuthenticPixels(), QueueAuthenticPixels(), or SyncAuthenticPixels() pixel cache methods.  These methods are intended for one thread of execution only with the exception of an OpenMP parallel section.  To access the pixel cache with more than one thread of execution, use a cache view.  We do this for the CompositeImage() method, for example.  Suppose we want to composite a single image over a different image in each thread of execution.  If we use GetVirtualPixels(), the results are unpredictable because multiple threads would likely be asking for different areas of the pixel cache simultaneously.  Instead we use GetCacheViewVirtualPixels() which creates a unique view for each thread of execution ensuring our program behaves properly regardless of how many threads are invoked.  The other program interfaces, such as the MagickWand API, are completely thread safe so there are no special precautions for threads of execution.

 
 
Here is an MagickCore code snippet that takes advantage of threads of execution with the OpenMP programming paradigm:

 
@@ -634,7 +634,7 @@ void ConvertBMPToImage(const BITMAPINFOHEADER *bmp_info,
 
 
If you call the ImageMagick API from your OpenMP-enabled application and you intend to dynamically increase the number of threads available in subsequent parallel regions, be sure to perform the increase before you call the API otherwise ImageMagick may fault.

 
-
MagickWand supports wand views.  A view iterates over the entire, or portion, of the image in parallel and for each row of pixels, it invokes a callback method you provide.  This limits most of your parallel programming activity to just that one module.  There are similar methods in MagickCore.  For an example, see the same sigmoidal contrast algorithm implemented in both MagickWand and MagickCore.

+
MagickWand supports wand views.  A view iterates over the entire, or portion, of the image in parallel and for each row of pixels, it invokes a callback method you provide.  This limits most of your parallel programming activity to just that one module.  There are similar methods in MagickCore.  For an example, see the same sigmoidal contrast algorithm implemented in both MagickWand and MagickCore.

 
 
In most circumstances, the default number of threads is set to the number of processor cores on your system for optimal performance.  However, if your system is hyperthreaded or if you are running on a virtual host and only a subset of the processors are available to your server instance, you might get an increase in performance by setting the thread policy or the MAGICK_THREAD_LIMIT environment variable.  For example, your virtual host has 8 processors but only 2 are assigned to your server instance.  The default of 8 threads can cause severe performance problems.  One solution is to limit the number of threads to the available processors in your policy.xml configuration file:

 
@@ -1170,7 +1170,7 @@ display logo.mgk
 
 
Custom Image Filters

 
-
ImageMagick provides a convenient mechanism for adding your own custom image processing algorithms.  We call these image filters and they are invoked from the command line with the -process option or from the MagickCore API method ExecuteModuleProcess().

+
ImageMagick provides a convenient mechanism for adding your own custom image processing algorithms.  We call these image filters and they are invoked from the command line with the -process option or from the MagickCore API method ExecuteModuleProcess().

 
 
Here is a listing of a sample custom image filter.  It computes a few statistics such as the pixel brightness and saturation mean and standard-deviation.

 
diff --git a/www/contact.html b/www/contact.html
index 7bbf9c413..f899d751b 100644
--- a/www/contact.html
+++ b/www/contact.html
@@ -60,7 +60,7 @@
   

   
Contact the Wizards

 	
Enter this code, 
-0ae3a2, in the Authenticate field and fill in the remaining fields.  Press Send to forward your message to the ImageMagick wizards:

+467db3, in the Authenticate field and fill in the remaining fields.  Press Send to forward your message to the ImageMagick wizards:

   

   

   

diff --git a/www/magick++.html b/www/magick++.html
index 110b88d24..dbcc1d5d7 100644
--- a/www/magick++.html
+++ b/www/magick++.html
@@ -171,7 +171,7 @@
 

 

 

-  Search
+  Search
 

 

 

@@ -306,7 +306,7 @@ of installing ImageMagick in a known location.
 

 

   ©  1999-2015 ImageMagick Studio LLC
-   Contact the Wizards
+   Contact the Wizards
 

 

 
diff --git a/www/magick-core.html b/www/magick-core.html
index cfcf53bd3..960c7d3e7 100644
--- a/www/magick-core.html
+++ b/www/magick-core.html
@@ -59,57 +59,57 @@
 
The MagickCore API is a low-level interface between the C programming language and the ImageMagick image processing libraries and is recommended for wizard-level programmers only.  Unlike the MagickWand C API which uses only a few opaque types and accessors, with MagickCore you almost exlusively access the structure members directly.  A description of the MagickCore public methods are found here:

 
 
 
diff --git a/www/magick-wand.html b/www/magick-wand.html
index 00120af7a..d57de005c 100644
--- a/www/magick-wand.html
+++ b/www/magick-wand.html
@@ -59,15 +59,15 @@
 
The MagickWand API is the recommended interface between the C programming language and the ImageMagick image processing libraries.  Unlike the MagickCore C API, MagickWand uses only a few opaque types.  Accessors are available to set or get important wand properties.  A description of the MagickWand public methods are found here:

 
 
 
diff --git a/www/magick.html b/www/magick.html
index 36724ffb1..930407e49 100644
--- a/www/magick.html
+++ b/www/magick.html
@@ -141,7 +141,7 @@
 
 

 

-  Search
+  Search
 

 

 

@@ -1383,7 +1383,7 @@ transparent, extract, background, or shape the alpha channel
   

   

     ©  1999-2011 ImageMagick Studio LLC
-     Contact the Wizards
+     Contact the Wizards