Remove old wiki.

2025-01-21 21:20:07 -05:00 · 2017-03-15 18:18:18 -07:00 · 2017-03-15 18:18:18 -07:00 · ce26728f7c
commit ce26728f7c
parent 5352dc55bf
22 changed files with 0 additions and 2932 deletions
--- a/Data/Wiki/AboutDialog.htm
+++ b/Data/Wiki/AboutDialog.htm
@ -1,26 +0,0 @@
 #summary About dialog
 <font face="Verdana">
 =About=
 The About dialog shows miscellaneous program information.
 <ul>
    <li>
        ==Code Copied==
        This is code where portions were copied and modified.
    </li>
    <li>
        ==Libraries Linked==
        This is code that was either directly copied and remained mostly unmodified, or was built and linked in library form.
    </li>
    <li>
        ==Icons Used==
        The various icon sets that Fractorium got its icons from. Almost all of these were altered to be gray.
    </li>
 </ul>
--- a/Data/Wiki/AlgorithmExplanation.htm
+++ b/Data/Wiki/AlgorithmExplanation.htm
@ -1,318 +0,0 @@
 #summary How the fractal flames algorithm actually works.
 <font face="Verdana">
 =Introduction=
 The standard way of getting familiar with the algorithm is reading the paper by Scott Draves and Erik Reckase, titled <a href="http://flam3.com/flame_draves.pdf">The Fractal Flame Algorithm</a>. Reading it is highly recommended before proceeding.
 Another paper which gives more detail, and which this project borrows heavily from is the <a href="http://www.eecs.ucf.edu/seniordesign/su2011fa2011/g12/report.pdf">Cuburn paper</a>. The first few sections give a better description of the algorithm. The later sections are more focused on GPU implementations, so they are only recommended for advanced readers.
 While the original paper gives a great introduction, it omits some important details. If one reads the flam3 code, they will notice that quite a bit is left out of the paper. This section of the wiki gives a detailed description of what actually happens when a fractal flame is rendered.
 It's broken down into the data used, and the processing performed on the data in order from start to finish. It dispenses with mathematical terms and notation, and expresses the process in plain English with pseudo code.
 <br><br>
 =Details=
 <ul>
 <li>
 ==Data==
 <ul>
 <li>
 ===Buffers===
 -Histogram: Supersampled with gutter, iteration is plotted here.
 -Density filter buffer/accumulator: Same dimensions as histogram, density filter output written here.
 -Final image buffer: Not supersampled, final output written here.<br></br>
 The dimensions of the final image are straightforward. They are just the values specified in the size field of the Xml.
 The dimensions of the histogram are slightly more complex to calculate:
 {{{
 histwidth = (finalwidth * supersample) + (2 * gutter)
 histheight = (finalheight * supersample) + (2 * gutter)
 }}}
 The gutter is to account for the extra space needed when filtering at edge pixels. It's calculated by:
 {{{
 gutter = max((spatialfilterwidth - supersample) / 2, maxdensityfilterradius * supersample)
 }}}
 Computing the histogram bounds (camera) is much more complex. The values are based off of the following Xml fields: size, supersample, scale, zoom, center, spatial and density filter widths.
 Scale is the pixels per unit, meaning the number of raster pixels needed to represent the distance from 0 to 1 in the Cartesian plane. The higher the value, the more zoomed in the camera is. Increasing scale will degrade image quality.
 Zoom is the amount of zoom to apply to the image. It has a similar effect to increasing scale, but does not suffer from quality loss. This will increase the number of iterations done to compensate.
 Supersample is the value to multiply the dimensions of the histogram and accumulator by to accomplish anti-aliasing.
 Center is the camera offset in on each axis. The image will move in the opposite direction of these values.
 </li>
 <li>
 ===Fractal Flame (Ember)===
 The main data structure is the fractal flame itself. In this project, it is referred to as an `Ember`.
 An `Ember` contains the following pieces:<br></br>
 -Dimensions, filter parameters, and quality settings.<br></br>
 -A list of xforms, which each contain a weight, color index, color speed, pre and post affine transforms, and a list of variations.<br></br>
 -A color palette.
 </li>
 <li>
 ===Xml===
 An `Ember` is stored in an Xml file, which can contain one or more `Embers` in them. The first step in rendering is to read the data out of the Xml and into a vector of `Embers`.
 The first parameters encountered in each `Ember` are ones that specify general information about what is to be rendered, such as the dimensions, rotation, quality, supersampling, filter types and sizes, and color information. The colors that are to be used during iteration are specified in a palette, which is a list of 256 colors.
 </li>
 <li>
 ===Palettes===
 Palettes can be specified in one of two ways: An index into a palette file, or as an inserted block of data present in the `Ember` Xml. For the first case, the palette file is usually the standard flam3-palettes.xml file which contains 700 palettes and is shipped with all fractal flame editors. The `Ember` has an Xml field named palette whose value is an integer index into the file. A value of -1 means to select a random palette from the file. The palette index field is used in conjunction with the hue field. Hue signifies a hue rotation to be applied to the palette after it's read. The palettes in the file are stored as RGB values in the range of 0-255. Upon reading, the hue rotation is applied to them, and they are converted into normalized values ranging from 0-1. They are stored with the `Ember` in a `Palette` object.
 The other way of specifying a palette is to embed it directly in the Xml as either individual tags for each color entry, or as a hexadecimal representation of the binary data. The latter is preferred because it keeps the Xml files smaller. When embedding the palette, no hue adjustment is applied after reading it.
 </li>
 <li>
 ===Xforms===
 The xforms are what contribute most to defining the look of the final output image. Each xform contains several parameters:
 <ul>
 <li>
 ====Weight====
 The probability that the xform will be chosen in each iteration. All weights are normalized before running.
 </li><li>
 ====Color Index====
 The index in the palette the xform uses.
 </li><li>
 ====Color Speed====
 The speed with which the color indices are pulled toward this xform's color index. This value can be negative.
 </li><li>
 ====Opacity====
 How visible the xform's contribution to the image is.
 </li><li>
 ====Pre Affine Transform====
 The affine transform that is applied to the input coordinates which will be used as inputs to the variations.
 </li><li>
 ====Post Affine Transform====
 The affine transform that is applied to the output of the sum of the variations, optionally omitted.
 </li><li>
 ====Variations====
 A list of functions which each contain a weight, and optionally more parameters.
 </li><li>
 ====Xaos====
 Xaos is an optional advanced feature that adds an element of control to the random selection of xforms during iteration. It adds an adjustment to the probability that a given xform will be selected based on the xform that was selected in the previous iteration. This is usually omitted.
 </li>
 </ul>
 In addition to the list of xforms, an additional one can be specified as the final xform. It contains all of the same parameters, except weight. This is because it is always applied in each iteration.
 </li>
 <li>
 ===Filters===
 As mentioned earlier, each `Ember` contains filtering parameters. These are values used to specify details about the three filtering stages used to improve the quality of the final output image. They are:
 <ul>
 <li>
 ====Temporal====
 In addition to creating a still image, the algorithm can be used to create a series of still images where each represents a frame in an animation. This is done by adjusting the affine transforms slightly for each frame. It also involves interpolating (blending) between two different `Embers`. Sometimes, even slight changes in the `Ember` parameters can cause a large change in the final output image. To mitigate this effect, each frame splits its render into a number of temporal samples. This does not increase the number of iterations. Instead, it breaks the total number of iterations into chunks. Each chunk renders an interpolated `Ember` at a specific time between the current frame and the next one to be rendered. The histogram is not cleared between temporal samples, so all iteration values are accumulated to produce a motion blurring effect. A temporal samples value of 1000 is commonly used for animation. When rendering a single frame, the number of temporal samples is always set to 1 since there is nothing to interpolate.
 </li><li>
 ====Density====
 Flam3 refers to this as density estimation, or DE. This is a misnaming as there is no estimation taking place. Rather, a variable width Gaussian filter is applied to each log scaled histogram cell. The Xml specifies the minimum and maximum widths that the filter can be, as well as the decay curve for how quickly the filter's values drop off when extending outward from the pixel being filtered.
 </li><li>
 ====Spatial====
 After iterating and density filtering are done, final color correction to the output image is computed. Spatial filtering is applied during this step. The Xml parameters specify both the width of the filter as well as the type. This gives very fine adjustment over what the final image looks like.
 <br></br>
 </li>
 </ul>
 </li>
 </ul>
 </li>
 <li>
 ==Processing==
 The process contains 3 main steps:
 -Iterating<br></br>
 -Density Filtering<br></br>
 -Final Accumulation
 <ul>
 <li>
 ===Iterating===
 <ul>
 <li>
 ====Xform Application====
 Iterating is described in the paper, however it's worth clarifying because it's the most important part of the algorithm.
 Random numbers are obviously a core component of the algorithm, however the paper doesn't touch on exactly how they're implemented and used. Flam3 uses a very fast and high quality RNG named ISAAC because system RNGs are usually of poor quality. Using ISAAC also allows for producing the exact same image on different platforms when supplied with the same seed.
 More interesting though, is how the numbers from ISAAC are used to select random xforms. Before iterating begins, a buffer of 10,000 elements is created. All xform weights are normalized and the elements of the buffer are populated with xform indices with a distribution proportional to each of their weights. For example, given an Ember with 4 xforms, each with a weight of 1, their normalized weights would each become 0.25. The random selection buffer would then be populated like so:
 {{{
 buf[0..2499] = 0
 buf[2500..4999] = 1
 buf[5000..7499] = 2
 buf[7500..9999] = 3
 }}}
 To select a random xform, retrieve the next random unsigned integer from ISAAC and perform a modulo (%) 10,000. The value at that index in the buffer is the index of the next xform to use.<br></br>
 The classic Iterated Function System works like the following pseudo code in flam3 and Ember:
 x and y = random numbers between -1 and 1.
 Pick a random xform from the Ember, with biases specified by their weights.
 Calculate tx and ty by applying the selected xform's pre affine transform to x and y:
 {{{
 tx = Ax * By + C
 ty = Dx * Ey + F
 }}}
 Pass the transformed point to each of the variations and sum the results. Note that this does not change the transformed points at all, they are only used as inputs.
 {{{
 vx = 0
 vy = 0
 vx,vy += var1(tx, ty)
 vx,vy += var2(tx, ty)
 vx,vy += var3(tx, ty)
 ...
 vx,vy += varN(tx, ty)
 ox, oy = vx, vy
 }}}
 If a post affine transform is present, apply it to the result calculated from summing the outputs of the variations above.
 {{{
 ox = pAvx * pBvy + pC
 oy = pDvx * pEvy + pF
 }}}
 Now that the new point has been calculated, compute the new color coordinate. As the paper states, the coordinate is the one specified in the currently chosen xform, blended with the one from the previously chosen xform. It incorrectly states that blending is achieved by adding the current and previous coordinates and dividing by 2. Not only is it calculated differently, but the hard coded value of 2 is actually the user specified color speed parameter of each xform. The real calculation is:
 {{{
 newindex = colorspeed * thisindex + (1.0 - colorspeed) * oldindex
 }}}
 It's important to note that the colors themselves are not being blended, only their indices in the palette are.
 At this point, we have the final output point ox,oy to be plotted to the histogram. However, we can't use it just yet. There is a slight possibility that the calculated value was not valid. This is detected by checking for it being very close to infinity, or very close to zero. If either are the case, 5 attempts at the following correction method are tried:
 -Pick a new input point with x and y each being a different random number between -1 and 1.<br></br>
 -Pick a new random xform and apply it.<br></br>
 -Keep color index from the first xform that was applied, which originally gave us the bad values.<br></br>
 If after 5 attempts, a valid point is not produced, the output point is assigned random numbers between -1 and 1. The number of bad values are saved for statistical use later.
 After computing this point, apply a final xform if one is present. Plot its output next, however do not feed it back into the iteration loop. Rather, only feed the output of the randomly selected xform above to the next iteration of the loop.
 </li>
 <li>
 ====Plotting====
 Once we have our new point, it's time to plot it. This is one of the most important parts of the algorithm, so it's worth detailing what exactly happens. First, let's review the information the point contains:
 -An x,y coordinate in Cartesian space.<br></br>
 -A color index from 0-255.<br></br>
 The first step in plotting is applying any rotation specified in the Xml. Rotation is specified in terms of the camera, so it will actually rotate the image in the opposite direction.
 After applying rotation to the coordinate, bounds checking is done. If the point is outside of the Cartesian space the histogram covers, then it's discarded, otherwise it's plotted if the opacity is non-zero.
 The point can't be plotted directly because it's in a different coordinate system than the one used for indexing the histogram memory. The points are decimal numbers in Cartesian space with 0,0 at the center. The histogram is stored in raster coordinates with 0,0 at the top left and each bucket specified by an integer x,y index. So before plotting, the coordinates must be converted to determine the histogram bucket to write to.
 After computing the raster coordinate, a color must be added to the bucket. This is gotten from the Ember's color palette, at the index specified in the point. A similar coordinate problem occurs in that the computed color index is a decimal number, but the indices in the palette are integers. The algorithm offers two methods for retrieving the color. The first is called "Step" and just rounds the index down to the nearest integer. The other is called "Linear" and does a blending of the values at the integer index and the one next to it.
 Once a color is retrieved, multiply all three RBG values by the opacity and add the result to the RGB values in the histogram bucket at the specified location. The alpha channel is unused for transparency and is instead used as a hit counter to record how many times a given bucket was hit during iteration. Each hit adds one to the alpha channel.
 The Cartesian coordinate calculated from applying the xform in the previous step is fed back into the iteration loop and is used as the starting point for repeating the process all over again. The number of times this is done is referred to as the quality and is equal to:
 {{{
 quality * finalwidth * finalheight
 }}}
 Note that while supersampling increases the size of the histogram, it does not increase the number of iterations performed.
 </li>
 <li>
 ====Trajectory====
 Iterating and plotting don't occur exactly in the order described above or in the paper. The point is not plotted immediately after each xform application. Rather, the points are all stored in a temporary buffer whose size defaults to 10,000, known as a sub batch. Once 10,000 iterations have completed, all of the points are plotted to the histogram. Before the next sub batch begins, the point trajectory is reset by re-enabling the fuse state and assigning the first input coordinate random numbers between -1 and 1.
 This method of using sub batches reveals an interesting characteristic of the algorithm not covered in the paper. That is, the point trajectory need not remain continuous to produce a final image. Even when resetting every 10,000 iterations, the trajectory still converges on the attractor. Thanks to this property, multi-threading does not degrade the image quality by breaking up the trajectory, since each thread will run many sub batches.<br></br>
 </li>
 </ul>
 </li>
 <li>
 ===Density Filtering===
 After the iteration loop is performed many times, most of the buckets in the histogram will have been hit many times. This puts their color values far outside the allowed range for display, 0-255 (or 0-1 for normalized colors).
 To bring these color values into the valid range, log scaling is applied. There are two types, basic log scaling or log scaling with density estimation filtering. As stated above, the term density estimation is misleading, since no estimating of any kind takes place.
 Basic log scaling is triggered by setting the maximum density filtering radius to zero. It is achieved by performing the following step on each histogram bucket:
 {{{
 scale = 2^zoom
 scaledquality = quality * scale * scale
 area = (finalwidth * finalheight) / (pixelsperunitx * pixelsperunity)
 k1 = (brightness * 268) / 256
 k2 = supersample^2 / (area * scaledquality * temporalfilter.sumfilt)
 accumulator[index] = (k1 * log(1 + histogram[index].hitcount * k2)) / histogram[index].hitcount
 }}}
 This calculation is much more complex than the simplistic log(a)/a mentioned in the flam3 paper. Note the presence of the somewhat mysterious k1 and k2 variables. They are mentioned nowhere in the paper, and are completely undocumented in the flam3 code, yet play a large role in how the final output image appears. k1 is intended to be the brightness multiplied by a magic number. k2 helps adjust the log scaling based on the supersample.
 If the max density filtering radius is greater than zero, a much more advanced algorithm is used for filtering. As stated in the paper, it's a Gaussian blur filter whose width is inversely proportional to the number of hits in a given bucket. This means that buckets which were hit infrequently will have a wide blur applied to the surrounding pixels. A bucket with many hits will have very little blur applied.
 The result of these filtering operations is written to another buffer of identical size called the filtering buffer, or accumulator.
 </li>
 <li>
 ===Final Accumulation===
 Despite filtering, the image is still not ready for final display. One more step is needed, and that is final accumulation with spatial filtering.
 For each pixel in the filtering buffer at the beginning (top left) of each supersample block (SSxSS), a spatial filter is applied and the resulting value is written as a single pixel to the final output image.
 The spatial filter is of a fixed width and type specified in the original Xml. It multiplies the filter values by the pixel values of all pixels extending forward and down by the length of the filter, and sums them to a final value. This final value will most likely be out of range, so further color correction is necessary. Gamma correction is applied and the final pixels are clamped to the valid range of 0-255 and written to the output image buffer. Note that the color correction process is not documented anywhere and remains mostly a mystery, however it works.
 If early clipping is specified, the color correction is applied before the spatial filter.
 The process is done.
 </li>
 </ul>
 </li>
 </ul>
--- a/Data/Wiki/Building.htm
+++ b/Data/Wiki/Building.htm
@ -1,232 +0,0 @@
 #summary How to build Fractorium from source.
 <font face="Verdana">
 =Introduction=
 Step by step instructions for building Fractorium and its associated libraries from source.
 The development environment currently supported is Visual Studio 2010 SP1. In the future, other compilers and operating systems will be supported. For now, this page focuses on VS 2010 SP1.
 First install Visual Studio 2010, and run it once. Then close it and install SP1.
 =Details=
 The release built into the installer on the main page is for x64 systems only. This is because x64 gives a ~30% performance improvement over x86, which is most likely due to additional registers in the x64 standard. Another reason for x64 only, is that such processors have been around for almost a decade, with popular operating system support existing since Windows Vista. There is simply no reason to support x86 systems. This project aims to help move the target platforms of popular applications away from x86 and toward x64.
 Sadly, the free version of Visual Studio does not support building x64 targets. You are welcome to build for x86, but understand that the CPU performance will be significantly lower than what you experience with the executable contained in the installer.
 These steps must be followed exactly as stated, and in the order stated. Skipping any step, or doing any step out of order will break the build.
 ==Prerequisites==
 These are the libraries that the project depends on. Download the zip files and extract them into folders organized in the following way:
 /<a href="http://sourceforge.net/projects/ogl-math/">glm</a> (Matrix math)<br></br>
 /<a href="http://www.ijg.org/">libjpeg</a> (Jpg image support)<br></br>
 /<a href="https://sourceforge.net/projects/libpng/files/">libpng</a> (Png image support)<br></br>
 /<a href="https://git.gnome.org/browse/libxml2/">libxml2</a> (Xml parsing support)<br></br>
 /<a href="https://www.threadingbuildingblocks.org/">tbb</a> (Intel Threading Building Blocks)<br></br>
 /<a href="http://www.zlib.net/">zlib</a> (Zip compression)
 ===libjpeg===
 libjpeg does not ship with VS 2010 projects, so its older project files must first be converted before opening the solution.
 Open a Visual Studio command prompt and navigate to:
 /libjpeg
 and run:
 {{{
 NMAKE /f makefile.vc  setup-v10
 }}}
 This will create all of the necessary project files for libjpeg.
 ===libxml2===
 The libxml2 project is crippled out of the box so it needs some changes before it will open. Further changes will be required later once it's opened.
 Navigate to:
 libxml2\win32
 and find the file configure.js. Right click on it and click Properties. Ensure the default program used to open it is Windows Based Script Host, click Ok. Double click configure.js and you will see several message boxes telling you the project files it created.
 ===OpenCL===
 Install the latest drivers for your video card.
 <ul>
    <li>
 ====nVidia====
 Install the latest <a href="https://developer.nvidia.com/cuda-downloads">CUDA</a> development kit, which will contain un-advertized OpenCL libraries.
 Get the file <a href="http://www.khronos.org/registry/cl/api/1.1/cl.hpp">cl.hpp</a> and place it here:
 C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v5.0\include\CL
    </li>
    <li>
 ====AMD====
 Install the APP SDK.
    </li>
 </ul>
 ===Qt===
 Qt is what Fractorium uses for its GUI. Sadly, the pre-compiled version of Qt cannot be used. Instead, it must be completely rebuilt from source. The reason being that it does not use the desktop OpenGL library and instead uses OpenGL ES. Since Qt is a very large build, you should only do this step if you plan to build the full Fractorium GUI. If you are only interested in the Ember libraries and command line programs, skip this step.
 Further, Qt will not work with Express versions of Visual Studio.
 These instructions roughly follow what's listed <a href="http://qt-project.org/wiki/Building-Qt-5-from-Git">here</a>, however they are a bit more concise.
 Install the <a href="http://qt-project.org/downloads">Visual Studio Qt Add-on</a> found in the Other Downloads section of the Qt downloads page.
 Install <a href="http://msysgit.github.io/">Git</a>, <a href="http://www.activestate.com/activeperl/downloads">Perl</a>, <a href="http://www.python.org/download/releases/">Python</a> and <a href="http://qt-project.org/wiki/jom">Jom</a>.
 Assuming Jom was installed to C:\jom and Python was installed to C:\Python27, add both of these to your PATH variable:
 {{{
 C:\jom
 C:\Python27\DLLs
 }}}
 Open a Visual Studio x64 command prompt and cd to the folder which contains all prerequisites and Fractorium. Enter the following commands:
 {{{
 git clone git://gitorious.org/qt/qt5.git qt5
 cd qt5
 git checkout stable
 }}}
 This will take roughly 15 minutes. After it's done, add these paths to your PATH variable:
 {{{
 /your/dev/dir/qt5/qtbase/bin
 /your/dev/dir/qt5/gnuwin32/bin
 }}}
 Add these environment variables:
 {{{
 QMAKESPEC win32-msvc2010
 QTDIR /your/dev/dir/qt5/qtbase
 }}}
 Enter the following commands to configure and build:
 {{{
 Perl init-repository –no-webkit
 cd qtbase
 configure -developer-build -opensource -shared -opengl desktop -platform win32-msvc2010 -nomake examples -nomake tests
 jom.exe
 }}}
 The jom.exe command is what actually starts the build. Note that you should replace the number 4 with the number of cores on your system. Configuring and building will take roughly one hour.
 Once finished, open Visual Studio and verify there is a menu item named Qt5. Click on it and click Qt Options.
 Add a new Qt version to the list with the exact name of "5.0.1", and set its path to /your/dev/dir/qt5/qtbase
 The name must match exactly and must be created before any Qt solution is opened. If not, the Qt add-in will completely ruin all solution and project files that use Qt.
 Set the default version to the newly created Qt version and click Ok.
 ===Fractorium===
 Next, checkout Fractorium with cvs so that it's on the same level with the other dependencies like so:
 /<a href="https://code.google.com/p/fractorium/source/checkout">fractorium</a>
 /glm
 /libjpeg
 /libpng
 /libxml2
 /qt5
 /tbb
 /zlib
 To build the installer, you must have <a href="http://wixtoolset.org/">Wix</a> installed. If you are unconcerned with it, you can skip this step and just dismiss the warning that shows when opening the solution later.
 ==Opening the Solution==
 Navigate to the subfolder:
 fractorium/Builds/MSVC/VS2010
 and open Fractorium.sln
 If all dependencies were placed in the proper hierarchy, the solution should open with no warnings or errors. However, it's not ready to build yet.
 ==Build Configuration==
 Visual Studio merges all build configurations and platforms from every project in a solution. Because Fractorium has dependencies on other libraries, the configuration manager will show all configurations from all projects in the solution. Most of these can safely be ignored. The only configurations that matter are Debug/Release. The only platforms that matter are Win32/x64.
 Building other configurations and platforms is not advised and is unsupported.
 Despite x64 support in Visual Studio for many years, most third party libraries do not ship with an x64 build target in their project files. You must manually create them here before you can build for x64. If you are only building for Win32, you can skip this step.
 Right click on the solution and open the Configuration Manager.
 Set the configuration to Release, and the platform to x64. Do the following for jpeg, libpng, libxml2, pnglibconf, and zlib:
 -Click the combo box in the platform column on the project's row and select New...
 -Set New Platform to x64, and Copy Settings From to Win32. Click Ok. Note, Visual Studio has a bug where you may need to do this twice for each project. After you click Ok, click the combo box again to verify it worked. If x64 is shown as a valid platform in the list, it worked. If not, you must repeat this step.
 ===Further libxml2 Changes===
 Right click on the libxml2 project and open the properties dialog and click Configuration Properties.
 Navigate to General, select all configurations and all platforms and set the configuration type to Dynamic Library (.dll).
 Set Output Directory to:
 {{{
 $(SolutionDir)$(Platform)\$(Configuration)\
 }}}
 Set Intermediate Directory to:
 {{{
 $(Platform)\$(Configuration)\
 }}}
 and click Apply.
 Navigate to C/C++ | General and make sure these paths are present in the Additional Include Directories for Debug/Release configurations and Win32/x64 platforms, and click Apply:
 {{{
 $(ProjectDir);
 $(ProjectDir)..\..\include;
 }}}
 Navigate to C/C++ | Preprocessor, select All Configurations and All Platforms and add ;WIN32 to the list in Preprocessor Definitions, and click Apply.
 Navigate to Linker | Input, select All Configurations and All Platforms and add ;Ws2_32.lib to the list of Additional Dependencies, and click Ok.
 Find the file /include/libxml/xmlversion.h and comment out line 277:
 {{{
 #define LIBXML_ICONV_ENABLED
 }}}
 because Fractorium doesn't need Iconv support.
 ===zlib Changes===
 Open the file zutil.h, and comment out line 33:
 {{{
 typedef long ptrdiff_t;
 }}}
 The solution is now ready to build. The output will be placed in:
 {{{
 /your/dev/dir/fractorium/Bin/$(Platform)/$(Configuration)
 }}}
--- a/Data/Wiki/CodingPhilosophy.htm
+++ b/Data/Wiki/CodingPhilosophy.htm
@ -1,15 +0,0 @@
 #summary Coding philosophy.
 <font face="Verdana">
 =Introduction=
 The philosophy behind the code contained in this project.
 =Details=
 Code is read many more times than it is written. Therefore, legible code is of high importance. This project makes every effort to write understandable, well designed and well documented code. When a person reads the code for the first time, they should not be blindsided with confusion. Instead, they should be able to navigate and understand the code and project structure relatively quickly.
 Modern language techniques like lambdas, templates and the C++ Standard Template Library can greatly simplify code. These are taken advantage of at every possible opportunity. There is simply no valid reason to use legacy coding styles in a project of this nature.
 This project only supports x64 hardware. Given the prevalence of it and operating systems that support it, as well as the performance boost it gives, there is no reason to continue supporting x86. Much like 16-bit programs have disappeared from the development landscape, 32-bit programs have also had their day.
--- a/Data/Wiki/CommandLinePrograms.htm
+++ b/Data/Wiki/CommandLinePrograms.htm
@ -1,29 +0,0 @@
 #summary User's guide for command line programs.
 <font face="Verdana">
 =Introduction=
 Usage of EmberRender, EmberAnimate and EmberGenome command line programs.
 These are advanced tools mostly used in a scripted environment.
 =Details=
 These programs are replacements for the original flam3-render, flam3-animate and flam3-genome programs. They function the same and produce identical output, however they offer two major advantages over the originals:
 -Option to use OpenCL renderer.<br>
 -Ability to use command line arguments in addition to environment variables. The originals only supported the latter.<br>
 Running any with the `--help` argument will provide a list of the options available to that program.
 More information on the what these do and the options to pass them can be found in the original flam3 documentation here:
 <a href="https://code.google.com/p/flam3/wiki/Flam3Render">EmberRender</a>
 <a href="https://code.google.com/p/flam3/wiki/Flam3Animate">EmberAnimate</a>
 <a href="https://code.google.com/p/flam3/wiki/Flam3Genome">EmberGenome</a>
 The only option omitted was `field` which was used to render progressive scanned images for animations. Modern LCD/LED displays overcome the need for this.
--- a/Data/Wiki/Developers.htm
+++ b/Data/Wiki/Developers.htm
@ -1,9 +0,0 @@
 #summary Information for developers.
 [EmberImplementationDetails Ember]
 [EmberCLImplementationDetails EmberCL]
 [Building Building]
 [CodingPhilosophy Coding Philosophy]
--- a/Data/Wiki/EmberCLImplementationDetails.htm
+++ b/Data/Wiki/EmberCLImplementationDetails.htm
@ -1,266 +0,0 @@
 #summary EmberCL implementation details.
 <font face="Verdana">
 = Introduction =
 EmberCL resides in a separate project that links to Ember and uses OpenCL to perform iteration, density filtering and final accumulation. Xml parsing, interpolation, and palette setup are still performed by the base library on the CPU.
 OpenCL was chosen because it provides run-time compilation and cross platform interoperability, both of which nVidia's CUDA platform lack.
 = Details =
 <ul>
 <li>
 ==OpenCLWrapper==
 OpenCL programming requires a large amount of setup code before getting to the point where a kernel can be invoked. To relieve the programmer of having to deal with such details, a class named `OpenCLWrapper` is provided. It holds all buffers, images, kernel source and compiled programs in memory and automatically frees them as necessary. Each object can be accessed via name string or index in a vector.
 </li>
 <li>
 ==Kernel Creators==
 At the heart of OpenCL is the kernel. It's a small program ran as the body of a number of threads executing in parallel. It takes the form of a text string that is compiled at run-time. The compiled binary output is passed to the device running OpenCL along with various arguments and grid dimensions. The grid is is a 1D, 2D or 3D matrix of blocks, and each block is a 1D, 2D or 3D matrix of threads. A full discussion of OpenCL is beyond the scope of this Wiki.
 EmberCL takes a unique approach to building and running kernels for fractal flame rendering that differs from the other two major OpenCL implementations, flam4 and Fractron. The Single Instruction-Multiple Thread (SIMT) nature of the devices OpenCL runs on suffer from an interesting limitation that CPUs do not suffer from. CPUs are very good at processing conditionals, but are slower at doing calculations. SIMT devices are bad at processing conditionals, but are very fast at doing calculations. Because of this, the EmberCL kernel creators build special versions of kernels for each rendering processing step with the conditionals dynamically stripped out at runtime. This creates highly condensed kernels that only run what is absolutely necessary for the Ember currently being rendered. The drawback of this approach is that if the Ember currently being rendered differs enough from the previous one rendered, an OpenCL recompilation will be triggered. These take from one third to one half of a second on a modern processor.
 <ul>
 <li>
 ===Iteration Kernel===
 The iteration kernel is the most advanced, and most important portion of the EmberCL library. It is here that EmberCL achieves its large performance lead over other OpenCL implementations of the fractal flame algorithm.
 <ul>
 <li>
 ====The Naive Implementation===
 The naive implementation copies the code from the CPU implementation to a kernel and each thread runs it in parallel. This is very inefficient and is an improper use of OpenCL.
 SIMT devices excel at executing the same instruction across multiple threads in a group. On nVidia hardware, this group is known as a warp and is 32 threads wide. On AMD hardware, it's known as a wavefront and is 64 threads wide. They operate at peak efficiency when every thread is executing the same instruction at once. If any threads take a different execution path than the others, then warp divergence occurs. Some threads have to sit idle and wait while others complete their operations until they can all get back in sync. This is a waste of resources and prevents the OpenCL device from achieving its full potential.
 This scenario occurs with the naive implementation. If each thread is choosing random xforms to apply, then they will be diverging from all other threads which picked different xforms. A smarter implementation for randomization is needed when using OpenCL, enter cuburn.
 </li>
 <li>
 ====Randomization Without Warp Divergence====
 Cuburn was the senior project for 4 students at Central Florida University in the fall of 2011. It investigated this exact issue and came up with a novel solution using Python and CUDA. Their solution is implemented and improved on here in OpenCL and is what gives EmberCL its performance advantage. It takes the following form.
 Each iteration  block is 32 threads wide by 8 threads high, giving 256 threads. Each block gets a buffer of on-chip local shared memory with the same dimensions as the block (32x8) to store point iterations to.
 For each iteration, instead of every thread picking a random xform to apply, each row of threads gets a single random xform and all threads in it execute the same xform. The output of each iteration is accumulated to the histogram and also written to a different thread's location within shared memory.
 After each iteration, the process repeats by re-randomizing each row and having each thread use the point at its location in the shared memory buffer, which was the previous output of a different thread, as the input to the xform it applies. This process is repeated 256 times for each thread, giving a total of 65,536 iterations per block.
 The combination of point shuffling and randomizing the xform each row applies on each iteration achieves the goal of eliminating warp divergence while also producing high quality randomization.
 </li>
 <li>
 ====MWC vs ISAAC====
 As mentioned in the Ember description, ISAAC is the RNG used in both Ember and flam3. While performing very well on the CPU, it's a poor choice for OpenCL since it would require a large amount of memory for each thread to keep its own copy. An alternative used in cuburn is the multiply-with-carry RNG. EmberCL uses this as well because it gives good randomization while requiring very little memory. Each block is passed a different seed, and each thread adds its index to the seed to ensure that all threads take a different trajectory when using the RNG.
 </li>
 <li>
 ====Run-time Compilation====
 As mentioned above, one of the key strengths of OpenCL is run-time compilation. EmberCL takes heavy advantage of this at every opportunity to achieve maximum performance. The CPU implementation has many conditional checks during iteration. These include the presence/absence of post affine transforms, final xforms, palette indexing mode, pre-blur variations as well as virtual functions (or a case statement in flam3) to execute each variation. Such a large number of conditionals would be detrimental to OpenCL performance. Run-time compilation allows us to eliminate these completely. Once the `Ember` to be rendered is known, the kernel to render it is dynamically generated with only the necessary parts included and is compiled on the fly.
 </li>
 <li>
 ====Race Conditions====
 One area where EmberCL differs from cuburn is that it does not account for the case of two threads accumulating to the same bucket in the histogram at the same time by default. Cuburn devoted a large portion of the paper to experimenting with every possible way to avoid such a condition. EmberCL ignores these efforts by default because they are mostly unnecessary. The whole point of using the GPU is to get real-time fractal flame rendering, or to make pre-rendered animations more quickly. With animating flames, a few pixels missing a few iteration values will be unnoticeable to the human eye. The small benefit of a clever implementation of such a mechanism is nowhere near being worth the performance hit and additional code complexity. However, is still interested in comparing the differences between locked and unlocked iteration, they can specify the `--lock_accum` argument on the command line for `EmberRender.exe` and `EmberAnimate.exe`. This will prevent race conditions, but will dramatically slow down the performance because the locking is achieved by using software atomic operations which are very slow.
 </li>
 <li>
 ====Compatibility With CPU====
 A concern with GPU implementations of any program originally written for a CPU is that it will not be able to implement every feature from the original. EmberCL addresses these concerns by implementing all other features involved with iteration which were originally implemented on the CPU. These are fusing, opacity, bad value detection, xaos, post affine transforms, final xforms, and step vs linear palette indexing for histogram accumulation.
 <br></br>
 </li>
 </ul>
 </li>
 <li>
 ===Density Filter Kernel===
 As mentioned in the algorithm overview description, density filtering can either be basic log scaling, or a more advanced Gaussian blur filter. EmberCL implements both of these. The former is trivial, the latter is very complex. The extreme difficulty of fully implementing density filtering such that it operates efficiently and also gives identical output to the CPU has prevented it from being done elsewhere. EmberCL overcomes this and is the first full implementation of variable width Gaussian density filtering for fractal flames in OpenCL. Seven different methods were tried, with the fastest being the chosen one. There are two main kernels used for density filtering, one with shared memory and one without.
 <ul>
 <li>
 ====Shared Memory Kernel====
 The shared memory kernel is used for final filter widths of 9 or less with float data types due to the limited space of shared memory. As stated in the algorithm overview, density filtering multiplies the log scaled value at a given histogram bucket by a filter value and adds it to the surrounding pixels in the accumulator. This process repeats for the width of the filter and the scaling values decrease as it moves outward from the pixel being operated on.
 When running on a GPU, these repeated reads and writes to global memory are very slow. A better approach is for each thread to read a pixel from the histogram, and perform filtering to a shared memory buffer. Once all threads in the block have finished, the final result from the shared memory box is written to the accumulator.
 In the EmberCL implementation, each block is 32x32 threads, and the box size of the shared memory is the size of the block plus the width of the filter in each direction. So for the commonly used filter width of 9, the box size would be 32 + 9 x 32 + 9, or 41 x 41. Each block processes a box and exits. No column or row advancements take place.
 The filter is applied in a different manner than on the CPU to avoid race conditions. On the CPU, it's applied from the center pixel outward. In OpenCL, it's applied by row from top to bottom.
 Certain variables were reused because the code is so complex, the card runs out of resources for block sizes greater than 24.
 </li>
 <li>
 ====Non-shared Memory Kernel====
 The non-shared memory kernel is used for double precision data types or for final filter widths of 10 or more. This is commonly the case when supersampling is used because the final filter width is the supersample value times the max density filter radius. It takes roughly the same form as the shared memory kernel, but omits shared memory and deals directly with the histogram and accumulator for all reads and writes. Due to the excessive global memory accesses in this method, it offers no real performance improvement over the CPU.
 </li>
 <li>
 ====Filter Overlapping====
 Both of these methods present a problem when two kernels are operating on an adjacent block of pixels. Although the pixels themselves don't overlap, the filters extending out from the edges of the blocks do overlap. To overcome this, the kernels are launched in multiple passes that are spaced far enough apart vertically and horizontally on the image so as to not overlap.
 </li>
 <li>
 ====Special Supersampling Cases====
 Density filtering performs a few extra calculations depending on the supersample value used. To eliminate conditionals and achieve maximum performance, a separate kernel is built for each of these cases for the shared and non-shared memory cases. This leads to a total of 6 possible kernels being built to cover all scenarios. After being built once, the compiled output is saved for all subsequent renders during a program run.
 <br></br>
 </li>
 </ul>
 </li>
 <li>
 ===Final Accumulation Kernel===
 The implementation of final accumulation in OpenCL is the simplest of the kernels and is copied almost verbatim from the Ember CPU code. To maintain complete compatibility with the CPU, all advanced features such as transparency, early clipping and highlight power are implemented. Like density filtering, unnecessary calculations and conditionals are eliminated by providing different kernels depending on the parameters of the Ember being rendered. They are:
 -Early clipping with transparency.<br></br>
 -Early clipping without transparency.<br></br>
 -Late clipping with transparency.<br></br>
 -Late clipping without transparency.
 All are assumed to have an alpha channel. Three channel RGB output is implemented, but not supported.
 <br></br>
 </li>
 </ul>
 </li>
 <li>
 ==RendererCL==
 The main rendering class in Ember is `Renderer`. EmberCL contains a class  which derives from `Renderer<T>` named `RendererCL<T>` and fully supports both single and double precision data types like the base class does.
 `RendererCL` overrides various virtual functions defined in `Renderer` and implements their processing on the GPU in OpenCL.
 <ul>
 <li>
 ===Shared vs. Un-shared===
 `RendererCL` can operate in two modes, shared and un-shared.
 <ul>
 <li>
 ====Un-shared====
 The final output is rendered to an OpenCL 2D image which no other running program is accessing.
 </li>
 <li>
 ====Shared====
 The final output is rendered to an OpenCL 2D image which another program is also using as an OpenGL 2D texture. This is how interactive rendering is done in the Fractorium GUI. Shared mode benefits from the efficiency of a shared image/texture because no copying is necessary and all outputs remain on the GPU.
 For sharing to work, every call to create, access or destroy the output image must be preceded by a call to acquire the object from OpenGL and followed by a call to release it. These calls are handled internally by `OpenCLWrapper`.
 </li>
 In either of these modes, the output image can be copied back into main memory as needed for use in writing the final output file.
 </ul>
 </li>
 <li>
 ===Parameter Differences===
 A few user configurable properties from `Renderer` are hard coded in `RendererCL` due to how processing is implemented.
 <ul>
 <li>
 ====Thread Count====
 Always considered to be 1, because threading is managed inside the kernels.
 </li>
 <li>
 ====Channels====
 Always 4 because the type of the output image is `CL_RGBA`. Final output file type can only be PNG.
 </li>
 <li>
 ====Bits Per Pixel====
 Always 8, 16bpp for PNG images is only supported in Ember on the CPU.
 </li>
 <li>
 ====Sub Batch Size====
 Always `iterblocksWide * iterblockshigh * 256 * 256` since that is the number of iterations performed in a single kernel call.
 </li>
 </ul>
 </li>
 <li>
 ===Kernel Launching===
 <ul>
 <li>
 ====Iteration Grid Dimensions====
 The iteration kernel is launched in a grid which is 64 blocks wide by 2 blocks high. Each block has 256 (32x8) threads which each perform 256 iterations. This gives 8,388,608 iterations per kernel launch. The grid dimensions were empirically derived and may change in the future as new hardware is released.
 </li>
 <li>
 ====Passing Arguments====
 An `Ember` object cannot be passed directly from the CPU side to an OpenCL kernel. Instead, stripped down versions of the `Ember` object and its filters are created and copied right before each kernel launch and are passed as arguments. However, the palette can be passed verbatim since it's just a 256 element `vector<vec4<float>>`.
 </li>
 <li>
 ====Fusing====
 Fusing is very important for image quality. Omitting it or choosing the wrong value will lead to strange artifacts in the final output image. Since there are so many threads, setting the fuse value is not as simple as just using the same value from the CPU side.
 Forcing each thread to fuse on each kernel call would be a huge waste of resources since each only performs 256 iterations. On the other hand, not fusing often enough after several kernel calls leads to bad image quality. `RendererCL` uses an empirically derived solution of having every thread fuse 100 times for every 4 kernel calls, which is 1024 iterations.
 </li>
 <li>
 ====Recompilation====
 As mentioned above, a custom kernel is created and compiled for every `Ember` that is rendered. However, compilation is not always required if the `Ember` to be rendered does not differ significantly from the previous one rendered. Differences in the following parameters will trigger a recompilation:
 -Xform count.<br></br>
 -Presence/absence of post affine transform.<br></br>
 -Presence/absence of final xform.<br></br>
 -Presence/absence of xaos.<br></br>
 -Step/linear palette indexing mode.<br></br>
 -Variations present in each xform.
 When requesting iteration to commence, the checks above will be made. If any mismatches occur, a recompilation will be triggered right before the kernel launch.
 </li>
 </ul>
 </li>
 </ul>
 </li>
 </ul>
--- a/Data/Wiki/EmberImplementationDetails.htm
+++ b/Data/Wiki/EmberImplementationDetails.htm
@ -1,171 +0,0 @@
 #summary Ember implementation details for developers.
 <font face="Verdana">
 =Introduction=
 This page is intended for developers who wish to get familiar with the Ember code.
 As stated on the main page, the intent of Ember was to re-write the entire flam3 library and the 3 command line programs that use it, in C++. By using modern design and language techniques, a legacy code base was made to be easily understandable to the common programmer. The extensibility of C++ also allows derived projects to implement alternative renderers as they are developed, while still maintaining 100% compatibility with the original. Below are the main design features of Ember and how they compare to the original implementation in flam3.
 Ember takes advantage of a few core language features in C++ that help simplify the coding effort.
 <ul>
 <li>
 ===Templates===
 Since the process of rendering a fractal flame from start to finish is lengthy, it's interesting to experiment with how using different data types affects performance and image quality. flam3 implemented just such a capability, but since C doesn't have the concept of templates, it did something else. It used a tricky method of strategically positioning #include statements after #defines for each type. C++ provides a more elegant solution through the use of template arguments. Ember supports not only changing the data types of the histogram, but of every calculation used in the entire algorithm. Supported types are float and double.
 </li>
 <li>
 ===Lambdas===
 These were added to the standard in C++0x and have been a blessing to those implementing multi-threaded programs ever since. Before that, the traditional threading model required a programmer to butcher their design just to achieve parallelism. Modern C++ offers a vast improvement through the use of lambdas. These allow us to write multi-threaded code while keeping good program design structure in tact. Ember achieves this by using the Intel Threading Building Blocks library for all threading needs.
 </li>
 </ul>
 =Details=
 <ul>
 <li>
 ==Containers==
 Flam3 contained very verbose code for managing seemingly simple memory operations such as keeping a list of xforms. With the C++ Standard Template Library, such code can be greatly reduced. Containers are used extensively throughout Ember, greatly simplifying the code, reducing its verbosity and enhancing its readability.
 </li>
 <li>
 ==Variations==
 In flam3, for any action to be taken on a variation, such as calling it or setting parameters, a massive case statement had to be used. The number of cases equaled the number of variations supported by that build. If a new variation was added, all case statements had to be updated.
 In Ember, this cumbersome burden was alleviated by making each variation a class which derived from a base variation class. Each implements a virtual function which does the processing work. Other virtual functions are used for setting random or default states for parametric variations.
 In Apophysis, users can add variations by compiling their own DLLs. Ember could conceivably support such a feature in the future by having DLLs return pointers to base variation objects that have been instantiated as derived variations. However, no such support has been implemented. For the time being, new variation classes will periodically be added to Ember.
 </li>
 <li>
 ==Iterating==
 Iteration is the portion of the algorithm where the most time is spent. Any possible optimization that can be taken, should be taken within the innermost loops. Flam3 missed a few opportunities to do this, so Ember optimized every last piece to the maximum possible extent.
 <ul>
 <li>
 ===Fusing===
 As stated in the paper, the first 20 iterations are not plotted in order to get a more concentrated image with less stray points. This is somewhat misleading, since the number flam3 actually uses is 15. If early clipping is used, the number of fuse iterations is 100.
 Further deviating from the paper, fusing is not just done at the very beginning. Rather, all iteration is broken up into chunks, or sub batches, of 10,000. At the beginning of each sub batch, the point trajectory is reset, and fused again. Assuming a fuse value of 15 and a sub batch size of 10,000, fusing takes place for 0.0015 of the total iterations.
 For each iteration, flam3 checks to see whether fusing is done yet, if so, the point is plotted. This is wasteful to check for something every iteration that occurs so infrequently. In the interest of maximum efficiency, Ember splits all iteration up into two identical loops, one with fusing and one without. This reduces the number of conditional checks needed.
 A further optimization opportunity was that when a final xform was present, flam3 applied it during fusing, even though the computed point was never used. Ember omits the application of the final xform during fusing.
 </li>
 <li>
 ===Point Assignment===
 The general structure of the iteration loop in flam3 looks like:
 {{{
 p2 = xform(p1)
 save p2 to temp buffer for plotting later
 p1 = p2
 }}}
 This was optimized to omit the assignment from p2 back to p1 for the start of the next iteration. Instead, no temporary points are ever created. Rather, the indices of the temporary buffer to read from and write to are incremented. Further, the buffer is read from and written to directly, alleviating the need for temporary assignments. It roughly takes the form of:
 {{{
 i = 0
 while (i < SubBatchSize)
 {
    xform(buf[i], buf[i + 1])
    i++
 }
 }}}
 </li>
 <li>
 ===Xaos===
 When xaos is used, an additional calculation must be performed to look up the next random xform to apply. Ember bypasses this when xaos is not present by having two separate classes for iteration, one with xaos and one without.
 </li>
 </ul>
 </li>
 <li>
 ==Filtering==
 For density and spatial filtering, a box of pixels is processed. Flam3 accessed pixels in row, column order. This is cache inefficient because every pixel access is on a different row. Ember optimizes filtering by processing in a more cache-friendly column, row order.
 While flam3 parallelized the Gaussian density filtering, it did not do so for basic log scale filtering (max radius = 0). While this method is seldom used for a final output image, it is used for interactive renders to give a preview image before full iteration is complete. In an effort to give a more responsive GUI, Ember parallelized this method.
 During an interactive render, the only parameters that are usually changing are the affine transforms. Because this doesn't affect many of the other parameters used to render, intelligent checks are used to skip any unnecessary memory allocations each time the main render function is called. This technique is used with density and spatial filters to only recreate them if the requested filter differs from the one previously used.
 </li>
 <li>
 ==Incremental Rendering==
 Ember is designed to be run from the command line, or from an interactive GUI. To facilitate the latter, the rendering process keeps state information about its progress. This is done so that it can be aborted in mid-render, and resumed later on. It also serves to ensure the minimum amount of processing is performed in response to a change in the `Ember` being rendered. For example, if a render completes and the user only wants to change the vibrancy, then only final accumulation needs to be ran again. Another feature is that if a render completes and the user increases the quality, all previous iteration information is preserved in the histogram and the new iterations for the quality difference are simply added to them.
 The downside of this design is that it admittedly butchers the structure of the main rendering function with numerous conditionals. The cost is worth it as the state-preserving design greatly facilitates interactive rendering from a GUI.
 </li>
 <li>
 ==Final Accumulation==
 This stage is where color correction and spatial filtering are done. Flam3 did not multi-thread this step because the percentage of the total time spent here is small. Ember easily parallelized it with the aforementioned use of lambdas and TBB. While inconsequential in a headless render, it's very helpful in providing more responsiveness in an interactive render.
 The process was further optimized by eliminating many of the redundant assignments and bounds checks that flam3 did.
 </li>
 <li>
 ==Xml Parsing==
 While not much of a speed bottleneck, Xml parsing can take some time if reading in a large file, such as is used for animations. Flam3 implemented this in the least efficient manner possible by reading a single character at a time. Ember does this much faster by reading the entire file at once. The structure of the Xml parsing functions remains mostly the same.
 </li>
 <li>
 ==Affine Transforms==
 In every iteration, these are applied before, and optionally after, variations are applied. Flam3 treated them as an array of 6 coefficients arranged in column, row order. Ember puts them in a class called Affine2D so they can be accessed more clearly using their coefficient labels, A-F. The layout of the two is like so:
 flam3: 3 columns of 2 rows each. Accessed col, row.
 {{{
 [a(0,0)][b(1,0)][c(2,0)]
 [d(0,1)][e(1,1)][f(2,1)]
 }}}
 Ember: 2 columns of 3 rows each. Accessed col, row.
 {{{
 [a(0,0)][d(1,0)]
 [b(0,1)][e(1,1)]
 [c(0,2)][f(1,2)]
 }}}
 </li>
 <li>
 ==Matrices==
 All matrices and vectors are from the glm library and receive the same template argument used to create the classes they're used in.
 </li>
 <li>
 ==Random Numbers==
 Randomization is at the heart of the fractal flames algorithm. Flam3 used the ISAAC random number generator. Ember does the same, but uses a C++ version with a few additional convenience functions added.
 The flam3 method of using a buffer to hold xform indices to randomly select is also used in Ember. However, flam3 made each element an unsigned short. Since an Ember will have nowhere near 256 xforms, the elements were made to be 1 byte each in an effort to make the buffer fit into the cache better.
 </li>
 </ul>
--- a/Data/Wiki/FinalRenderDialog.htm
+++ b/Data/Wiki/FinalRenderDialog.htm
@ -1,229 +0,0 @@
 #summary Final render dialog
 <font face="Verdana">
 =Final Render Dialog=
 This dialog allows the user to render flames to an output file. It can render either the current flame, or all
 open flames. When rendering all, they can either be treated as individual images, or as frames in an animation. If the
 later is chosen, temporal samples are used to achieve motion blur. All values specified here will be saved between program runs.
 Before rendering begins, the current flame will be saved back to the opened file in memory.
 Miscellaneous messages are shown in the bottom text box.
 <ul>
    <li>
        ==Early Clip==
        Whether to apply color correction before spatial filtering. It's recommended to only use this if the colors don't look right.
        A more thorough discussion of early clip from the original flam3 documentation is <a href="https://code.google.com/p/flam3/wiki/NewFeatures">here</a>.
    </li>
    <li>
        ==Transparency==
        Whether the empty pixels in the image should be transparent, or use the background color. This only applies when saving as PNG.
    </li>
    <li>
        ==Use OpenCL==
        Whether to use OpenCL in the rendering process. It is highly recommended that you use this if your video card supports it.
    </li>
    <li>
        ==Use Double Precision==
        Whether to use double precision numbers in the rendering process. This will slow down the render and double the memory usage, but will produce a better looking image in some cases.
    </li>
    <li>
        ==Save Xml==
        Whether to also save the Xml of every rendered image in the same folder the image is saved.
    </li>
    <li>
        ==Render All==
        Whether to render all currently opened flames, or just the current one. When checked, image and Xml output names will be auto generated.
    </li>
    <li>
        ==Render as Animation Sequence==
        When Render All is checked, whether to use the Temporal Samples value specified to create motion blurring. Disabled if Render All is unchecked.
    </li>
    <li>
        ==Keep Aspect Ratio==
        Whether to keep the aspect ratio of the final output image the same as the original flame. When checked, changing the value of one of the dimensions
        will cause the other dimension to change a corresponding amount times the aspect ratio of the original.<br></br>
        The original dimensions will be those of the render preview window if the flame originated in Fractorium.
        If the flame originated from a file or pasted Xml, the original dimensions will be whatever was specified in those parameters.
    </li>
    <li>
        ==Scale==
        The scaling method to use. This is used to adjust the zoom specified in the scale parameter based on the difference between the original image dimensions and the final image dimensions.
        <ul>
            <li>
                ===None===
                Do not adjust the scale parameter in response to the difference between the original dimensions and the final dimensions. This is useful for cropping without zooming.
            </li>
            <li>
                ===Width===
                Scale the scale parameter by the percentage difference between the original width and the final width.
            </li>
            <li>
                ===Height===
                Scale the scale parameter by the percentage difference between the original height and the final height.
            </li>
        </ul>
    </li>
    <li>
        ==Render All Extension==
        The image type to use when Render All is checked. Disabled if Render All is unchecked.
    </li>
    <li>
        ==OpenCL Platforms==
        The available OpenCL platforms on the system. Disabled if Use OpenCL is unchecked.
    </li>
    <li>
        ==OpenCL Device==
        The available devices on the currently selected platform. Disabled if Use OpenCL is unchecked.
    </li>
    <li>
        ==Threads==
        The number of threads to use when using the traditional CPU renderer. Disabled if Use OpenCL is unchecked.
        Range: 1 - number of cores.
    </li>
    <li>
        ==Width==
        The width of the final output image.
        Range: 10 - 100,000.
    </li>
    <li>
        ==Height==
        The height of the final output image.
        Range: 10 - 100,000.
    </li>
    <li>
        ==Quality==
        The quality of the final output image. Values above 500 don't offer noticeable improvement.
        Range: 1 - 200,000.
    </li>
    <li>
        ==Temporal Samples==
        The temporal samples to use when applying motion blur. A value of 1000 is recommended. Only used when Render as Animation Sequence is checked, otherwise a value of 1 is internally used.
        Range: 1 - 5,000.
    </li>
    <li>
        ==Supersample==
        The value to multiply the dimensions of the histogram and density filter buffer by to help eliminate jagged lines.
        Values greater than one will greatly impact performance and will increase memory usage. See the Memory Usage field for the effect.
        While a value of 2 offers some visual improvement, values greater than 2 don't offer noticeable improvement.
        Range: 1 - 4.
    </li>
    <li>
        ==Memory Usage==
        The amount of memory required for the the entire render, which is the histogram, density filtering buffer and final image.
    </li>
    <li>
        ==Output==
        The file to save a single image render to, or the folder to save multiple image renders to. This is set by clicking the ... button.
        Clicking Open will open the folder location in an explorer window.
    </li>
    <li>
        ==Prefix==
        The prefix to prepend to all image and Xml files.
    </li>
    <li>
        ==Suffix==
        The suffix to append to all image and Xml files.
    </li>
    <li>
        ==Total Progress==
        The percentage of the entire rendering process which has completed.
    </li>
    <li>
        ==Iteration==
        The percentage of the iteration step in the current image render which has completed.
    </li>
    <li>
        ==Density Filtering==
        The percentage of the density filtering step in the current image render which has completed.
    </li>
    <li>
        ==Final Accumulation==
        The percentage of the final color correction and spatial filtering step in the current image render which has completed. This is almost always instantaneous.
    </li>
    <li>
        ==Start==
        Begin the rendering process. If a render is already running, it will stop it first.
    </li>
    <li>
        ==Stop==
        Stop the rendering process.
    </li>
    <li>
        ==Close==
        Stop the rendering process, close the dialog and return to the main window.
    </li>
 </ul>
--- a/Data/Wiki/FlameTab.htm
+++ b/Data/Wiki/FlameTab.htm
@ -1,319 +0,0 @@
 #summary Flame tab
 <font face="Verdana">
 =Flame Tab Item Descriptions=
 <ul>
    <li>
        ==Color==
        These settings affect color. There is no set combination to make a perfect image. Once you've settled on a design you like,
        play with different color combinations to give it the desired final look.
        <ul>
            <li>
                ===Brightness===
                The brightness of the final output image.
                Range: 0.05 - 50.
                Render State: Density filtering.
            </li>
            <li>
                ===Gamma===
                The gamma of the final output image. Higher values will give better color, but will reveal more scattered points.
                Lower values will reduce scattered points but will wash the colors out to white.
                Range: 1 - 9999.
                Render State: Final accumulation.
            </li>
            <li>
                ===Gamma Threshold===
                The gamma threshold of the final output image. Higher values will reduce scattered points, but will also reduce color quality.
                Lower values will reveal more scattered points, but give better color. 
                Range: 0 - 10.
                Render State: Final accumulation.
            </li>
            <li>
                ===Vibrancy===
                The scale factor to apply to the alpha channel log scaling when gamma correcting the final output image. Higher values will
                give more saturated colors. Lower values will wash the colors out to white.
                Range: 0 - 1.
                Render State: Final accumulation.
            </li>
            <li>
                ===Highlight Power===
                The highlight power of the final image. Set this to a value greater than zero if the colors don't look right.
                A more thorough discussion of highlight power from the original flam3 documentation is <a href="https://code.google.com/p/flam3/wiki/HighlightPower">here</a> and <a href="https://code.google.com/p/flam3/wiki/NewFeatures">here</a>.
                Range: -1 - 2.
                Render State: Final accumulation.
            </li>
            <li>
                ===Background===
                The background color of the image. Ignored on the final image output if transparency is used.
                Range: 0-255 for RGB.
                Render State: Full render.
            </li>
            <li>
                ===Palette Mode===
                The mode used for palette indexing when accumulating to the histogram.
                Step: If the specified palette index is a fraction, round down to the nearest integer.
                Linear: Blend the specified index with the one after it.
                Render State: Full render.
            </li>
        </ul>
    </li>
    <li>
        ==Geometry==
        <ul>
            <li>
                ===Width===
                The width in pixels of the viewable area. Read only.
            </li>
            <li>
                ===Height===
                The height in pixels of the viewable area. Read only.
            </li>
            <li>
                ===Center X===
                The center offset of the camera. The image will move in the opposite direction on the X axis.
                Range: -10 - 10.
                Render State: Full render.
            </li>
            <li>
                ===Center Y===
                The center offset of the camera. The image will move in the opposite direction on the Y axis.
                Range: -10 - 10.
                Render State: Full render.
            </li>
            <li>
                ===Scale===
                The number of pixels in the final image that correspond to the distance from 0 to 1 in the Cartesian rendering plane.
                Increasing zooms in, decreasing zooms out. Quality is not scaled when this value is adjusted, so increased values
                will degrade the final image quality.
                Range: 10 - 3000.
                Render State: Full render.
            </li>
            <li>
                ===Zoom===
                The zoom level of the final image. Quality is scaled when this value is adjusted, so rendering time is greatly increased.
                Range: 0 - 5.
                Render State: Full render.
            </li>
            <li>
                ===Rotate===
                The rotation of the final image.
                Range: -180 - 180.
                Render State: Full render.
            </li>
        </ul>
    </li>
    <li>
        ==Filter==
        <ul>
            <li>
                ===Spatial Filter Width===
                The width of the spatial filter applied to the final image.
                Range: 0.1 - 10.
                Render State: Full render.
            </li>
            <li>
                ===Spatial Filter Type===
                The type of the spatial filter applied to the final image.
                Render State: Full render.
            </li>
            <li>
                ===Temporal Filter Width===
                The width of the temporal filter used during animation. This value has no effect on the
                interactive renderer, however it's stored in the Xml when saved.
                Render State: Unchanged.
            </li>
            <li>
                ===Temporal Filter Type===
                The type of the temporal filter used during animation. This value has no effect on the
                interactive renderer, however it's stored in the Xml when saved.
                Render State: Unchanged.
            </li>
            <li>
                ===DE Filter Min Radius===
                The minimum filter radius to use when performing density filtering. Increasing this value
                will add additional blurring even in high density areas, which is generally undesirable. This must
                always be less than or equal to the DE max radius.
                A more thorough discussion of density filtering from the original flam3 documentation is <a href="https://code.google.com/p/flam3/wiki/DensityEstimation">here</a>.
                Range: 0 - 25.
                Render State: Full render.
            </li>
            <li>
                ===DE Filter Max Radius===
                The maximum filter radius to use when performing density filtering. Increasing this value
                will add additional blurring only to low density areas, which is generally desirable. This must
                always be greater than or equal to the DE min radius.
                When using OpenCL, if this value multiplied by the supersample is greater than 9, the performance
                of density filtering will drop to that of the CPU. This is because a filter size greater than 9
                cannot fit into local shared memory.
                Range: 0 - 25.
                Render State: Full render.
            </li>
            <li>
                ===DE Curve===
                The speed with which the density filter values decrease when moving away from the center pixel
                being filtered. This value will almost never need to be anything other than the default of 0.40.
                Range: 0.01 - 5.
                Render State: Full render.
            </li>
        </ul>
    </li>
    <li>
        ==Iteration==
        <ul>
            <li>
                ===Passes===
                The number of steps to break iteration into, applying density filtering each time.
                This value should never be anothing other than one and will most likely be removed in a future release.
                Range: 1 - 3.
                Render State: Full render.
            </li>
            <li>
                ===Temporal Samples===
                The number of temporal samples used to blend between frames during animation. This value has no effect on the
                interactive renderer, however it's stored in the Xml when saved.
                Range: 1 - 5,000.
                Render State: Unchanged.
            </li>
            <li>
                ===Quality===
                The number of iterations per pixel in the final output image. Suggested values:
                CPU, Interactive: 10
                OpenCL, Interactive: 20 - 60
                Final Render: 2000+
                Values greater than 2000 don't offer much noticeable improvement.
                Range: 1 - 200,000.
                Render State: Full render.
            </li>
            <li>
                ===Supersample===
                The value to multiply the dimensions of the histogram and density filter buffer by
                to help eliminate jagged lines. During interactive editing, it should always be one,
                and should only be increased when preparing for a final render. Values greater than one
                will greatly impact performance and will increase memory usage.
                While a value of 2 offers some visual improvement, values greater than 2 don't offer noticeable improvement.
                Range: 1 - 4.
                Render State: Full render.
            </li>
            <li>
                ===Affine Interpolation===
                The method to use when interpolating affine transforms during animation. This value has no effect on the
                interactive renderer, however it's stored in the Xml when saved.
                Render State: Unchanged.
            </li>
            <li>
                ===Interpolation===
                The method to use when interpolating flames during animation. This value has no effect on the
                interactive renderer, however it's stored in the Xml when saved.
                Render State: Unchanged.
            </li>
        </ul>
    </li>
 </ul>
--- a/Data/Wiki/FractoriumUserGuide.htm
+++ b/Data/Wiki/FractoriumUserGuide.htm
@ -1,159 +0,0 @@
 #summary User's guide for Fractorium.
 <font face="Verdana">
 =Introduction=
 Fractorium is a fractal flame editor written in C++ with the Qt library. It uses Ember and EmberCL to perform all rendering.
 The intent of Fractorium is to create an editor which has a cleaner interface, easier usage and better performance than any currently available in order to provide the artist with the best possible experience.
 <br></br>
 =Details=
 <ul>
    <li>
        ==General Usage==
        Fractorium aims to allow the artist maximum creative freedom with the minimal possible effort. To achieve this, the entire program was designed to be used with a mouse containing two buttons and a wheel. Using Fractorium with a less capable input device will most likely be cumbersome and is not supported.
        In keeping with the idea of minimizing effort, a novel feature is that the user need not click in the spinners or combo boxes they are editing. Rather, just hover over them and scroll the mouse wheel. Almost every control in the program is designed to be altered with the mouse wheel. Scrolling it only applies to the control the mouse is hovering over. Once the mouse moves away from the control, it loses focus and mouse wheel scrolling no longer applies to it.
        In addition to being designed for a mouse, the user is also meant to have one hand on the keyboard with their fingers on the shift, ctrl and alt keys.
        Most controls have a default non-zero value. Fractorium makes it easy for the user to switch back and forth between a default value and a reasonable non-default value. Just double click in any control with a default value and you will see the value change to a reasonable non-default value. Double click again and it will change back to the default.
        If you need to enter a specific value with finer granularity than is provided by double clicking or mouse wheel scrolling, you can enter it by hand. Select the text of the control and type in it while the mouse is still hovering over it. Be careful not to move the mouse away, because it will cause the control to lose focus.
        Note that all rendering is done without locking the histogram. While this is theoretically imperfect, it doesn't seem to have any visual impact. An option to control this may be revisited later.
    </li>
    <li>
        ==Usage Tips==
        A responsive interface has the highest positive impact on user experience. These tips will help get you running in the best possible configuration for your hardware.
        The first step is to enable OpenCL in the options if your video card supports it. This will give incredibly fluid real-time feedback while editing transforms.
        When running with OpenCL enabled, you may find the movement is a little bit jerky if you have a fast card. This is a case of running "too fast". The jerkiness comes from the fact that your card is so fast that it's completing the render in between every mouse movement and is attempting to perform full Gaussian density filtering which can be slow. To avoid this jerkiness, increase the quality slightly to a value between 20 and 50. This will cause the render to take long enough such that full density filtering will not be performed between rapid mouse movements.
        If OpenCL does not work, and you are forced to use the CPU, keep your quality setting on 10. This will give reasonably responsive feedback.
        Regardless of the renderer type being used, do not increase the quality to a high value until your design is solid enough to be ready for a final render. Keep the quality low until you are sure you've got something you want to keep.
        You can optionally select single or double precision numbers. Single is much faster and is highly recommended. Double will produce better image quality but is so slow that it is only recommended when doing a final render.
        Never use supersampling during interactive rendering. It won't produce any noticeable improvement in quality and will greatly slow down performance. Only use it if you want to determine if it will help a final render look better. After experimenting with values greater than one, always restore supersample to one when finished. As a general rule, values higher than 2 don't add any benefit.
        For each mouse movement, a number of iterations are ran before displaying a preview image. This value is controlled by the sub batch count option. Separate values are allowed for CPU and OpenCL. Increase these to get a better preview, decrease them to get more responsive feedback.
        By default, preview images for mouse movements are scaled using basic log density scaling. Only when iteration has fully completed after the mouse is held still is full Gaussian density filtering performed. If you have an extremely fast processor or video card, try setting the filtering method to Full DE. This will perform full Gaussian density filtering on every mouse movement. The processing cost is high, but the feedback is stunning.
        The circles shown on the main display are the affine transforms for each xform. Dragging them around is how most editing is done. Holding down certain keys can alter the effect dragging has on them.
        To get an existing Xml file open in the editor, you can either select it by clicking the File | Open menu, or by dragging and dropping the file onto the window.
        <ul>
            <li>
                ====No Keys====
                X & Y: Rotate and Scale.
                Center: Move.
            </li>
            <li>
                ====Shift====
                X & Y: Rotate only.
                Local Pivot:
                Center: Rotate around 0,0, while keeping local orientation fixed.
                World Pivot:
                Center: Rotate around 0,0, also rotating local orientation.
            </li>
            <li>
                ====Control====
                X, Y and Center: Snap current movement to grid.
            </li>
            <li>
                ====Alt====
                X & Y: Free movement.
                Center: No effect.
            </li>
            <li>
                ====Shift + Alt====
                Local Pivot:
                X & Y: Rotate around transform center.
                Center: No effect.
                World Pivot:
                X & Y: Rotate around 0,0.
                Center: No effect.
            </li>
        </ul>
        Dragging the image with the right mouse button rotates and scales.
        Dragging the image with the middle mouse button pans.
    </li>
    <li>
        ==Parameter Descriptions==
        Behavior and recommended usage of all UI elements.
        [Menus Menus]<br></br>
        [Toolbar Toolbar]
        <ul>
            <li>
                ===Tabs===
                <ul>
                    <li>
                        [FlameTab Flame]<br></br>
                    </li>
                    <li>
                        [XformsTab Xforms]<br></br>
                    </li>
                    <li>
                        [PaletteTab Palette]<br></br>
                    </li>
                    <li>
                        [LibraryTab Library]<br></br>
                    </li>
                    <li>
                        [InfoTab Info]<br></br>
                    </li>
                </ul>
            </li>
            <li>
                ===Dialogs===
                <ul>
                    <li>
                        [FinalRenderDialog Final Render]<br></br>
                    </li>
                    <li>
                        [OptionsDialog Options]<br></br>
                    </li>
                    <li>
                        [AboutDialog About]<br></br>
                    </li>
                </ul>
            </li>
        </ul>
    </li>
 </ul>
--- a/Data/Wiki/InfoTab.htm
+++ b/Data/Wiki/InfoTab.htm
@ -1,45 +0,0 @@
 #summary Info tab
 <font face="Verdana">
 =Info Tab Item Descriptions=
 <ul>
    <li>
        ==Histogram Bounds==
        When the histogram is allocated before starting a render, it does not have the exact dimensions the user requested. Instead, it is slightly larger
        to allow for filter padding around the edges. The box helps the user understand the relationship between the Cartesian space the histogram represents and the
        dimensions of the memory allocated for it. This is mostly of engineering interest.
        The corners going clockwise from the top left correspond to the bounds of the Cartesian space the histogram represents. They are upper left,
        upper right, lower right, lower left.
        The values in the middle of the top and left sides of the box represent the height and width of the histogram in memory.
        <ul>
            <li>
                ===Gutter===
                The amount of padding added to the edges of the histogram to allow for filtering.
            </li>
            <li>
                ===DE Box Dimensions===
                The size of the density filtering box used, with the pixel being filtered in the center. This value is used in calculating the gutter.
            </li>
        </ul>
    </li>
    <li>
        ==File Opening==
        If there were any warnings or errors opening a file, the details will be displayed here.
    </li>
    <li>
        ==Rendering==
        If there were any problems creating a renderer, or finishing the rendering process, the details will be displayed here.
    </li>
 </ul>
--- a/Data/Wiki/LibraryTab.htm
+++ b/Data/Wiki/LibraryTab.htm
@ -1,34 +0,0 @@
 #summary Library tab
 <font face="Verdana">
 =Library Tab Item Descriptions=
 <ul>
    <li>
        ==Current Flame File==
        This shows a list of all flames present in the currently opened file, or randomly generated flock. When editing, the latest updates to the
        current flame will not be saved back to this list in memory, and the preview will not be updated, unless the user specifically does so. This allows restoration of the original flame
        if needed.
        The entire file will not be saved back to disk unless the user specifically does so.
        <ul>
            <li>
            ===Single click===
            Edit the name of the selected flame. This will be used as the name within the Xml file when the user saves it back to disk.
            Render State: Unchanged.
            </li>
            <li>
            ===Double click===
            Set the flame as the current one. This will overwrite any edits currently pending, so be sure to save them first before switching between flames. This will also reset the undo list.
            Render State: Full render.
            </li>
        </ul>
    </li>
 </ul>
--- a/Data/Wiki/MainPage.htm
+++ b/Data/Wiki/MainPage.htm
@ -1,101 +0,0 @@
 =Description=
 <font face="Verdana" size="2">
 A Qt-based fractal flame editor which uses a C++ re-write of the flam3 algorithm named Ember and a GPU capable version named EmberCL which implements a portion of the cuburn algorithm in OpenCL.
 </font>
 <br></br>
 ==Installer (0.3.7.2 Beta)==
 <font face="Verdana" size="2">
 <a href="https://drive.google.com/file/d/0Bws5xPbHJph6TThVOHdUZUxVM00/edit?usp=sharing">Windows 7 64-bit Installer</a>
 </font>
 <br></br>
 ==Documentation==
 <font face="Verdana" size="2">
 Get started <a href="https://code.google.com/p/fractorium/wiki/ProjectOverview">here</a>.
 </font>
 <br></br>
 ==Requirements and Prerequisites==
 <font face="Verdana" size="2">
 Windows 7, 64-bit
 Install the latest drivers for your video card
 An nVidia or AMD video card to take advantage of OpenCL
 If you have an Intel processor, but do not have a device capable of running OpenCL, and still want to run Fractorium with only CPU support, you must install Intel's CPU-only OpenCL libraries <a href="http://registrationcenter.intel.com/irc_nas/3608/intel_sdk_for_ocl_applications_2013_r2_runtime_x64_setup.msi">here</a>.
 </font>
 <br></br>
 ==Running==
 <font face="Verdana" size="2">
 Fractorium and its associated command line tools can render fractal flames using the CPU, or OpenCL. In order to use OpenCL, you must have an nVidia card that has the Fermi architecture or later, or a recent AMD card. If you attempt to use an unsupported card, you will receive an error message and the CPU renderer will be used instead.
 </font><br></br>
 ==Current Status==
 <font face="Verdana" size="2">
 Initial beta releases supporting the following:
 ===Hardware:===
 -CPU: x64 Intel and AMD CPUs.
 -GPU: Recent AMD and nVidia (Fermi and later) cards.
 ===Variations:===
 -The 98 standard variations included with flam3.
 ===Palettes:===
 -The 700 palettes included in the standard flam3-palettes.xml file.
 ===Data Types:===
 -Single and double precision floating point numbers on both the CPU and the GPU.
 ===Compilers:===
 -Microsoft Visual Studio 2010 SP1 (project files upgrade-able to 2012).
 ===Operating Systems:===
 -Windows 7 x64.
 </font>
 ==Future Direction==
 <font face="Verdana" size="2">
 Help is needed and welcome for implementing the following features:
 -Support for Intel and AMD APU chips.
 -More variations from Apophysis.
 -Support for other compilers, such as gcc and MingW.
 -Support for other operating systems, Mac and Linux.
 -Conversion of OpenGL calls to shader programs.
 -Implementation of more alternative rendering methods.
 -Standalone animator/music visualizer.
 -Benchmarking suite.
 </font><br></br>
 ==Gratitude==
 <font face="Verdana" size="2">
 A sincere thanks to the following people.
 Code and theory questions:
 Scott Draves
 Erik Reckase
 Steve Robertson
 Mike Thiesen
 Testing:
 Richard Vollebregt
 Tai
 </font>
--- a/Data/Wiki/Menus.htm
+++ b/Data/Wiki/Menus.htm
@ -1,214 +0,0 @@
 #summary Menus
 <font face="Verdana">
 =Menu Item Descriptions=
 <ul>
    <li>
        ===Menu===
        <ul>
            <li>
                ====File====
                <ul>
                    <li>
                        =====New Flock=====
                        Create a new set of 10 randomly generated flames and set the first one as the current flame. This will clear whatever is currently open.
                        Render State: Full render.
                    </li>
                    <li>
                        =====New Empty Flame=====
                        Add a new empty flame to the end of the open flames and set it as the current flame.
                        Render State: Full render.
                    </li>
                    <li>
                        =====New Random Flame=====
                        Add a new random flame to the end of the open flames and set it as the current flame.
                        Render State: Full render.
                    </li>
                    <li>
                        =====Copy Flame=====
                        Add a copy of the current flame to the end of the open flames and set it as the current flame.
                        Render State: Full render.
                    </li>
                    <li>
                        =====Open=====
                        Open a flame Xml file. This will clear whatever is currently open.
                    </li>
                    <li>
                        =====Save Current as Xml=====
                        Save the current flame to an Xml file. If it has not yet been saved, a file save dialog will be shown. On subsequent saves, no dialog will be shown
                        and it will use the filename specified the first time the dialog was shown.
                    </li>
                    <li>
                        =====Save Entire File as Xml=====
                        Save the all currently open flames to a single Xml file. If it has not yet been saved, a file save dialog will be shown. On subsequent saves, no dialog will be shown
                        and it will use the filename specified the first time the dialog was shown.
                    </li>
                    <li>
                        =====Save Current Screen=====
                        Save the current screen to an image file.
                    </li>
                    <li>
                        =====Save Current To Open File=====
                        Save the current flame back to the open flame list in memory. This does not save anything to disk.
                    </li>
                    <li>
                        =====Exit=====
                        Exit the program. Save all current work before exiting.
                    </li>
                </ul>
            </li>
            <li>
                ====Edit====
                <ul>
                    <li>
                        =====Undo=====
                        Revert to the previous edit. The undo list is updated upon completion of the rendering process, when not traversing the undo list.
                        If an edit is made while traversing the list, the list is cleared.
                        Render State: Full render.
                    </li>
                    <li>
                        =====Redo=====
                        If traversing the undo list, move forward to the next edit.
                        Render State: Full render.
                    </li>
                    <li>
                        =====Copy Xml=====
                        Copy the current flame as an Xml to the clipboard.
                    </li>
                    <li>
                        =====Copy All Xmls=====
                        Copy all flames in the currently opened file as Xmls to the clipboard.
                    </li>
                    <li>
                        =====Paste Xml Append=====
                        Paste the current clipboard text as a flame appended to the list of currently opened flames.
                        Render State: Full render.
                    </li>
                    <li>
                        =====Paste Xml Over=====
                        Paste the current clipboard text over the list of currently opened flames. This will clear whatever is currently open.
                        Render State: Full render.
                    </li>
                </ul>
            </li>
            <li>
                ====Tools====
                <ul>
                    <li>
                        =====Add Reflective Symmetry=====
                        Add an xform that will reflect the image along the Y axis. This is accomplished by giving the xform a weight of one, color speed of 0 and
                        a single linear variation with a weight of one. Its affine is centered on 0,0 with X at -1,0 and Y at 0,1.
                        Render State: Full render.
                    </li>
                    <li>
                        =====Add Rotational Symmetry=====
                        Add an xform that will duplicate a rotated portion of the image along the Y axis. This is accomplished by giving the xform a weight of one, color speed of 0 and
                        a single linear variation with a weight of one. Its affine is centered on 0,0 with X at -1,0 and Y at 0,-1.
                        Render State: Full render.
                    </li>
                    <li>
                        =====Add Reflective and Rotational Symmetry=====
                        Add two xforms, one for reflective symmetry and another for rotational symmetry.
                        Render State: Full render.
                    </li>
                    <li>
                        =====Clear Flame=====
                        Clear the current flame such that it only has one xform with no variations, pre and post affine transforms set to the identity matrix, and no xaos.
                        Render State: Full render.
                    </li>
                    <li>
                        =====Render Previews=====
                        Re-render all previews.
                    </li>
                    <li>
                        =====Stop Rendering Previews=====
                        Stop rendering previews.
                    </li>
                    <li>
                        =====Final Render=====
                        Display the final rendering dialog. This will stop the render, and restart it from the beginning when the dialog is closed.
                        Render State: Full render.
                    </li>
                    <li>
                        =====Options=====
                        Display the options dialog. This will stop the render, and restart it from the beginning when the dialog is closed.
                        Render State: Full render.
                    </li>
                </ul>
            </li>
            <li>
                ====Help====
                <ul>
                    <li>
                        =====About=====
                        Show the about box which gives a description, version, and licensing information about the code this project uses.
                    </li>
                </ul>
            </li>
        </ul>
    </li>
 </ul>
--- a/Data/Wiki/OptionsDialog.htm
+++ b/Data/Wiki/OptionsDialog.htm
@ -1,178 +0,0 @@
 #summary Options Dialog
 <font face="Verdana">
 =Options=
 Options to use in various parts of Fractorium.
 <ul>
    <li>
        ==Interactive Rendering==
        Options used when editing flames and displaying them in the output window.
        <ul>
            <li>
                ===Early Clip===
                Whether to apply color correction before spatial filtering. It's recommended to only use this if the colors don't look right.
                A more thorough discussion of early clip from the original flam3 documentation is <a href="https://code.google.com/p/flam3/wiki/NewFeatures">here</a>.
            </li>
            <li>
                ===Transparency===
                This has no effect since the output window will always have the same color as the flame's specified background color.
            </li>
            <li>
                ===Use OpenCL===
                Whether to use OpenCL in the rendering process. It is highly recommended that you use this if your video card supports it.
            </li>
            <li>
                ===Use Double Precision===
                Whether to use double precision numbers in the rendering process. This will slow down the render and double the memory usage, but will produce a better looking image in some cases. It is recommended you don't use this for interactive rendering on the GPU unless you have an extremely fast graphics card with double precision support.
            </li>
            <li>
                ===OpenCL Platforms===
                The available OpenCL platforms on the system. Disabled if Use OpenCL is unchecked.
            </li>
            <li>
                ===OpenCL Device===
                The available devices on the currently selected platform. Disabled if Use OpenCL is unchecked.
            </li>
            <li>
                ===Threads===
                The number of threads to use when using the traditional CPU renderer. Disabled if Use OpenCL is unchecked.
                Range: 1 - number of cores.
            </li>
            <li>
                ===CPU Sub Batch===
                The number of sub batches of 10,000 iterations to run on each mouse movement. Values between 1 and 10 are recommended.
                Higher values give better preview images, but a less responsive UI. Decrease this value if you have a slower processor.
            </li>
            <li>
                ===OpenCL Sub Batch===
                The number of sub batches of ~8 million iterations to run on each mouse movement. Values between 1 and 3 are recommended.
                Higher values give better preview images, but a less responsive UI. Decrease this value if you have a slower video card.
                Note that since the sub batch size for the OpenCL renderer is so large, low quality renders can complete on the first sub batch. In that case, 
                full density filtering will be performed, which can give a choppy UI. In such cases, increase the quality a bit.
            </li>
            <li>
                ===CPU Filtering===
                The type of filtering to perform for preview renders on each mouse movement when using the CPU renderer. Log scaling is recommended for all but the fastest processors. However, if
                you have a very fast processor and want to see a more realistic representation of what the final output image will look like on every mouse movement, select
                the Full DE option.
            </li>
            <li>
                ===OpenCL Filtering===
                The type of filtering to perform for preview renders on each mouse movement when using the OpenCL renderer. Log scaling is recommended for all but the fastest video cards. However, if
                you have a very fast processor and want to see a more realistic representation of what the final output image will look like on every mouse movement, select
                the Full DE option.
                Note that as stated above under OpenCL Sub Batch, even if this option is set to log scaling, full DE might get performed on each mouse movement for low quality renders.
            </li>
        </ul>
    </li>
    <li>
        ==Xml Saving==
        When editing flames, the user will save the parameters as an Xml file once they are satisfied with the result. Most of the values will be displayed exactly as they
        are on the UI. However, there are a few that make sense to override each time.
        <ul>
            <li>
                ===Width===
                The width of the final output image.
                Range: 10 - 100,000.
            </li>
            <li>
                ===Height===
                The height of the final output image.
                Range: 10 - 100,000.
            </li>
            <li>
                ===Quality===
                The quality of the final output image. Values above 2000 don't offer much noticeable improvement.
                Range: 1 - 200,000.
            </li>
            <li>
                ===Temporal Samples===
                The temporal samples to use when applying motion blur. A value of 1000 is recommended. Only used during animation, otherwise the value is overridden with one.
                Range: 1 - 5,000.
            </li>
            <li>
                ===Supersample===
                The value to multiply the dimensions of the histogram and density filter buffer by to help eliminate jagged lines.
                Values greater than one will greatly impact performance and will increase memory usage.
                While a value of 2 offers some visual improvement, values greater than 2 don't offer noticeable improvement.
                Range: 1 - 4.
            </li>
        </ul>
    </li>
    <li>
        ==Identity==
        When saving flame parameters to an Xml file, there is a field for the identity of the artist who made the flame. Fill these out with your identity so that you
        get proper attribution for your work.
        <ul>
            <li>
                ===Id===
                The identity of the user.
            </li>
            <li>
                ===Url===
                The website of the user.
            </li>
            <li>
                ===Nick===
                The nick name of the user.
            </li>
        </ul>
    </li>
 </ul>
--- a/Data/Wiki/PaletteTab.htm
+++ b/Data/Wiki/PaletteTab.htm
@ -1,108 +0,0 @@
 #summary Palette tab
 <font face="Verdana">
 =Palette Tab Item Descriptions=
 <ul>
    The list of available palettes as well as optional adjustment values.
    <li>
        ==Adjustments==
        Adjustments are applied to the selected palette in the following order: frequency, hue, saturation, brightness, contrast, blur.
        Double clicking a spinner will reset it to its default value.
        <ul>
            <li>
                ===Hue===
                The degrees to rotate the hue of the HSV representation of the RGB color by.
                Range: -180 - 180.
                Render State: Full render.
            </li>
            <li>
                ===Saturation===
                The percentage to add to the saturation (intensity) component of the HSV representation of the RGB color.
                Range: 0 - 100.
                Render State: Full render.
            </li>
            <li>
                ===Brightness===
                The value to add to each channel. Negative values bring it toward black, positive values toward white.
                Range: -255 - 255.
                Render State: Full render.
            </li>
            <li>
                ===Contrast===
                The difference between lightest and darkest colors in the palette. Negative values decrease the difference, and
                bring the colors toward gray. Positive values increase the difference and make the colors more saturated.
                Range: -100 - 100.
                Render State: Full render.
            </li>
            <li>
                ===Blur===
                The width in pixels of the blurring.
                Range: 0 - 127.
                Render State: Full render.
            </li>
            <li>
                ===Frequency===
                The number of times to repeat the palette.
                Range: 1 - 10.
                Render State: Full render.
            </li>
        </ul>
    </li>
    <li>
        ==Palette Preview==
        What the final adjusted palette looks like. This is what's used for iteration.
    </li>
    <li>
        ==Palette List==
        The full list of palettes and their names in the current palette file, which defaults to flam3-palettes.xml.
        <ul>
            <li>
            ===Single click===
            Set the selected palette as the current one and apply the specified adjustments.
            Render State: Full render.
            </li>
            <li>
            ===Double click===
            Set the selected palette as the current one and reset all adjustments.
            Render State: Full render.
            </li>
        </ul>
    </li>
 </ul>
--- a/Data/Wiki/ProjectOverview.htm
+++ b/Data/Wiki/ProjectOverview.htm
@ -1,88 +0,0 @@
 =Description=
 <font face="Verdana" size="2">
 A Qt-based fractal flame editor which uses a C++ re-write of the flam3 algorithm named Ember and a GPU capable version named EmberCL which implements a portion of the cuburn algorithm in OpenCL.
 </font>
 <br></br>
 ==Installer==
 <font face="Verdana" size="2">
 <a href="https://drive.google.com/file/d/0Bws5xPbHJph6Vm1jOVRZSVJ6OUk/edit?usp=sharing">Windows 7 64-bit Installer</a>
 </font>
 <br></br>
 ==Requirements and Prerequisites==
 <font face="Verdana" size="2">
 Windows 7, 64-bit
 Install the latest drivers for your video card
 An nVidia video card to take advantage of OpenCL
 If you have an Intel processor, but do not have a device capable of running OpenCL, and still want to run Fractorium with only CPU support, you must install Intel's CPU-only OpenCL libraries <a href="http://registrationcenter.intel.com/irc_nas/3608/intel_sdk_for_ocl_applications_2013_r2_runtime_x64_setup.msi">here</a>.
 </font>
 <br></br>
 ==Running==
 <font face="Verdana" size="2">
 Fractorium and its associated command line tools can render fractal flames using the CPU, or OpenCL. In order to use OpenCL, you must have an nVidia card that has the Fermi architecture or later. If you attempt to use an unsupported card, you will receive an error message and the CPU renderer will be used instead.
 AMD cards will be supported shortly.
 </font>
 <br></br>
 ==Current Status==
 <font face="Verdana" size="2">
 Initial beta release supporting the following:
 ===Hardware:===
 -CPU: x64 Intel and AMD CPUs.
 -GPU: nVidia Fermi and later cards.
 ===Variations:===
 -The 98 standard variations included with flam3.
 ===Palettes:===
 -The 700 palettes included in the standard flam3-palettes.xml file.
 ===Compilers:===
 -Microsoft Visual Studio 2010 (project files upgrade-able to 2012).
 ===Operating Systems:===
 -Windows 7 x64.
 </font>
 ==Future Direction==
 <font face="Verdana" size="2">
 Help is needed and welcome for implementing the following features:
 -Support for AMD hardware.
 -More variations from Apophysis.
 -Support for other compilers, such as gcc and MingW.
 -Support for other operating systems, Mac and Linux.
 -Conversion of OpenGL calls to shader programs.
 -Implementation of more alternative rendering methods.
 -Standalone animator/music visualizer.
 -Benchmarking suite.
 </font>
 <br></br>
 ==Gratitude==
 <font face="Verdana" size="2">
 A sincere thanks to the following people for answering all of my questions:
 Scott Draves
 Erik Reckase
 Steve Robertson
 Mike Thiesen
 </font>
--- a/Data/Wiki/SideBar.htm
+++ b/Data/Wiki/SideBar.htm
@ -1,21 +0,0 @@
 #summary Sidebar
 * [Users]
   * [ProjectOverview Overview]
   * [AlgorithmExplanation Algorithm]
   * [FractoriumUserGuide Fractorium User's Guide]
    * [Menus Menus]
    * [Toolbar Toolbar]
    * [LibraryTab Library Tab]
    * [FlameTab Flame Tab]
    * [XformsTab Xforms Tab]
    * [PaletteTab Palette Tab]
    * [InfoTab Info Tab]
    * [FinalRenderDialog Final Render Dialog]
    * [OptionsDialog Options Dialog]
    * [AboutDialog About Dialog]
   * [CommandLinePrograms Command Line Programs]
 * [Developers]
   * [EmberImplementationDetails Ember]
   * [EmberCLImplementationDetails EmberCL]
   * [Building Building]
   * [CodingPhilosophy Coding Philosophy]
--- a/Data/Wiki/Toolbar.htm
+++ b/Data/Wiki/Toolbar.htm
@ -1,9 +0,0 @@
 #summary Toolbars
 <font face="Verdana">
 =Toolbar Item Descriptions=
 <ul>
    ===Toolbar===
    Buttons perform the same functions as the menu items of the same names.
 </ul>
--- a/Data/Wiki/Users.htm
+++ b/Data/Wiki/Users.htm
@ -1,18 +0,0 @@
 #summary Information for users.
 [ProjectOverview Overview]
 [AlgorithmExplanation Algorithm]
 [FractoriumUserGuide Fractorium User's Guide]
 [Menus Menus]<br></br>
 [Toolbar Toolbar]<br></br>
 [LibraryTab Library]<br></br>
 [FlameTab Flame Tab]<br></br>
 [XformsTab Xforms]<br></br>
 [PaletteTab Palette]<br></br>
 [InfoTab Info]<br></br>
 [FinalRenderDialog Final Render Dialog]<br></br>
 [OptionsDialog Options Dialog]<br></br>
 [AboutDialog About Dialog]
 [CommandLinePrograms Command Line Programs]
--- a/Data/Wiki/XformsTab.htm
+++ b/Data/Wiki/XformsTab.htm
@ -1,343 +0,0 @@
 #summary Xforms tab
 <font face="Verdana">
 =Xforms Tab Item Descriptions=
 <ul>
    <li>
        ==Current Xform==
        The number shown is the index of the currently selected xform. The values on all controls within the xforms tab
        will be from the current xform.
    </li>
    <li>
        ==Add Xform==
        Add an empty xform to the current flame and set it as the current one. It will have no variations and its affine trasforms will be set to the identity matrix
        Render State: Full render.
    </li>
    <li>
        ==Duplicate Xform==
        Make a copy of the current xform and add it to the end of the xforms and set it as the current one.
        Render State: Full render.
    </li>
    <li>
        ==Clear Xform Variations==
        Delete all variations from the current xform.
        Render State: Full render.
    </li>
    <li>
        ==Delete Xform==
        Delete the current xform from the flame.
        Render State: Full render.
    </li>
    <li>
        ==Add Final Xform==
        Add a final xform if one is not already present.
        Render State: Full render.
    </li>
    <li>
        ==Weight==
        The probability that the current xform will be chosen among the others during iteration. Note that all weight values
        are normalized before iteration begins.
        Render State: Full render.
    </li>
    <li>
        ==Equalize Weights==
        Set all xform weights to be 1 / xform count.
        Render State: Full render.
    </li>
    <li>
        ==Name==
        Optional name for this xform to help more easily identify it. Note this values is only used for display purposes
        in Fractorium and is not saved to the Xml file.
    </li>
    <li>
        ==Color==
        <ul>
            <li>
                ===Color Index===
                The index in the palette the current xform uses. This value can be changed by scrolling the mouse wheel in the box displaying the value
                or by dragging the scroll bar.
                Range: 0 - 1.
                Render State: Full render.
            </li>
            <li>
                ===Color Speed===
                The speed with which the color indices are pulled toward the current xform's color index. This value can be negative.
                Range: -1 - 1.
                Render State: Full render.
            </li>
            <li>
                ===Opacity===
                How visible the current xform's contribution to the image is. 0 is invisible, 1 is totally visible.
                Range: 0 - 1.
                Render State: Full render.
            </li>
            <li>
                ===Solo===
                When checked, the current xform is the only visible one. The text of the checkbox specifies which xform is
                the solo one. If none are selected as solo, no number is displayed. This feature is useful for determining how much
                each xform contributes to the final image.
                Note that checking this does not affect the opacity values stored in the Xml file when saved.
                Render State: Full render.
            </li>
        </ul>
    </li>
    <li>
        ==Affine==
        <ul>
            <li>
                ===Pre Affine Transform===
                The affine transform applied to the input points before variations are applied on each iteration.
                The values correspond to the usual affine transform of:
                {{{
                tx = Ax * By + C
                ty = Dx * Ey + F
                }}}
                like so:
                A: X1, D: X2
                B: Y1, E: Y2
                C: O1, F: O2
                <ul>
                    <li>
                        ====Enable====
                        Checking/unchecking shows/hides pre affine transforms and enables/disables the controls.
                    </li>
                    <li>
                        ====Reset====
                        Reset the pre affine transform to the identity matrix.
                        Render State: Full render.
                    </li>
                    <li>
                        ====Adjustments====
                        Change the values of the pre affine transform as the tool tips describe.
                        Render State: Full render.
                    </li>
                    <li>
                        ====Show Current/All====
                        Show current only draws a circle around the current xform's pre affine transform.
                        Show all draws a circle around all xforms' pre affine transforms. This can sometimes clutter
                        the view if the flame contains many xforms, hence the option to only show current.
                    </li>
                </ul>
            </li>
            <li>
                ===Post Affine Transform===
                The affine transform applied to the sum of the applying the variations.
                The values correspond to the usual affine transform of:
                {{{
                tx = Ax * By + C
                ty = Dx * Ey + F
                }}}
                like so:
                A: X1, D: X2
                B: Y1, E: Y2
                C: O1, F: O2
                <ul>
                    <li>
                        ====Enable====
                        Checking/unchecking shows/hides post affine transforms and enables/disables the controls.
                    </li>
                    <li>
                        ====Reset====
                        Reset the post affine transform to the identity matrix.
                        Render State: Full render.
                    </li>
                    <li>
                        ====Adjustments====
                        Change the values of the post affine transform as the tool tips describe.
                        Render State: Full render.
                    </li>
                    <li>
                        ====Show Current/All====
                        Show current only draws a circle around the current xform's post affine transform.
                        Show all draws a circle around all xforms' post affine transforms. This can sometimes clutter
                        the view if the flame contains many xforms, hence the option to only show current.
                    </li>
                </ul>
            </li>
            <li>
                ===Pivot===
                <ul>
                    <li>
                        ====When dragging the X or Y component of an affine transform and holding Shift+Alt:====
                        Local: Rotates the point around the center of the transform.
                        World: Rotates the point around 0, 0.
                    </li>
                    <li>
                        ====When dragging the center of an affine transform and holding Shift:====
                        Local: Rotates entire transform around the origin, keeping its local orientation fixed.
                        World: Rotates entire transform around the origin, also rotating the local orientation.
                    </li>
                    <li>
                        ====When reflecting an affine transform:====
                        Local: Reflect horizontally and vertically around the center of the transform.
                        World: Reflect horizontallly around the Y axis, and vertically around the X axis.
                    </li>
                </ul>
            </li>
        </ul>
    </li>
    <li>
        ==Variations==
        <ul>
            Each xform has one or more variations contained in it that get applied during each iteration. The value to the right of the
            variation name is its weight. Values below it in sub-tree items are for parametric variations.
            <li>
                ===Weight===
                Add a variation to the current xform by scrolling its weight to a non-zero value. Remove it by scrolling
                its weight back to zero. Variations present in the current xform will have a gray background to make them easily
                identifiable.
                A quick way to add or remove a variation is to double click the weight spinner, which will flip the weight
                between 0 and 1.
                Adding or removing variations will trigger an OpenCL recompile, so you will see a slight pause when doing so.
                Render State: Full render.
            </li>
            <li>
                ===Search===
                Typing in this box does a case insensitive search which will only show variations
                with matching text. To restore all, click the X button to the right.
            </li>
            <li>
                ===Sorting===
                Clicking on the left header column will sort by variation ID (which is hidden from the user).
                Clicking on the right header column will sort by weight, placing all variations in the current xform
                with non-zero weights at the top.
            </li>
        </ul>
    </li>
    <li>
        ==Xaos==
        <ul>
            Xaos is an advanced feature that adds an element of control to the random selection of xforms during iteration.
            It adds an adjustment to the probability that a given xform will be selected based on the xform that was selected in the previous iteration.
            Each of the spinners in the right column show a value to adjust the probability of the scenario described in the left column by.
            Values greater than one make it more likely to happen, values less than one make it less likely. Setting all values equal to one indicate no xaos is used.
            Render State: Full render.
            <li>
                ===Direction===
                Different users understand xaos more easily based on the "direction" the terms are specified in. Switching the direction changes the text description in the left column
                and changes the spinner values accordingly.
                To: Adjust the probability of each xform being selected when going from the currently selected xform "to" all of the others.
                From: Adjust the probability of the currently selected xform being selected when coming "from" all of the others.
            </li>
            <li>
                ===Clear Xaos===
                Set all xaos values in all xforms to 1.
            </li>
        </ul>
    </li>
 </ul>