diff --git a/www/architecture.html b/www/architecture.html
index 34e7c9e..867eae1 100644
--- a/www/architecture.html
+++ b/www/architecture.html
@@ -127,7 +127,7 @@
<div class="sponsbox">
<div class="sponsor">
- <a title="Sponsor: Fernsehdienst Berlin" href="http://www.atlas-multimedia.de">Fernsehdienst Berlin</a><!-- 2011040100025 atlas.multimedia-->
+ <a title="Sponsor: Free Catalogs" href="http://www.who-sells-it.com/">Free Catalogs</a><!-- 20120801000600 -->
</div>
<div class="sponsor">
<a title="Sponsor: Druckerei" href="http://print24.com/de/">Druckerei</a><!-- 201110010720 -->
@@ -254,7 +254,7 @@
<p>When the pixel cache is initialized, pixels are scaled from whatever bit depth they originated from to that required by the pixel cache. For example, a 1-channel 1-bit monochrome PBM image is scaled to a 4 channel 8-bit RGBA image, if you are using the Q8 version of ImageMagick, and 16-bit RGBA for the Q16 version. You can determine which version you have with the <a href="../www/command-line-options.html#version">‑version</a> option: </p>
-<p class='crt'><span class="crtprompt"> $magick> </span><span class='crtin'>identify -version</span><span class='crtout'>Version: ImageMagick 6.6.6-3 2010-22-21 Q16 http://www.imagemagick.org</span></p>
+<p class='crt'><span class="crtprompt"> $magick> </span><span class='crtin'>identify -version</span><span class='crtout'>Version: ImageMagick 6.6.6-4 2010-12-01 Q16 http://www.imagemagick.org</span></p>
<p>As you can see, the convenience of the pixel cache sometimes comes with a trade-off in storage (e.g. storing a 1-bit monochrome image as 16-bit RGBA is wasteful) and speed (i.e. storing the entire image in memory is generally slower than accessing one scanline of pixels at a time). In most cases, the benefits of the pixel cache typically outweigh any disadvantages.</p>
</div>
@@ -283,7 +283,8 @@
x,
y;
- destination=CloneImage(source,source->columns,source->rows,MagickTrue,exception);
+ destination=CloneImage(source,source->columns,source->rows,MagickTrue,
+ exception);
if (destination == (Image *) NULL)
{ /* an exception was thrown */ }
for (y=0; y < (ssize_t) source->rows; y++)
@@ -345,7 +346,7 @@
<p>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.</p>
<p>Access to the virtual pixels are controlled by the <a href="../www/api/cache.html#SetImageVirtualPixelMethod">SetImageVirtualPixelMethod()</a> method from the MagickCore API or the <a href="../www/command-line-options.html#virtual-pixel">‑virtual‑pixel</a> option from the command line. The methods include:</p>
-<pre class="text">
+<pre class="text" style="font-size: 90%;">
background: the area surrounding the image is the background color
black: the area surrounding the image is black
checker-tile: alternate squares with image and background color
@@ -372,7 +373,7 @@
<dl class="doc">
<dt class="doc">files</dt>
- <dd>maximum number of open pixel cache files. When this limit is exceeded, any subsequent pixels cached to disk are closed and reopened on demand. This behavior permits a large number of images to be accessed simultaneously on disk, but with a speed penalty due to repeated open/close calls.</dd>
+ <dd>maximum number of open pixel cache files. When this limit is exceeded, any subsequent pixels cached to disk are closed and reopened on demand. This behavior permits a large number of images to be accessed simultaneously on disk, but without a speed penalty due to repeated open/close calls.</dd>
<dt class="doc">area</dt>
<dd>maximum area in bytes of any one image that can reside in the pixel cache memory. If this limit is exceeded, the image is automagically cached to disk.</dd>
<dt class="doc">memory</dt>
@@ -381,6 +382,10 @@
<dd>maximum amount of memory map in bytes to allocate for the pixel cache.</dd>
<dt class="doc">disk</dt>
<dd>maximum amount of disk space in bytes permitted for use by the pixel cache. If this limit is exceeded, the pixel cache is not created and a fatal exception is thrown.</dd>
+ <dt class="doc">thread</dt>
+ <dd>maximum number of threads that are permitted to run in parallel.</dd>
+ <dt class="doc">time</dt>
+ <dd>maximum number of seconds that the process is permitted to execute. When this limit is exceeded, an exception is thrown and processing stops.</dd>
</dl>
<p>To determine the current setting of these limits, use this command:</p>
@@ -390,7 +395,7 @@
768 1.0386GB 3.8692GiB 7.7384GiB unlimited 4 unlimited
</pre
></span></p>
-<p>You can set these limits either as a <a href="../www/resources.html#configure">policy</a> (see <kbd>policy.xml</kbd>), with an <a href="../www/resources.html#environment">environment variable</a>, with the <a href="../www/command-line-options.html#limit">-limit</a> command line option, or with the <a href="../www/api/resource.html#SetMagickResourceLimit">SetMagickResourceLimit()</a> MagickCore API method. As an example, our online web interface to ImageMagick, <a href="http://www.imagemagick.org/MagickStudio/scripts/MagickStudio.cgi">ImageMagick Studio</a>, has an area limit of 64 megabytes, a memory limit of 128 mebibytes and a map limit of 256 mebibytes and a disk limit of 1 gigabytes. Since we process multiple simultaneous sessions, we don't want any one session consuming all the available memory. Instead large images are cached to disk. If the image is too large and exceeds the pixel cache disk limit, the program exits. In addition, we place a 60 second time limit to prevent any run-away processing tasks.</p>
+<p>You can set these limits either as a <a href="../www/resources.html#configure">policy</a> (see <a href="../www/source/policy.xml">policy.xml</a>), with an <a href="../www/resources.html#environment">environment variable</a>, with the <a href="../www/command-line-options.html#limit">-limit</a> command line option, or with the <a href="../www/api/resource.html#SetMagickResourceLimit">SetMagickResourceLimit()</a> MagickCore API method. As an example, our online web interface to ImageMagick, <a href="http://www.imagemagick.org/MagickStudio/scripts/MagickStudio.cgi">ImageMagick Studio</a>, has an area limit of 64 megabytes, a memory limit of 128 mebibytes and a map limit of 256 mebibytes and a disk limit of 1 gigabytes. Since we process multiple simultaneous sessions, we don't want any one session consuming all the available memory. Instead large images are cached to disk. If the image is too large and exceeds the pixel cache disk limit, the program exits. In addition, we place a 60 second time limit to prevent any run-away processing tasks.</p>
<p>Note, the cache limits are global, meaning if you create several images, the combined resource requirements are compared to the limit to determine the pixel cache storage disposition.</p>
</div>
@@ -410,7 +415,8 @@
for (y=0; y < (ssize_t) source->rows; y++)
{
u=GetCacheViewVirtualPixels(view_1,0,y,source->columns,1,exception);
- v=GetCacheViewVirtualPixels(view_2,0,source->rows-y-1,source->columns,1,exception);
+ v=GetCacheViewVirtualPixels(view_2,0,source->rows-y-1,source->columns,1,
+ exception);
if ((u == (const PixelPacket *) NULL) || (v == (const PixelPacket *) NULL))
break;
for (x=0; x < (ssize_t) source->columns; x++)
@@ -612,7 +618,7 @@
<p><a href="../www/api/wand-view.html">MagickWand</a> 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 <a href="../www/api/image-view.html">MagickCore</a>. For an example, see the same sigmoidal contrast algorithm implemented in both <a href="../www/magick-wand.html#wand-view">MagickWand</a> and <a href="../www/magick-core.html#image-view">MagickCore</a>.</p>
-<p>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 <a href="../www/resources.html#configure">policy</a> or the <a href="../www/resources.html#environment">MAGICK_THREAD_LIMIT</a> 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 <kbd>policy.xml</kbd> configuration file:</p>
+<p>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 <a href="../www/resources.html#configure">policy</a> or the <a href="../www/resources.html#environment">MAGICK_THREAD_LIMIT</a> 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 <a href="../www/source/policy.xml">policy.xml</a> configuration file:</p>
<pre class="text">
<policy domain="resource" name="thread" value="2"/>
@@ -682,7 +688,8 @@
{
for (long u=(-mid_width); u <= mid_width; u++)
{
- register const ulong index=ClampToCanvas(y+v,rows)*columns+ClampToCanvas(x+u,columns);
+ register const ulong index=ClampToCanvas(y+v,rows)*columns+ClampToCanvas(x+u,
+ columns);
const double alpha=scale*(QuantumRange-source[index].w);
sum.x+=alpha*filter[i]*source[index].x;
sum.y+=alpha*filter[i]*source[index].y;