diff --git a/www/architecture.html b/www/architecture.html
index 9f7ce19..650f020 100644
--- a/www/architecture.html
+++ b/www/architecture.html
@@ -142,7 +142,7 @@
<a title="Sponsor: Druckerei Online" href="http://www.allesdruck.de">Druckerei Online</a><!-- 201012011200 allesdruck.de-->
</div>
<div class="sponsor">
- <a title="Sponsor: Lampe Berger" href="http://www.geschenke-elsen.de/" title="Lampe Berger">Lampe Berger</a><!-- 201006101000040 -->
+ <a title="Sponsor: Online-Magazin" href="http://www.unkostenbeitrag.de/" title="Online-Magazin">Online-Magazin</a><!-- 20101101000200 -->
</div>
</div>
</div>
@@ -239,7 +239,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.2-1 2010-14-15 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.2-2 2010-24-25 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>
@@ -327,6 +327,7 @@
<h3><a name="virtual-pixels"></a>Virtual Pixels</h3>
<div class="doc-section">
+<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">
@@ -347,7 +348,6 @@
white: the area surrounding the image is white
</pre>
-<p>There is a plethora of image processing algorithms that require a neighborhood of pixels about a pixel of interest. There is typically 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>
</div>
<h3>Cache Storage and Resource Requirements</h3>
@@ -514,7 +514,7 @@
<p>ImageMagick can read, process, or write mega-, giga-, or tera-pixel image sizes. For example, here we resize an image to a quarter million pixels square:</p>
<p class='crt'><span class="crtprompt"> $magick> </span><span class='crtin'>convert logo: -resize 250000x250000 logo.miff</span></p>
-<p>For large images, ImageMagick will more than likely create a pixel cache on disk. Make sure you have plenty of temporary disk space. If your default temporary disk partition is too small, tell ImageMagick to use another partition with plenty of free space. For example:</p>
+<p>For large images, ImageMagick will likely create a pixel cache on disk. Make sure you have plenty of temporary disk space. If your default temporary disk partition is too small, tell ImageMagick to use another partition with plenty of free space. For example:</p>
<p class='crt'><span class="crtprompt"> $magick> </span><span class='crtin'>convert -define registry:temporary-path=/data/tmp logo: \ <br/> -resize 250000x250000 logo.miff</span></p>
<p>To ensure large images do not consume all the memory on your system, force the image pixels to memory-mapped disk with resource limits:</p>
@@ -530,7 +530,7 @@
<h2><a name="threads"></a>Threads of Execution</h2>
<div class="doc-section">
-<p>Many of ImageMagick's internal algorithms are threaded to take advantage of speed-ups offered by the dual and quad-core processor technologies. 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. To access the pixel cache with more than one thread of execution, use a cache view. We do this for the <a href="../www/api/composite.html#CompositeImage">CompositeImage()</a> 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 <a href="../www/magick-wand.html">MagickWand API</a>, are completely thread safe so there are no special precautions for threads of execution.</p>
+<p>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. To access the pixel cache with more than one thread of execution, use a cache view. We do this for the <a href="../www/api/composite.html#CompositeImage">CompositeImage()</a> 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 <a href="../www/magick-wand.html">MagickWand API</a>, are completely thread safe so there are no special precautions for threads of execution.</p>
<p>Here is an example of how ImageMagick can take advantage of threads of execution with the <a href="http://en.wikipedia.org/wiki/OpenMP">OpenMP</a> programming paradigm:</p>