initial commit

This commit is contained in:
Mauro Torrez
2022-07-30 14:46:04 -03:00
commit 47650131de
312 changed files with 212465 additions and 0 deletions

View File

@@ -0,0 +1,226 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE Benchmarks</title>
</head>
<body>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Benchmarks</h1>
<p>Times listed are process user time; ALE is compiled with GCC 3.3.4 and
linked with ImageMagick version 6.0.1; and all images are 3x8-bit RGB
non-interlaced PNGs. Test names are constructed as follows:</p>
<table border=1>
<tr>
<th>Machine code</th>
<th>Description</th>
</tr>
<tr><td>PIII<td>Pentium III 700MHz 100MHz FSB 256K L2 cache
<tr><td>ATH<td>Athlon XP 3000+ 400MHz FSB 512K L2 cache
<tr>
<th>Test code</th>
<th>Description</th>
<tr><td>A+R<td>3 256x256 100% white images, --perturb-upper=32
<tr><td>R <td>3 256x256 100% white images, --perturb-upper=0
<tr>
<th>Run Code</th>
<th>Description</th>
<tr><td>1<td>Run number 1
<tr><td>2<td>Run number 2
<tr><td>3<td>Run number 3
</table>
<h2>Benchmark Table</h2>
<table border=1>
<tr>
<th>Version</th>
<th>Configuration</th>
<td>PIII A+R 1</td>
<td>PIII A+R 2</td>
<td>PIII A+R 3</td>
<td>PIII R 1</td>
<td>PIII R 2</td>
<td>PIII R 3</td>
<td>ATH A+R 1</td>
<td>ATH A+R 2</td>
<td>ATH A+R 3</td>
<td>ATH R 1</td>
<td>ATH R 2</td>
<td>ATH R 3</td>
</tr>
<tr>
<td>0.5.1-patch3</td>
<td>IMAGEMAGICK=1<br>
BITS=8</td>
<td>0m16.830s
<td>0m16.884s
<td>0m16.871s
<td>0m1.432s
<td>0m1.438s
<td>0m1.432s
<td>0m4.819s
<td>0m4.821s
<td>0m4.818s
<td>0m0.400s
<td>0m0.401s
<td>0m0.401s
</tr>
<tr>
<td>0.5.1-patch3</td>
<td>IMAGEMAGICK=1<br>
BITS=16</td>
<td>0m17.024s
<td>0m17.062s
<td>0m17.060s
<td>0m1.493s
<td>0m1.500s
<td>0m1.493s
<td>0m4.904s
<td>0m4.902s
<td>0m4.904s
<td>0m0.414s
<td>0m0.415s
<td>0m0.415s
</tr>
<tr>
<td>0.6.0</td>
<td>IMAGEMAGICK=1<br>
--8bpc
<td>0m13.917s
<td>0m13.881s
<td>0m13.888s
<td>0m2.632s
<td>0m2.642s
<td>0m2.640s
<td>0m4.251s
<td>0m4.257s
<td>0m4.254s
<td>0m0.771s
<td>0m0.764s
<td>0m0.750s
</tr>
<tr>
<td>0.6.0</td>
<td>IMAGEMAGICK=1<br>
--16bpc
<td>0m14.007s
<td>0m14.015s
<td>0m14.020s
<td>0m2.754s
<td>0m2.751s
<td>0m2.753s
<td>0m4.307s
<td>0m4.299s
<td>0m4.302s
<td>0m0.794s
<td>0m0.803s
<td>0m0.796s
</tr>
<tr>
<td>0.7.0</td>
<td>IMAGEMAGICK=1<br>
--q0<br>
--8bpc<br>
<td>0m13.328s
<td>0m13.366s
<td>0m13.352s
<td>0m8.245s
<td>0m8.255s
<td>0m8.253s
<td>0m3.739s
<td>0m3.742s
<td>0m3.731s
<td>0m2.325s
<td>0m2.328s
<td>0m2.322s
</tr>
<tr>
<td>0.7.0</td>
<td>IMAGEMAGICK=1<br>
--q0<br>
--16bpc<br>
<td>0m13.439s
<td>0m13.466s
<td>0m13.462s
<td>0m8.378s
<td>0m8.337s
<td>0m8.342s
<td>0m3.765s
<td>0m3.762s
<td>0m3.768s
<td>0m2.356s
<td>0m2.354s
<td>0m2.354s
</tr>
<tr>
<td>0.7.1</td>
<td>IMAGEMAGICK=1<br>
--q0<br>
--8bpc<br>
<td>0m13.133s
<td>0m13.153s
<td>0m13.143s
<td>0m8.100s
<td>0m8.109s
<td>0m8.108s
<td>0m3.774s
<td>0m3.781s
<td>0m3.776s
<td>0m2.327s
<td>0m2.332s
<td>0m2.322s
</tr>
<tr>
<td>0.7.1</td>
<td>IMAGEMAGICK=1<br>
--q0<br>
--16bpc<br>
<td>0m13.243s
<td>0m13.249s
<td>0m13.269s
<td>0m8.177s
<td>0m8.196s
<td>0m8.204s
<td>0m3.808s
<td>0m3.810s
<td>0m3.799s
<td>0m2.371s
<td>0m2.368s
<td>0m2.365s
</tr>
</table>
<h2>Summary</h2>
Between versions 0.5.1 and 0.7.0, alignment times show a steady improvement,
but this can be partly explained by a change in the default alignment settings
in 0.7.0. Rendering times, on the other hand, are about 6 times longer for
0.7.0 than for 0.5.1, as a consequence of renderer changes. More detailed
summaries for alignment and rendering tests follow.
<h3>Alignment</h3>
<p>Alignment times improve as the version number increases, through version
0.7.0, but note that version 0.7.0 with the --q0 option defaults to --mc 30,
which offers less accurate alignment than is offered by other versions'
configurations. (Instead of sampling the difference between images for each
reference image pixel, --mc 30 specifies that differences be sampled at roughly
30% of reference image pixels.)
<h3>Rendering</h3>
<p>Rendering times increase significantly with version number, through version
0.7.0, the most significant increase being between 0.6.0 and 0.7.0, as the
latter uses a computationally more expensive rendering technique. Whether the
improved rendering quality is worth the extra rendering time likely depends on
subjective criteria, but the differences seem to be most apparent when
performing relatively complex rendering tasks.</p>
<br>
<hr>
<i>Copyright 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,168 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE Known Bugs, version 0.5.1</title>
</head>
<body>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Known Bugs</h1>
<!-- No known bugs. -->
<h2>Version 0.8.2</h2>
<table border width=100%>
<tr>
<th width=10%>Packages Affected</th>
<th width=60%>Bug</th>
<th>Status</th>
</tr>
<tr>
<td>All</td>
<td>3D subspace bounding boxes are miscalculated</td>
<td>Fixed in 0.8.3</td>
</tr>
<tr>
<td>All</td>
<td>--ip-median and/or --dchain median:* may cause image degradation when --scale is less than 1.0</td>
<td>Unconfirmed</td>
</tr>
</table>
<h2>Version 0.8.1</h2>
<table border width=100%>
<tr>
<th width=10%>Packages Affected</th>
<th width=60%>Bug</th>
<th>Status</th>
</tr>
<tr>
<td>All</td>
<td>--ip-median and/or --dchain median:* may cause image degradation when --scale is less than 1.0</td>
<td>Unconfirmed</td>
</tr>
<tr>
<td>All</td>
<td>2D alignment with control points does not work properly.
<td>Fixed in 0.8.2.</td>
</tr>
</table>
<h2>Version 0.8.0</h2>
<table border width=100%>
<tr>
<th width=10%>Packages Affected</th>
<th width=60%>Bug</th>
<th>Status</th>
</tr>
<tr>
<td>Source</td>
<td>Fails to compile with GCC 3.4.
<td>Fixed in 0.8.1.</td>
</tr>
</table>
<h2>Version 0.7.1</h2>
<table border width=100%>
<tr>
<th width=10%>Packages Affected</th>
<th width=60%>Bug</th>
<th>Status</th>
</tr>
<tr>
<td>All</td>
<td>Exclusion regions may be wrong when <code>--extend</code> is used.
<td>Fixed in patch 1.</td>
</tr>
<tr>
<td>All</td>
<td>Next frame's default alignment may be incorrect following an alignment failure.
<td>Fixed in patch 1.</td>
</tr>
</table>
<h2>Version 0.7.0</h2>
<table border width=100%>
<tr>
<th width=10%>Packages Affected</th>
<th width=60%>Bug</th>
<th>Status</th>
</tr>
<tr>
<td>All</td>
<td><code>--visp</code> segfaults when used with non-last invariant.
<td>Fixed in 0.7.1.</td>
</tr>
<tr>
<td>All</td>
<td>Euclidean and translational alignment break when used with
<code>--scale</code>, and multiple-LOD alignment does not work properly.</td>
<td>Fixed in patch 1.</td>
</tr>
</table>
<h2>Version 0.6.0</h2>
<table border width=100%>
<tr>
<th width=10%>Packages Affected</th>
<th width=60%>Bug</th>
<th>Status</th>
</tr>
<tr>
<td>All</td>
<td>Multiple-LOD alignment does not work properly.</td>
<td>Fixed in 0.7.1.</td>
</tr>
</table>
<h2>Version 0.5.1</h2>
<table border width=100%>
<tr>
<th width=10%>Packages Affected</th>
<th width=60%>Bug</th>
<th>Status</th>
</tr>
<tr>
<td>All</td>
<td>Multiple-LOD alignment does not work properly.</td>
<td>Fixed in 0.7.1.</td>
</tr>
<tr>
<td>All</td>
<td>Drizzling without --drizzle-only results in a memory leak that grows as
O(n) with the total size of image data from all frames.</td>
<td>Fixed in patch 3.
</tr>
<tr>
<td>All</td>
<td>Rendering an image mosaic that has been extended upwards or to the left of the
original frame using the Irani-Peleg renderer results in corrupted output.
<td>Fixed in patch 2.
</tr>
<tr>
<td>Source distribution only</td>
<td>Using an 8-bit ALE build with 16-bit ImageMagick truncates the most
significant bits of pixel data on 16-bit input image files. This does not
affect 8-bit input files. This bug does not affect the Windows package.
</td>
<td>Fixed in patch 1.
</tr>
</table>
<h2>Previous Versions</h2>
<p>See the changelog in the darcs repository linked from the <a href="../download/">download page</a>.</p>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,148 @@
<html>
<title>Error Functions</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> | <a href="mc/">Monte Carlo</a> ]</b></p>
<h1>Error Functions</h1>
<p>Error functions are used to determine whether a transformation is "good" or
not, and in particular, whether one transformation is better or worse than
another. In particular, a smaller error indicates a better transformation.
<!--
The error functions used by ALE are based on two principles:
<ol>
<li>A relatively small change in camera position or orientation should be
reflected by a small transformation.
<li>When a new frame is merged, the accumulated image should change as little
as possible.
</ol>
-->
<!--
<p>Since sufficiently large transformations can move a new frame so far that it
no longer overlaps the accumulated image, it is important that the alignment
process not mistakenly move images too far, although in principle it is
possible, as in the case of a chain-link fence, that two fairly similar images
do, in fact, represent areas that are spatially separated. This is the
motivation for the first criterion.
<p>The second criterion is based on the general idea that, if two inputs to ALE
look vaguely like a petunia, the output should look like a petunia also. Hence
it should typically be the case that the accumulated image not change much when
new frames are merged.
-->
<p>ALE defines error functions for each pixel of the accumulated image, and
also a comprehensive error function that summarizes the error over all
pixels.
<h3>Per-Pixel Error Functions</h3>
<p>Since differences in exposure may alter the absolute values of pixels even
in images that are perfectly aligned, ALE usually normalizes the images so that
overall image intensity matches. This normalization step does not affect the
pixel values contributing to the merged image, but it does affect the values
with which the per-pixel error function is calculated. (The normalization
step is skipped when --extend or --follow is specified.)
<!-- <p>(Alternatives to normalization exist, including the use of inner products; see
Steve Mann's paper, available on the website linked in footnote 1, for a
discussion of alignment approaches.) -->
<!--
<p>Based on principle 2, ALE calculates the difference between each accumulated
image pixel and the value with which it would be merged given a candidate
transformation. This latter value is the <i>overlapping value</i>, as
described in the section on <a href="../../merging/">merging</a>. This difference
is then raised by the error metric exponent, as specified by the --metric
option. The exponent defaults to 2.0 for ALE versions 0.1.0 and later, or 1.0
for version 0.0.0. Hence,
-->
<p>The per-pixel error function for pixel <i>(i, j)</i> in the accumulated
image <i>A</i>, frame <i>B</i>, and transformation <i>T</i>, is:
<p><blockquote>
<pre>
<i>p(i, j, A, B, T) = Abs( A(i, j) - B(T_inverse(i, j)) )<sup>metric_exponent</sup></i>
</pre>
</blockquote>
<p>where <i>Abs()</i> is the absolute value function and <i>B(T_inverse(i, j))</i>
is the overlapping value described in the <a href="../../merging/">merging</a> section.
If not specified by the --metric option, <i>metric_exponent</i> defaults to 2.0
for ALE versions 0.1.0 and later, or 1.0 for version 0.0.0.
<p>In addition to the per-pixel error function, a per-pixel <i>maximum error
estimator</i> is calculated, as follows:
<p><blockquote>
<pre>
<i>p_max(i, j, A, B, T) = Max( A(i, j), B(T_inverse(i, j)) )<sup>metric_exponent</sup></i>
</pre>
</blockquote>
<h3>Comprehensive Error Functions</h3>
There are two varieties of comprehensive error function used by ALE: an
<i>exhaustive</i> error function and, in versions 0.4.3 and later, a
<a href="mc/"><i>Monte Carlo</i></a> error function. Whereas the exhaustive function
evaluates the error for each pixel in the accumulated image, the <a href="mc/">Monte
Carlo</a> function evaluates only a subset of pixels. <!-- The latter may require
less time to compute, possibly at the expense of precision. -->
<p>If we consider <i>Sum[]</i> to provide the sum over whatever
subset of pixels we are sampling (including possibly the set of all pixels), then
the comprehensive error function, for accumulated image <i>A</i>, frame
<i>B</i>, and transformation <i>T</i>, is:
<p><blockquote>
<pre>
<i>E(A, B, T) = (Sum [ p(i, j, A, B, T) ] / Sum [ p_max(i, j, A, B, T) ])<sup>(1/metric_exponent)</sup></i>
</pre>
</blockquote>
<br><br>
<hr>
<i>Copyright 2002, 2003 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any
medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,159 @@
<html>
<title>Monte Carlo Error Function</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Monte Carlo Error Function</h1>
Monte Carlo alignment can decrease the time required to align large images,
since calculating transformations for every pixel is usually expensive.
Sections in this page describe the motivation for Monte Carlo alignment, the
ratio calculations used, the sampling algorithm, cache behavior for the
algorithm, randomization approaches, typical deviations from the specified
ratios, special handling of level-of-detail, and practical observations
regarding the use of Monte Carlo alignment.
<h2>Motivation</h2>
Transforming large numbers of points in order to determine alignment error can
be very computationally expensive. One approach to mitigating this expense is
to use reduced level-of-detail. However, using reduced level-of-detail can
also reduce alignment precision. In particular, reducing the level of detail
by a factor of two can make impossible the task of precisely aligning a
horizontal line one pixel high. However, if just a few pixels from the line
are sampled at full detail, exact alignment is possible.
<h2>Ratio Calculations</h2>
<p>In Monte Carlo alignment, a ratio
<blockquote>
<i>s = (expected # of pixel
samples) / (# of total pixels in the accumulated image)</i>
</blockquote>
is specified. From this ratio, a new ratio
<blockquote>
<i>u = (expected # of unsampled pixels) / (expected # of sampled pixels)</i>
</blockquote>
is calculated. Pixels are sampled in such a manner that <i>u</i> is
approximately satisified.
<h2>Sampling Algorithm</h2>
<p>Pixels are considered in order of index, where the accumulated image pixel
at position <i>(i, j)</i> is numbered with an index <i>(i * width + j)</i>.
In order of index, we skip and sample pixels in such a manner that the
expected size of a run of consecutive skipped pixels preceding a sampled pixel
is <i>u</i>. We select the size of each run of consecutive skipped pixels as
follows:
<p>If <i>2 * u</i> is an integer, then we draw uniformly from integer values in
the interval <i>[0,2u]</i>. If it is not an integer, then we draw from integer values in
the interval <i>[0,2u + 1]</i> in such a manner that integer values in
<i>[0,2u]</i> are equally likely to be chosen. (There is only one probability
distribution of this kind that satisfies the expected value <i>u</i>. Version
0.4.3 deviates slightly from this distribution, and so a deviation in the
expected value of <i>s</i> occurs, as outlined in this <a
href="ratios/">table</a>. This problem is fixed in version 0.4.4.)
<p>(Also, see the section below on interaction with level-of-detail.)
<h2>Cache behavior</h2>
<p>Since indices are monotonically increasing in memory address, this approach
to sampling may make effective use of memory cache where other approaches (e.g.
repeated random draws from the entire index space) would not.
<h2>Randomization</h2>
ALE versions 0.4.7 and earlier do not reseed the pseudorandom number generator,
and so a new random subset is selected every time the error function is
evaluated. Hence, as more or fewer of the pixels critical to alignment are
sampled, the reported alignment can worsen or improve even in the absence of
any change in transformation.
<p>With this approach, since many transformations are inspected during the
alignment of any given frame, it is likely, especially with greater precision
of alignment, that some measured differences between transformations are due to
a difference in sample sets rather than a difference in alignment accuracy.
<p>By reseeding the pseudorandom number generator, ALE versions 0.4.8 and later
instead use a consistent set of pixels from the accumulated image when
comparing two transformations. Tests sampling 3% of pixels from a set of
320x240 frames indicate that this approach improves alignment.
<h2>Sampling characteristics</h2>
For an image with 100,000 pixels and specified
<i>s</i> in the interval <i>[0.005,0.995]</i>, ALE's sampling method results in
a ratio <i>s</i> within 0.000003 of the specified <i>s</i>. This number
improves with image size. These results are outlined in the <a href="ratios/">table</a> linked
above. However, note that s only represents an expected value, and the actual number
of sampled pixels may vary by more than the numbers given here.
<h2>Interaction with level-of-detail</h2>
<p>When reduced level-of-detail is used, the number of reduced-detail pixels
sampled is taken to be a percentage of the total number of pixels in the
full-detail image, rather than as a percentage of the total number of pixels in
the reduced-detail image. (When this fraction of pixels in the full-detail
image is more than the number of reduced-detail pixels available, all
reduced-detail pixels are used.) This may improve the likelihood of successful
alignment, but may also add overhead to the alignment process.
<h2>Use of Monte Carlo Alignment</h2>
<p> If it is not known in advance what settings will work well for a series of
frames, it may be desirable to begin by sampling a small percentage of pixels,
saving the results of alignment, and then, if the output suggests that proper
alignment is occuring, performing more precise alignment with a larger
percentage of pixels on later passes, using smaller perturbation upper bounds.
If alignment problems occur on the first pass, the percentage of pixels can be
increased and alignment performed again.</p>
<br><br>
<hr>
<i>Copyright 2002, 2003 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any
medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,250 @@
<html>
<head>
<title>Expected sample ratio for --mc &lt;x&gt; argument</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<pre>
Expected sample ratio for specified --mc &lt;x&gt; argument in a 100,000 pixel
image. This table illustrates the effects of a bug in ALE version 0.4.3.
Column A: Specified expected sample ratio x*10^-2
Column B: Expected sample ratio in release 0.4.4
Column C: Expected sample ratio in release 0.4.3
A B C (buggy)
0.005000 0.004997 0.004997
0.010000 0.009997 0.009997
0.015000 0.014997 0.014997
0.020000 0.019997 0.019997
0.025000 0.024997 0.024997
0.030000 0.029997 0.029995
0.035000 0.034997 0.034995
0.040000 0.039997 0.039997
0.045000 0.044997 0.044991
0.050000 0.049997 0.049997
0.055000 0.054997 0.054987
0.060000 0.059997 0.059984
0.065000 0.064997 0.064984
0.070000 0.069997 0.069975
0.075000 0.074997 0.074973
0.080000 0.079997 0.079997
0.085000 0.084997 0.084957
0.090000 0.089997 0.089964
0.095000 0.094997 0.094986
0.100000 0.099997 0.099997
0.105000 0.104997 0.104983
0.110000 0.109997 0.109945
0.115000 0.114997 0.114901
0.120000 0.119997 0.119895
0.125000 0.124997 0.124997
0.130000 0.129997 0.129858
0.135000 0.134997 0.134898
0.140000 0.139997 0.139847
0.145000 0.144997 0.144862
0.150000 0.149997 0.149795
0.155000 0.154997 0.154909
0.160000 0.159997 0.159719
0.165000 0.164997 0.164867
0.170000 0.169997 0.169756
0.175000 0.174997 0.174638
0.180000 0.179997 0.179839
0.185000 0.184997 0.184730
0.190000 0.189997 0.189526
0.195000 0.194997 0.194606
0.200000 0.199997 0.199997
0.205000 0.204997 0.204556
0.210000 0.209997 0.209354
0.215000 0.214997 0.214412
0.220000 0.219997 0.219750
0.225000 0.224997 0.224681
0.230000 0.229997 0.229272
0.235000 0.234997 0.234082
0.240000 0.239997 0.239128
0.245000 0.244997 0.244426
0.250000 0.249998 0.249997
0.255000 0.254998 0.254371
0.260000 0.259998 0.258926
0.265000 0.264998 0.263675
0.270000 0.269998 0.268631
0.275000 0.274998 0.273807
0.280000 0.279998 0.279218
0.285000 0.284998 0.284881
0.290000 0.289998 0.289338
0.295000 0.294998 0.293710
0.300000 0.299998 0.298243
0.305000 0.304998 0.302947
0.310000 0.309998 0.307830
0.315000 0.314998 0.312904
0.320000 0.319998 0.318180
0.325000 0.324998 0.323669
0.330000 0.329998 0.329386
0.335000 0.334998 0.334671
0.340000 0.339998 0.338773
0.345000 0.344998 0.343003
0.350000 0.349998 0.347366
0.355000 0.354998 0.351870
0.360000 0.359998 0.356520
0.365000 0.364998 0.361324
0.370000 0.369998 0.366290
0.375000 0.374998 0.371427
0.380000 0.379998 0.376742
0.385000 0.384998 0.382247
0.390000 0.389998 0.387950
0.395000 0.394998 0.393863
0.400000 0.399998 0.399998
0.405000 0.404998 0.403795
0.410000 0.409998 0.407690
0.415000 0.414998 0.411686
0.420000 0.419998 0.415788
0.425000 0.424998 0.419998
0.430000 0.429998 0.424322
0.435000 0.434998 0.428765
0.440000 0.439998 0.433332
0.445000 0.444998 0.438026
0.450000 0.449998 0.442855
0.455000 0.454998 0.447824
0.460000 0.459998 0.452939
0.465000 0.464998 0.458207
0.470000 0.469998 0.463635
0.475000 0.474998 0.469229
0.480000 0.479998 0.474998
0.485000 0.484998 0.480951
0.490000 0.489998 0.487095
0.495000 0.494998 0.493441
0.500000 0.499998 0.499998
0.505000 0.504998 0.503365
0.510000 0.509998 0.506801
0.515000 0.514998 0.510308
0.520000 0.519998 0.513887
0.525000 0.524998 0.517542
0.530000 0.529999 0.521275
0.535000 0.534999 0.525088
0.540000 0.539999 0.528984
0.545000 0.544999 0.532966
0.550000 0.549999 0.537036
0.555000 0.554999 0.541197
0.560000 0.559999 0.545453
0.565000 0.564999 0.549807
0.570000 0.569999 0.554262
0.575000 0.574999 0.558822
0.580000 0.579999 0.563491
0.585000 0.584999 0.568272
0.590000 0.589999 0.573169
0.595000 0.594999 0.578188
0.600000 0.599999 0.583332
0.605000 0.604999 0.588606
0.610000 0.609999 0.594016
0.615000 0.614999 0.599566
0.620000 0.619999 0.605262
0.625000 0.624999 0.611110
0.630000 0.629999 0.617116
0.635000 0.634999 0.623287
0.640000 0.639999 0.629628
0.645000 0.644999 0.636149
0.650000 0.649999 0.642856
0.655000 0.654999 0.649757
0.660000 0.659999 0.656862
0.665000 0.664999 0.664178
0.670000 0.669999 0.668341
0.675000 0.674999 0.670885
0.680000 0.679999 0.673468
0.685000 0.684999 0.676091
0.690000 0.689999 0.678755
0.695000 0.694999 0.681461
0.700000 0.699999 0.684210
0.705000 0.704999 0.687002
0.710000 0.709999 0.689839
0.715000 0.714999 0.692721
0.720000 0.719999 0.695651
0.725000 0.724999 0.698629
0.730000 0.729999 0.701657
0.735000 0.734999 0.704735
0.740000 0.739999 0.707864
0.745000 0.744999 0.711047
0.750000 0.749999 0.714285
0.755000 0.754999 0.717578
0.760000 0.759999 0.720929
0.765000 0.764999 0.724339
0.770000 0.769999 0.727810
0.775000 0.774999 0.731343
0.780000 0.780000 0.734939
0.785000 0.785000 0.738601
0.790000 0.790000 0.742331
0.795000 0.795000 0.746129
0.800000 0.800000 0.749999
0.805000 0.805000 0.753943
0.810000 0.810000 0.757961
0.815000 0.815000 0.762057
0.820000 0.820000 0.766233
0.825000 0.825000 0.770491
0.830000 0.830000 0.774834
0.835000 0.835000 0.779264
0.840000 0.840000 0.783783
0.845000 0.845000 0.788395
0.850000 0.850000 0.793103
0.855000 0.855000 0.797909
0.860000 0.860000 0.802817
0.865000 0.865000 0.807829
0.870000 0.870000 0.812949
0.875000 0.875000 0.818181
0.880000 0.880000 0.823529
0.885000 0.885000 0.828996
0.890000 0.890000 0.834586
0.895000 0.895000 0.840304
0.900000 0.900000 0.846154
0.905000 0.905000 0.852140
0.910000 0.910000 0.858268
0.915000 0.915000 0.864542
0.920000 0.920000 0.870968
0.925000 0.925000 0.877551
0.930000 0.930000 0.884297
0.935000 0.935000 0.891213
0.940000 0.940000 0.898305
0.945000 0.945000 0.905579
0.950000 0.950000 0.913043
0.955000 0.955000 0.920705
0.960000 0.960000 0.928571
0.965000 0.965000 0.936652
0.970000 0.970000 0.944954
0.975000 0.975000 0.953488
0.980000 0.980000 0.962264
0.985000 0.985000 0.971292
0.990000 0.990000 0.980583
0.995000 0.995000 0.990148

View File

@@ -0,0 +1,191 @@
<html>
<title>Alignment</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> | <a href="error/">Error Function</a> ]</b></p>
<h1>Alignment</h1>
ALE aligns each supplemental frame, in sequence, with the merged rendering
representing all previous frames. This page outlines the three supported
transformation classes, the algorithm used for alignment, and the properties of
the alignment algorithm. Following this is a discussion of practical use of
alignment options, including alignment classes and alignment in the case of
extended renderings.
<h2>Transformations</h2>
<p>ALE offers three classes of transformations: </p>
<table border>
<tr><td>Translations</td><td>introduced in version 0.0.0</td>
<tr><td>Euclidean transformations (excluding reflections)</td><td>introduced in version 0.1.0</td>
<tr><td>Projective transformations</td><td>introduced in version 0.2.0</td>
</table>
<!-- <p>ALE uses a forward transformation to map from a supplemental frame to the
accumulated image, and an inverse transformation to map from the accumulated
image to the supplemental frame. Alignment operates on the parameters of the
forward transformation. -->
<h2>Algorithm</h2>
<p>Alignment proceeds by a deterministic search, beginning with an initial
transformation and modifying this transformation through a series of
perturbations.
<p>The initial transformation may be loaded from a file or selected by default.
The default initial transformation is either the identity transformation or
(when the <code>--follow</code> option is specified) the most recently merged
frame's final alignment. (Note that changes in release 0.5.0 are not reflected
here; these changes affect the interaction of the --follow and --trans-load
flags.)
<p>Once the initial transformation is determined, an initial perturbation
amount is selected, and represents the step size by which each of the
transformation parameters are changed. In translational or Euclidean
alignment, the perturbation amount is applied to translation -- in units of
pixels on the two image axes -- and rotation -- in units of degrees about the
image center. (In version 0.4.8 and later, an additional configurable upper
bound constrains rotational perturbation separately, preventing, e.g., a
360 degree perturbation of rotation.) In the case of projective alignment, the
perturbation amount is applied to the position of the corners of the projected
quadrilateral in units of pixels, where the projection is from the boundary
of the supplemental image into the coordinate system of the accumulated image.
<p>If possible, transformation parameters are changed to decrease the <a
href="error/">error</a> between the two images being
aligned. The perturbation amount is halved whenever it is determined that no
parameter change of this size improves the alignment of the images. A lower
bound on the perturbation amount determines when the alignment is complete.
<p>The order in which parameters are considered for change is specified in the
source code, and has the following property: No modified parameter is
considered for further change until all other parameters have been considered.
A consequence of this property is that parameters are always considered in a
fixed (round robin) order.
<p>When multiple levels of detail are used, the error may be calculated on
images with a reduced level of detail. ALE versions 0.1.1 through 0.4.7 use a
level of detail twice as fine as the perturbation amount for perturbation
amounts larger than two, and full detail otherwise. Later versions default to
this behavior, but can be configured differently. Earlier versions do not use
reduced levels of detail.
<h2>Properties</h2>
<p>Several assumptions were made throughout the design and testing of the
algorithm outlined above. These assumptions are outlined below.
<p>The algorithm is based on a hill-climbing approach, which requires that any
local minimum reachable from the starting point by traveling a path of
decreasing error is also a global minimum (or, in this case, the correct
alignment). While it is possible that the algorithm outlined above succeeds in
some cases for which hill-climbing fails, it is still susceptible to entrapment
in local minima.
<p>As outlined above, depending on program options, transformation parameters
may be changed by perturbations of several units (degrees or pixels) early in
the alignment process. As long as no change of this magnitude moves the
transformation out of the 'bowl' in which the minimum error -- and hence
correct alignment -- lies, this is not a problem. However, it might break in
some cases where a hill-climbing approach would succeed. (Notably, simulated
annealing suffers from a similar problem, and it seems likely that a case could
be constructed in such a way that the algorithm outlined above -- like
simulated annealing -- could, contrarily, succeed where hill-climbing fails.)
<p>Finally, the use of reduced level-of-detail relies on a high signal-to-noise
ratio at low frequencies. Fortunately, this assumption seems to generally
hold, but camera defects or radio interference could violate the assumption,
possibly resulting in misalignment.
<h2>Use of Alignment Classes</h2>
<p>ALE is likely to be most useful when corresponding regions of different
frames can be aligned by one of the available alignment classes.
<p>As described by Steve Mann in his work on <a
href="http://wearcam.org/orbits/">Video Orbits</a>, the projective
transformation offers particular versatility for camera imaging of (ideal
Lambertian) flat scenes. In this case, any change in camera position and
orientation can be corrected as long as points always have a defined projection
onto the rendering plane (for which ALE uses the base of the pyramid
<b>R<sub>1</sub></b>).
<p>In camera imaging of scenes with depth, correction for orientation is almost
the same as for flat scenes, since, if focus and lens distortion is ignored, a
scene with depth is indistinguishable from a flat scene from the perspective of
a camera whose position is fixed.
<p>For sequences of camera images with small changes in position or
orientation, the projective transformations for alignment may closely
approximate Euclidean transformations; in this case, using Euclidean
transformations may achieve similar results and may require less time for
alignment, since there are fewer parameters to tweak (three parameters
instead of eight).
<p>In the case of flatbed scanners that preserve the relative height and width
of scans, any change in the position or orientation of flat objects can be
corrected using the Euclidean alignment class.</p>
<p>If a flatbed scanner does not preserve relative height and width, but does
preserve straight lines, then any change in the position or orientation of flat
objects can be corrected with the projective alignment class.
<p>However, even if a transformation is within the alignment class used, the
alignment algorithm may still be unable to determine large transformations.
<h2>Alignment in the case of Extended Renderings</h2>
<p>By using the --extend flag, ALE can be used to create image mosaics spanning
a spatial region larger than that represented by any single image in the frame
sequence. In these cases, if adjacent frames in the sequence tend to be more
closely aligned with each other than they are with the original frame, it may
be helpful to also use the --follow flag as a hint to the alignment algorithm.
</p>
<br><br>
<small>
</small>
<hr>
<i>Copyright 2002, 2003 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any
medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,89 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Drizzling Renderer</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Drizzling Renderer</h1>
<p>ALE versions 0.4.1 and later implement a drizzling algorithm based on that
outlined in research by Richard Hook and Andrew Fruchter.<sup>1</sup>
<h2>Algorithm</h2>
<p>In the drizzle rendering method, pixels from source images are considered to
span an area smaller than the original source pixel (a 'reduced footprint');
these source images with reduced pixel footprint are transformed for alignment,
and the reduced-area pixels from all transformed source images are combined to
form the target image, where each source pixel contributes to each target pixel
linearly with the area of overlap after transformation.
<p>ALE uses an approximation to the above approach, wherein the area of overlap
is calculated in the coordinates of the source image and then multiplied by a
factor approximating any difference in scale between the source and target
images; for the purpose of these calculations, the region of the target pixel
is approximated by a rectangle in the source coordinate system having all sides
parallel to the source image coordinate axes.
<h2>Properties</h2>
<p>Assuming small drizzling radius, drizzling is approximately the same as
convolution of discrete pixel data with a box filter having the same radius as
the chosen drizzling radius. For a very large, uniform input sequence, point
sampling with simple optics, and sufficiently small radius, drizzling should
provide an acceptable approximation of <b>T</b>.
<small>
<p><sup>1</sup> More information on drizzling can be found in the paper by Hook and Fruchter,
"Variable-Pixel Linear Combination", published in vol. 125 of the ASP
Conference Series (eds. Gareth Hunt and H. E. Payne). This paper was also
published on-line at:
<p><a href="http://www.cv.nrao.edu/adass/adassVI/hookr.html">http://www.cv.nrao.edu/adass/adassVI/hookr.html</a>
</small>
<hr>
<i>Copyright 2002, 2003 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,262 @@
<html>
<title>High-Frequency Enhancement Renderer</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> <!-- | <a href="../../ba/big_about.html">Examples</a> --> ]</b></p>
<h1>High-Frequency Enhancement Renderer</h1>
<p>The High-Frequency Enhancement Renderer is a built-in post-processing
step based on the unsharp mask technique, which has been used to enhance high
frequencies since the days of photographic plate processing (see, for example,
<a
href="http://www.scenic-route.com/tutorial/psp/tutor/unsharp/Unsharp.htm">this
page</a>). This renderer acts after all other rendering steps have completed,
except for Irani-Peleg Iterative Image Reconstruction, which occurs afterward.
<p>(The remainder of this text outlines version-specific information and offers no
further justification for rendering predicates.)
<!-- One theoretical approach to understanding the general
problem of lousy-looking images is that of convolution, and since many projects take
this approach, it may be useful to describe briefly how the ALE rendering pipeline
fits into this framework, as well as some deconvolution approaches which may be
useful.
-->
<!-- We discuss convolution -- one context in which such
a filter can be viewed -- and then deconvolution generally and the details of
the filter used by ALE. The sections most directly relevant to ALE's high-frequency
enhancement are the final two sections, 'Release 0.3.2' and 'Release 0.4.0'. The
other sections provide a context in which this enhancement can be viewed, and discuss
other approaches to addressing the problems that the high-frequency filter was
designed to solve. -->
<!--
<h2>Convolution</h2>
-->
<!-- <p>An image capture process involving ALE may transform a source scene in many ways.
Lens effects may place some areas of a scene in focus and others out of focus,
image sensors sometimes fail to resolve fine details, and, even when alignment
is successful, the rendering methods used by ALE do not, in general, respond
uniformly to unaliased input frequencies.
<p>Subjectively, all of these factors tend to make an image more 'blurry'. One approach
to handling blur, which can be very effective, is to consider it as a convolution. When
this assumption is made, the problem then becomes deconvolution. ('Deconvolution' may be
a good keyword to look for if a more detailed description is desired.) The remainder
of this section discusses how convolution can approximate the operation of ALE,
and the next section will cover deconvolution.
-->
<!--
<p>Several aspects of the ALE rendering pipeline, starting with the image capture hardware,
can be considered convolutions. These aspects are discussed briefly below.
<h3>Focus</h3>
<p>Blur due to an unfocused lens is sometimes considered in the realm of
convolution, and approaches such as Ernst Lippe's Gimp plugin <a
href="http://refocus.sourceforge.net/">refocus</a><sup>1</sup> take this view.
<!-- However, different parts of a scene may be focused differently, and so treating
an image uniformly may not always be appropriate. -->
<!--
<h3>Image Sensors</h3>
<p>The manner in which a scene projected onto an image sensor array is sampled
over each of several small regions corresponding to the sensor elements might
be considered as a convolution. In particular, if the response of each element
is roughly linear and uniform over a small, approximately square region, then
the sensor response could be approximated by convolution with the box filter.
-->
<!-- <p>The manner in which an image sensor element (several of which form an image
sensor array) combines intensity values over some area of a sensor array can be
to be roughly linearly uniformly responsive to changes in intensity over a finite
region<sup>2</sup>, then its response to intensity can be considered a
convolution. If the sensor element region is square, then its response would
be equivalent to convolution with a 2D box filter. -->
<!-- Note that this convolution
is not generally invertible for a single image, since only one value is
observed per region and there is no overlap between regions. However, if many
nearby samples are taken -- e.g. from a sequence of overlapping frames -- some
deconvolution may be possible. -->
<!--
<h3>ALE Rendering</h3>
<p>For a large number of input frames, when frames are of roughly the same
scale and rotation about the optical axis is negligible, the default ALE
rendering technique can be considered to apply the 2D convolution that is the
direct product of the 1D triangle filter with itself. (I believe this is
sometimes called the 2D triangle filter.) The distance between the center and
the edge of the filter is the distance between adjacent pixels.
<p>When the <a href="../drizzling">drizzle</a> rendering method is used with a
very small diameter and very fine grid (i.e. a large scale factor), then
negligible convolution occurs. On the other hand, when a diameter approaching
the distance between pixels is used, and the grid is of the same resolution as
the input frames, then convolution will be roughly equivalent to the default
ALE rendering technique.
<h2>Deconvolution</h2>
Deconvolution seems to be an active area of research, but many reasonably good
practical approaches exist, most of which require some interactive tweaking of
parameters.--> <!-- This should not be surprising, for at least two reasons.
<h3>Motivation for Interactivity</h3>
<p>First, the value of a filtering process often depends on the viewing context.
For example, contrast that would appear unrealistic upon close inspection may
produce what appears to be a realistic image when viewed from a distance. (A
familiar example of this is the arrangement of differently-colored elements in
a display device which nevertheless may produce what appears to be a uniform
image of an entirely different color.)
<p>Second, although deconvolution may be considered as a way of 'undoing' certain
characteristics of the image capture process, it is not always obvious what
these characteristics are. An apparently blurred result might, in fact, be a
faithful capture by a flatbed scanner of a high-quality print of a continuous color
spectrum. -->
<!--
<h3>Techniques</h3>
-->
<!-- <p>As described in the convolution section above, the rendering approaches used by
ALE can be approximated by convolutions, and so it is possible to take the
final rendered result of ALE and perform deconvolution with an external tool (such
as Ernst Lippe's Gimp plug-in 'refocus'<sup>1</sup>). -->
<!--
Several tools external to ALE, such as Ernst Lippe's Gimp plug-in
<a href="http://refocus.sourceforge.net/">refocus</a><sup>1</sup>, provide
deconvolution functions. Such tools can facilitate interactive adjustment
of deconvolution parameters.
-->
<!-- Since ALE is not well-suited to interactive parameter
tweaking, and external tools like the Gimp are designed for interactive
parameter tweaking, this may be a reasonable approach if such tweaking is
desired. -->
<!--
<p>Alternatively, ALE's <a href="../iterative">image reconstruction option</a>
may be used to reduce blur caused by other internal renderers and by image
sensors. <a href="../drizzling">Drizzling</a> with a small diameter may also
reduce renderer-incurred blurring.
<p>Finally, an internal filter to enhance high frequencies is provided, and may
sometimes be more convenient to use than the above options. The filter is
designed to be simple, and is based on the unsharp mask technique. The details
of the filter are covered in the following two sections.
-->
<h2>Release 0.3.1</h2>
<p>The filter in release 0.3.1 acts on a square region, centered on the pixel
to be filtered, where the length of each side of the square is linear with the
scale factor (arbitrarily selected to be 2.5 times the scale factor). &nbsp;The
pixel being filtered makes a positive contribution weighted with the total area
of the filter region, and all pixels coincident with the filter region make a
negative contribution weighted with the area in which the pixel is coincident
with the filter region.
<p>This filter was chosen primarily due to its implementation simplicity and
also for its satisfaction of the following two criteria:
<p>First, the filter value returned for a uniformly valued pixel array is zero.
&nbsp;Hence, when the pixels in the region of the filter support do not vary in
value, the high-frequency filter returns zero. &nbsp;This seems to be a
reasonable requirement for a high-frequency filter. &nbsp;
<p>Second, the filter support for a pixel closely corresponding to given pixel
in the original (unscaled) frame spans a region corresponding to a neighborhood
of pixels in the original frame that is roughly independent of the scale factor.
<p>In release 0.3.1, the filter result described above was divided by 100, so that
an enhancement factor of 1.0 would look reasonable for an image that had been
scaled up by a factor of 4. This division step is replaced by a more general
and elegant normalization step in release 0.4.0.
<p>Since this filter requires a square region of pixels centered on the pixel
to be filtered, it cannot operate near the boundary of an image. We avoid this
problem in release 0.3.1 by not filtering near the boundary of images.
<h2>Release 0.4.0 and later</h2>
<p>The filter in release 0.4.0 was modified from the filter in release 0.3.1 in two
ways:
<p>First, the filter was extended to operate near the boundaries of an image. When
necessary, the filter region is constrained so that it fits within the boundary
of the image. (However, the notion of boundary used does not yet elegantly accommodate
the non-rectangular boundaries that may occur when image extents are increased.)
<p>Second, the filter was normalized so that the filtered pixel makes a
positive contribution with unit (1) weight, and all pixels coincident with the
filter region make a negative contribution with weight <i>a/A</i>, where
<i>a</i> is the area in which the pixel is coincident with the
filter region and <i>A</i> is the total area of the filter region.
<p>This change provides the following nice property that did not hold for the
filter in release 0.3.1:
<p>Filtering and then scaling is almost the same as scaling and then filtering.
<p>Hence, a given high-frequency enhancement argument in ALE will achieve
roughly similar results regardless of scale factor. This behavior should be
less surprising than the behavior in 0.3.1, in which merely increasing the
scale factor argument could cause pixel values to become distorted as they
eventually collided with the limits of the image format.</p>
<small>
<!--
<sup>1</sup>Ernst Lippe. refocus: A Gimp plug-in for sharpening images. <a href="http://refocus.sourceforge.net/doc.html">http://refocus.sourceforge.net/doc.html</a><br>
<sup>2</sup>E.g. this approach was used in:
<br>Michal Irani and Shmuel Peleg. "Improving Resolution by Image Registration". <i>Graphical
Models and Image Processing.</i> Academic Press, May 1991. <a href="http://www.wisdom.weizmann.ac.il/~irani/abstracts/superResolution.html">http://www.wisdom.weizmann.ac.il/~irani/abstracts/superResolution.html</a> -->
</small>
<!--
<h2>Examples</h2>
<p><a href="../../ba/big_about.html">Examples</a> of post-enhancement are available.
-->
<hr>
<i>Copyright 2002, 2003 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

Binary file not shown.

After

Width:  |  Height:  |  Size: 10 KiB

View File

@@ -0,0 +1,489 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE Technical Description</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../../tech/">Up</a> | <a href="merging">Merging</a> | <a href="drizzling">Drizzling</a> | <a href="enhance/">Enhancement</a> | <a href="iterative/">Irani-Peleg</a> | <a href="alignment/">Alignment</a> ]</b></p>
<h1>ALE Technical Description <!-- <small>(or the best approximation to date)</small> --> </h1>
<h2>Abstract</h2>
<p>ALE combines a series of input frames into a single output image possibly
having:</p>
<ul>
<li>Reduced noise.
<li>Reduced aliasing.
<li>Increased dynamic range.
<li>Increased spatial resolution.
<li>Increased spatial extents.
</ul>
<p>This page provides information on related work, models of program input, an
outline of renderers, and an overview of the algorithm used in ALE. </p>
<p><b>Note: This document uses PNGs and HTML 4 character entities.</b></p>
<h2>Related Work</h2>
ALE derives <a href="drizzling/">one</a> of its rendering techniques from a
method developed by Richard Hook and Andrew Fruchter for combining dithered
images.
<p>Steve Mann's work in <a href="http://wearcam.org/orbits/">Video Orbits</a>
on increased spatial extents and the use of projective transformations has
influenced features incorporated by ALE.
<p>ALE incorporates an iterative solver based on the <a
href="http://www.wisdom.weizmann.ac.il/~irani/abstracts/superResolution.html">work</a>
of Michal Irani and Shmuel Peleg on image reconstruction.
<h2>Models of Program Input</h2>
<h3>Definition of Discrete and Continuous Images</h3>
<p>Using <b>R<sup>+</sup></b> to represent the non-negative real numbers, a
<i>discrete image</i> <b>D</b> of size <b>(d<sub>1</sub>,
d<sub>2</sub>)</b> is a function
<blockquote>
<b>D: {0, 1, &hellip;, d<sub>1</sub> - 1}&times;{0, 1, &hellip;, d<sub>2</sub> - 1} &rarr; R<sup>+</sup>&times;R<sup>+</sup>&times;R<sup>+</sup></b>
</blockquote>
A <i>continuous image</i> <b>I</b> of size <b>(c<sub>1</sub>, c<sub>2</sub>)</b> is a function
<blockquote>
<b>I: [0, c<sub>1</sub>]&times;[0, c<sub>2</sub>] &rarr; R<sup>+</sup>&times;R<sup>+</sup>&times;R<sup>+</sup></b>
</blockquote>
<!--
An <i>infinite continuous image</i> <b>I</b> is a function
<blockquote>
<b>I: (-&infin;, &infin;)&times;(-&infin;, &infin;) &rarr; R<sup>+</sup>&times;R<sup>+</sup>&times;R<sup>+</sup></b>
</blockquote>
-->
<p>In this document, a member of the set
<b>R<sup>+</sup>&times;R<sup>+</sup>&times;R<sup>+</sup></b> is sometimes called an
<i>RGB triple</i>.
<h3>Definition of a Camera Snapshot</h3>
<p>A <i>camera snapshot</i> is defined as an <i>n</i>-tuple consisting of:</p>
<ul>
<li>A scene <i><b>S</b></i>.
<li>A pyramid <i><b>R</b></i> with rectangular base.
<li>A continuous image <i><b>I</b></i>.
<li>A discrete image <i><b>D</b></i>.
<li>A function <i><b>i</b></i> such that <i><b>i(S, R) = I</b></i>.
<li>A function <i><b>d</b></i> such that <i><b>d(I) = D</b></i>.
</ul>
<p><i><b>S</b></i> represents a physical scene.</p>
<p><i><b>R</b></i> represents the viewing volume of a physical camera.
<p>The value <i><b>I(x, y)</b></i> is the RGB triple representing the radiance
that would be recorded from <i><b>S</b></i> by a directional light sensor
located at the apex of <i><b>R</b></i> and aimed at the point <i><b>(x,
y)</i></b> on the base of <i><b>R</b></i>. The only constraint on the sensor
is that, given a fixed scene <i><b>S</b></i>, it must return a unique value
for a given position and orientation. This sensor is assumed to be the same
for all camera snapshots, and is called the <i>canonical</i> sensor.</p>
<center>
<table>
<tr><td align=center><img src="i.png">
<tr><td align=center><i>Positioning of the canonical sensor</i>
</table>
</center>
<p><i><b>D</b></i> represents the discrete pixel values reported by the
camera.</p>
<p>The composite function <i><b>composite(d, i)</b></i> represents the optical
and electronic properties of the camera.
<h3>Definition of a Camera Input Frame Sequence</h3>
<p>For positive integer <b>N</b>, a sequence of camera snapshots
<b>{ C<sub>1</sub>, C<sub>2</sub>, &hellip;, C<sub>N</sub> }</b>, defined by the
<i>n</i>-tuples <b>{ C<sub>j</sub> = (S<sub>j</sub>, R<sub>j</sub>, I<sub>j</sub>, D<sub>j</sub>,
i<sub>j</sub>, d<sub>j</sub>) }</b> is a <i>camera input frame sequence</i> if,
for all <b>j</b> and <b>j'</b>, <b>S<sub>j</sub> =
S<sub>j'</sub></b> and <b>i<sub>j</sub> = i<sub>j'</sub></b>.
<h3>Definition of a Diffuse Surface</h3>
Given a camera input frame sequence <b>{ C<sub>1</sub>, C<sub>2</sub>,
&hellip;, C<sub>N</sub> }</b>, defined by the <i>n</i>-tuples
<b>{&nbsp;C<sub>j</sub> = (S, R<sub>j</sub>, I<sub>j</sub>, D<sub>j</sub>, i,
d<sub>j</sub>)&nbsp;}</b>, a surface in <b>S</b> is <i>diffuse</i> if the
radiance of each point on the surface (as measured by the canonical sensor) is
the same for all views <b>R<sub>j</sub></b> from which the point is visible.
<h3>Definition of the Extended Pyramid</h3>
<p>If the view pyramids <b>{ R<sub>1</sub>, R<sub>2</sub>, &hellip;,
R<sub>N</sub> }</b> of a sequence of <b>N</b> camera input frames all share a
common apex and can be enclosed in a single rectangular-base pyramid <b>R</b>
sharing the same apex and having base edges parallel to the base edges of
<b>R<sub>1</sub></b>, then the smallest such <b>R</b> is the <i>extended pyramid</i>.
Otherwise, the extended pyramid is undefined.</p>
<p>If a camera input frame sequence has an extended pyramid <b>R</b>, then an
<i>extended image</i> is defined from <b>R</b> in a manner analogous to the definition
of the image <i><b>I</b></i> from the view pyramid <i><b>R</b></i> in the
definition of a camera snapshot.
<h3>Definition of a Projective Snapshot</h3>
<p>A <i>projective snapshot</i> is defined as an <i>n</i>-tuple consisting of:</p>
<ul>
<li>A continuous image <i><b>&Sigma;</b></i>.
<li>A continuous image <i><b>I</b></i>.
<li>A discrete image <i><b>D</b></i>.
<li>A projective transformation <i><b>q</b></i> such that <i><b>I = composite(&Sigma;, q)</b></i>
<li>A function <i><b>d</b></i> such that <i><b>d(I) = D</b></i>.
</ul>
<p><i><b>&Sigma;</b></i> represents the subject of the
snapshot (somewhat analogous to <i><b>S</b></i> in the camera snapshot).
<p><i><b>D</b></i> represents discrete pixel values reported by the physical
imaging device.
<h3>Definition of a Projective Input Frame Sequence</h3>
<p>For positive integer <b>N</b>, a sequence of projective snapshots <b>{
P<sub>1</sub>, P<sub>2</sub>, &hellip;, P<sub>N</sub> }</b>, defined by the
<i>n</i>-tuples <b>{ P<sub>j</sub> = (&Sigma;<sub>j</sub>, I<sub>j</sub>,
D<sub>j</sub>, q<sub>j</sub>, d<sub>j</sub>) }</b> is a <i>projective input
frame sequence</i> if, for all <b>j</b> and <b>j'</b>, <b>&Sigma;<sub>j</sub> =
&Sigma;<sub>j'</sub></b>.
<p>The first frame in the sequence of input frames is called the <i>original
frame</i>, and subsequent frames <i>supplemental frames</i>.
<h3>Construction of Projective Input Frame Sequences from Camera Input Frame Sequences</h3>
<p>From a camera input frame sequence, define a continuous image
<b>&Sigma;</b> as follows:
<ul>
<li>If an extended pyramid is defined for the set of camera input frames, then
<b>&Sigma;</b> is the associated extended image. <br><br>
<li>If an extended pyramid would be defined if all pyramids
<b>R<sub>j</sub></b> were translated to share a common apex, and the scene
<b>S</b> represents a physical configuration presenting to the camera only a
single planar, diffuse surface, then define <b>&Sigma;</b> so that there
exists some projective transformation <b>p</b> such that <b>&Sigma;(p(x))</b>
indicates the radiance at point <b>x</b> on the surface.
</ul>
If such a <b>&Sigma;</b> exists, then each camera input frame
<blockquote>
<b>C<sub>j</sub> = (S, R<sub>j</sub>, I<sub>j</sub>, D<sub>j</sub>, i,
d<sub>j</sub>)</b>
</blockquote>
admits a projective input frame
<blockquote>
<b>P<sub>j</sub> = (&Sigma;, I<sub>j</sub>, D<sub>j</sub>, q<sub>j</sub>, d<sub>j</sub>)</b>
</blockquote>
for some <b>q<sub>j</sub></b>, and these <b>{ P<sub>j</sub> }</b> form a
projective input frame sequence.
<h3>Definition of a Projective Renderer without Extension</h3>
<p>For a projective input frame sequence <b>{ P<sub>j</sub> = (&Sigma;,
I<sub>j</sub>, D<sub>j</sub>, q<sub>j</sub>, d<sub>j</sub>) }</b>, a
<i>projective renderer without extension</i> is an algorithm that outputs a
discrete image approximation of <b>I<sub>1</sub></b>. The assumptions used in
calculating the approximation vary across rendering methods.
<h3>Definition of a Projective Renderer with Extension</h3>
<p>For a projective input frame sequence <b>{ P<sub>j</sub> = (&Sigma;,
I<sub>j</sub>, D<sub>j</sub>, q<sub>j</sub>, d<sub>j</sub>) }</b>, a
<i>projective rendering method with extension</i> is an algorithm that outputs
a discrete image approximation of <b>&Sigma;</b>. The assumptions used in
calculating the approximation vary across rendering methods.
<h2>Renderers</h2>
<!--
<h3>Examples</h3>
Examples of rendering output are available on the <a href="../render/">rendering
page</a>.
-->
<h3>Extension</h3>
<p>All renderers can be used with or without extension (according to whether the
--extend flag is used). The target image for approximation (either
<b>&Sigma;</b> or <b>I<sub>1</sub></b>) is generically called <b>T</b>.
<h3>Renderer Types</h3>
<p>Renderers can be of incremental or non-incremental type. Incremental
renderers update the rendering as each new frame is loaded, while
non-incremental renderers update the rendering only after all frames have been
loaded.</p>
<p>Incremental renderers contain two data structures that are updated with each
new frame: an accumulated image <b>A</b> with elements <b>A<sub>x, y</sub></b>
and the associated weight array <b>W</b> with elements <b>W<sub>x, y</sub></b>.
The accumulated image stores the current rendering result, while the weight
array stores information about contributions to each accumulated image pixel.
<h3>Renderer Details</h3>
These pages offer detailed descriptions of renderers.
<ul>
<li>Incremental Renderers</li>
<ul>
<li><a href="merging/">Merging</a>
<li><a href="drizzling/">Drizzling</a>
</ul>
<li>Non-incremental Renderers</li>
<ul>
<li><a href="enhance/">High-frequency Enhancement</a>
<li><a href="iterative/">Irani-Peleg</a>
</ul>
</ul>
<h3>Rendering Predicates</h3>
<p>Renderers should output approximations of <b>T</b> when certain predicates
are satisfied. Not all of these predicates are required for all renderers, and
renderers may produce acceptable output even when their predicates are not
satisfied.</p>
<blockquote>
<table border cellpadding=5>
<tr>
<th>Predicate</td>
<th>Explanation</th>
<tr>
<td>Alignment</td>
<td>The projective input frame transformations <b>q<sub>j</sub></b> are known.</td>
<tr>
<td>Translation</td>
<td>All projective input frame transformations <b>q<sub>j</sub></b> are
translations.</td>
<tr>
<td>Point sampling with simple optics</td>
<td><b>d<sub>j</sub></b> assigns <b>D<sub>j</sub>(x) = I<sub>j</sub>(x)</b>.
<tr>
<td>Very large, uniform input sequence</td>
<td>A large number of input frames are provided, uniformly sampling the domain
of <b>T</b>.
<tr>
<td>Small radius</td>
<td>The radius parameter used with the rendering method is chosen to be
sufficiently small.
<tr>
<td>Barlett filter approximation</td>
<td>Convolution of <b>T</b> with a Bartlett filter remains an acceptable
approximation of <b>T</b>.
<tr>
<td>USM approximation</td>
<td>Applying the unsharp mask employed by the ALE --hf-enhance option to the
output of drizzling or merging produces an acceptable approximation of
<b>T</b>.
<tr>
<td>Correct Projection Filter</td>
<td>The projection filter used in Irani-Peleg rendering approximates
<b>d<sub>j</sub></b>.
<tr>
<td>Low Response Approximation</td>
<td>Frequencies having low response in the Fourier domain representations of
<b>d<sub>j</sub></b> need not be accurately reconstructed in the Fourier
domain representation of program output.
<tr>
<td>Convergence</td>
<td>Iterating Irani-Peleg on the input frames will eventually produce an
acceptable approximation of <b>T</b>, and the number of iterations chosen is
adequate to achieve this. This predicate may entail the very large, uniform
input sequence predicate.
</table>
</blockquote>
<h3>Summary of Rendering Predicates by Renderer</h3>
<p>The following table indicates which rendering predicates are associated with
each renderer. Note that renderers may produce acceptable output even when
these predicates are not satisfied. Justification for non-obvious entries in
this table should appear in the detailed descriptions; for entries where this
is not the case, the value given should be considered unreliable.</p>
<ul>
<li><b>M</b> = Merging
<li><b>D</b> = Drizzling
<li><b>H</b> = High-frequency Enhancement
<li><b>I</b> = Irani-Peleg Iterative Image Reconstruction
</ul>
<blockquote>
<table border cellpadding=5>
<tr>
<th>&nbsp;</td>
<th>M</th>
<th>D</th>
<th>H</th>
<th>I</th>
<tr>
<td>Alignment</td>
<td>X</td>
<td>X</td>
<td>&nbsp;</td>
<td>X</td>
<tr>
<td>Translation</td>
<td>X</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<tr>
<td>Point sampling with simple optics
<td>X</td>
<td>X</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<tr>
<td>Very large, uniform input sequence
<td>X</td>
<td>X</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<tr>
<td>Small radius</td>
<td>&nbsp;</td>
<td>X</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<tr>
<td>Barlett filter approximation</td>
<td>X</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<tr>
<td>USM approximation</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>X</td>
<td>&nbsp;</td>
<tr>
<td>Correct Projection Filter</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>X</td>
<tr>
<td>Low Response Approximation</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<tr>
<td>Convergence</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>X</td>
</table>
</blockquote>
<h3>Space Complexity</h3>
Image storage space in memory for all renderers without extension is
<i>O(1)</i> in the number of input frames and <i>O(n)</i> in the number of pixels per
input frame. The worst-case image storage space in memory for all renderers
with extension is <i>O(n)</i> in the size of program input.
<h2>Algorithm</h2>
<p>First, a <a href="merging/">merging</a> renderer is instantiated. Then,
program flags are used to determine what other renderers should be
instantiated.
<p>An iterative loop supplies to the renderers each of the frames in sequence,
beginning with the original frame. The <a href="drizzling/">drizzling</a> and
<a href="merging/">merging</a> renderers are incremental renderers, and
immediately update their renderings with each new frame, while the <a
href="enhance/">high-frequency enhancement</a> and <a
href="iterative/">Irani-Peleg</a> renderers do not act until the final frame
has been received.
<p>In the case of the incremental renderers, the original frame is used without
transformation, and each supplemental frame is transformed according to the
results of the <a href="alignment/">alignment</a> algorithm, which aligns each
new frame with the current rendering of the <a href="merging/">merging</a>
renderer.
<p>Once all frames have been aligned and merged, non-incremental renderers
produce renderings based on input frames, alignment information, and the output
of other renderers.</p>
<small>
</small>
<br>
<hr>
<i>Copyright 2002, 2003 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,113 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Irani-Peleg Renderer</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Irani-Peleg Renderer</h1>
<p>ALE implements an iterative image reconstruction algorithm based on Michal
Irani and Shmuel Peleg's paper "Improving Resolution by Image Registration",
published in <i>Graphical Models and Image Processing</i>, Vol. 53, No. 3, May,
pp. 231-239, 1991, or available at:
<p><a href="http://www.wisdom.weizmann.ac.il/~irani/abstracts/superResolution.html">http://www.wisdom.weizmann.ac.il/~irani/abstracts/superResolution.html</a>
<p>This algorithm iteratively performs two steps: first, an
approximation of <b>T</b> is projected, based on a filter approximating
<b>d<sub>j</sub></b>, and data collected during <a
href="../alignment/">alignment</a>, to create a set of simulated input frames;
second, the per-pixel error -- between these simulated input frames and the
actual input frames -- is calculated, backprojected, and subtracted from the
approximation of <b>T</b>, resulting in a new approximation of <b>T</b>.
<h2>Initial Image Approximation</h2>
<p>ALE uses the results of previous rendering steps as the initial image
approximation.</p>
<h2>Projection and Back-projection filters</h2>
ALE provides command-line options for selecting forward-projection filters,
including box filters (release 0.4.2 and later) and custom filters (release
0.4.7 and later). The back-projection filters are constructed so that the
normalized back-projection weight between a given pixel in the approximation of
<b>T</b> and a given pixel in an input frame is always equal to the
corresponding normalized forward-projection weight. This differs from the
approach taken by Irani and Peleg.
<h3>Box Filter</h3>
ALE versions 0.4.2 and later implement a box filter with user-specified
diameter. This is somewhat similar to the 'blur' operator used by some image
editing applications, and in some cases, may be an adequate approximation
for <b>d<sub>j</sub></b>.
<h3>Custom Filters</h3>
ALE versions 0.4.7 and later implement support for device-specific custom
filters, including a filter calibrated for the IBM PC Camera Pro (XVP610) in
320x240 mode. Configurability by color channel and pixel position in the input
frame is also supported, although the latter is not currently used by any
filter included with ALE.
<h3><code>stdin</code> Filter</h3>
ALE versions 0.4.7 and later support limited configuration of filters at
runtime from standard input, implemented through a custom filter called
'stdin'. This filter can be used with a script included in the source
distribution to calibrate filters for devices with unknown properties.
<h2>Transformation details</h2>
<p>ALE's method of transforming pixel areas between coordinate systems
approximates transformed pixel boundaries with axis-aligned rectangular
regions. Since boundaries are transformed into the coordinate systems of the
input frames, this approximation can be improved by using larger scale factors
(and hence reducing the size of transformed pixels).</p>
<hr>
<i>Copyright 2003 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,120 @@
<html>
<title>Merging</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Merging</h1>
Merging uses bilinear interpolation to determine each frame's contribution to
the accumulated image, and each contribution is assigned equal weight.
Sections below outline the merging algorithm and its properties.
<h2>Calculating the <i>Overlapping Value</i></h2>
<p>(This section is a very verbose explanation of bilinear interpolation.)
<p>Determining what values from the new frame overlap pixels in the accumulated
image is an important part of merging. Since transformations may involve
sub-pixel alignment, and the accumulated image may be configured to be of finer
resolution than the input frames, the manner in which these values are
determined is not necessarily obvious.
<p>ALE uses the following rules to determine the <i>overlapping value</i>:
<ol>
<li>If the new frame overlaps the accumulated image pixel in such a manner that
the accumulated image pixel is aligned with a pixel in the new frame, then the
value of this pixel is the overlapping value. <br><br>
<li>If the point overlapping the accumulated image pixel falls on a line between
two pixels in the new frame, then the overlapping value is a linear
interpolation between these pixels in the coordinate system of the new frame.
<br><br>
<li>If the point overlapping the accumulated image pixel falls within a
quadrilateral outlined by the four closest pixels in the new frame, then the
overlapping value is a bilinear interpolation among these pixels in the
coordinate system of the new frame.<br><br>
<li>If none of the above conditions apply, then there is no overlapping value
for the accumulated image pixel in the new frame.<br><br>
</ol>
<h2>Calculating the <i>Merged Value</i></h2>
<p>The <i>merged value</i> for an accumulated image pixel is a weighted average
between the current accumulated image pixel value and the overlapping value.
The weights are selected so that overlapping values from all frames contribute
with equal weight.
<h2>Definition of <i>Merging</i></h2>
<p><i>Merging</i> a new frame replaces the existing value of each accumulated
image pixel with the merged value.
<h2>Properties</h2>
<h3>Density and false local minima</h3>
<p>The merging method outlined above has the property of always updating a
dense set of pixels in the accumulated image, even when the accumulated image
is of finer resolution than the new frame. This ensures that the area of
defined pixels in the accumulated image is dense and that any uniform change in
intensity is reflected uniformly over a dense area. The absence of these
properties may cause alignment to fail due to entrapment in local minima, and
so merging is always used internally to create the renderings used by the
alignment algorithm. Except in the case of a large pixel footprint, <a
href="../drizzling">drizzling</a> does not share these properties.
<h3>Convolution with the Bartlett (triangle) filter as the limiting case</h3>
<p>Assuming predicates for translation, point sampling with simple optics, and
a very large, uniform input sequence, the result of merging is equivalent to
convolution of pixel data with the Bartlett, or triangle, filter. This is
derived from the fact that bilinear interpolation of an image defined at
discrete points is equivalent to convolution with a Barlett filter. This
property is still approximately true even when the translation predicate is not
satisfied, so long as large changes in scale do not occur.
<br><br>
<hr>
<i>Copyright 2002, 2003 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,199 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Alignment</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Alignment</h1>
Alignment compares each supplemental frame in the sequence with an intermediate
rendering known as the accumulated image. Based on this comparison, a
transformation is assigned to the supplemental frame. Many different
transformations can be assigned before alignment of the frame is complete.
<h2>Match statistics</h2>
The match statistic is a single number indicating how well two frames are
aligned. After alignment is complete, ALE displays the final match statistic.
If the value is close to 100%, then the frames are well aligned. Very low
values can indicate misalignment. However, even frames that are very well
aligned do not usually achieve 100% alignment, and for improving image quality,
ALE works most effectively when match values are less than 100%.
<h3>Match threshold</h3>
A match threshold can be specified; no images with final match statistics
falling below this threshold will contribute to the final output.
<pre>
--threshold=x Min. match threshold; a perfect match is 100. (0 is default)
</pre>
<h3>Error metric exponent</h3>
The function calculated at each pixel to determine the match statistic is known
as the error metric, and is of the form <i>(a-b)<sup>x</sup></i>. The value <i>x</i> is
known as the error metric exponent, and is 2 by default. Larger numbers
usually mean that alignment will be more influenced by smaller image features.
<pre>
--metric=x Set the error metric exponent. (2 is default)
</pre>
<h3>Alignment Channel Options</h3>
In calculating the per-pixel error metric, there are three ways in which ALE
can handle color channels. By default, ALE adds the channels before
calculating the match. However, ALE can also rely solely on the green color
channel or use all three channels separately.
<pre>
--align-all Align images using all color channels
--align-green Align images using the green channel
--align-sum Align images using a sum of channels [default]
</pre>
<h3>Monte Carlo Alignment</h3>
Aligning large images can take a very long time if all pixels are examined in
determining the match statistic, so it is often desirable to examine a smaller
number of pixels. The Monte Carlo alignment option allows this. The number of
pixels used is specified as a percentage, and smaller numbers usually mean
faster, but less precise, alignment.
<pre>
--mc &lt;x> Align using, on average, x% of available pixels (0 < x < 100)
--no-mc Align using all pixels. [default]
</pre>
<h2>Perturbation</h2>
Every dot displayed after an input filename indicates a change in perturbation
size. The size is initially set to be high, allowing large changes in
alignment to be evaluated, and is reduced as the locally optimal alignment is
found for each size. When this size drops below a specified lower bound, the
frame is considered to be aligned.
<h3>Perturbation bounds</h3>
These options determine the upper and lower bounds for perturbation size. The
perturb-upper and perturb-lower bounds apply to rotation (in degrees),
translation (in pixels), and the movement of the boundaries of a projected
frame (in pixels). The rot-upper bound disables rotational perturbation above
a certain perturbation size (in degrees). To disable alignment, set
perturb-upper to zero.
<pre>
--perturb-upper=x Perturbation upper bound in pixels/degrees (32.0 is default)
--perturb-lower=x Perturbation lower bound in pixels/degrees (.125 is default)
--rot-upper=x Rotation-specific perturbation upper bound (32.0 is default)
</pre>
<h3>Level of detail</h3>
<p>Alignment at large perturbation sizes is usually carried out on
reduced-detail images. To disable this, set lod-max to
log<sub>2</sub>(perturb-upper).
<pre>
--lod-max=x LOD scale factor is max(1, (2^floor(x))/perturb) (1 is def.)
</pre>
<h2>Transformations</h2>
The variables used to adjust alignment are called transformations, and map
points from a source image to a target image.
<p>There are three transformation classes that can be used by ALE. The
translational class applies only translations to the inputs, changing only the
position of images; the Euclidean class applies translations and rotations; and
the projective class applies general projective transformations, which are the
most general type of transformation supported by ALE.
<p>The Euclidean class is most appropriate for use with scanners and as a first
pass for projective transformations. The projective class is most appropriate
for use with cameras.
<p>Except when capturing flat scenes, ALE does not correct for perspective
changes, so movement of cameras should ideally be constrained so that no large
translations occur.
<h3>Transformation Class Options</h3>
<pre>
--translation Only adjust the position of images
--euclidean Adjust the position and orientation of images [default]
--projective Use projective transformations. Best quality, but slow.
</pre>
<h3>Transformation data file options</h3>
Transformations used in alignment can be loaded from a file or saved to a file.
This can be useful when performing alignment in several passes, or when
refining rendering options.
<p>Note that projective transformation data saved to a file cannot be used to
initialize other transformation types.
<pre>
--trans-load=x Load initial transformation settings from file x
--trans-save=x Save final transformation data in file x
</pre>
<h3>Alignment following</h3>
When frames are more closely aligned with adjacent frames in the sequence than
they are with the first frame in the sequence, alignment success can be
improved by specifying the --follow option. This option can be effective even
when initial alignment information is loaded from a file.
<pre>
--identity Frames align closely with the original frame. [default]
--follow Frames align closely with their immediate predecessor.
</pre>
<br>
<hr>
<i>Copyright 2003 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,154 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE 0.5.1 User Manual</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../../user/">Up</a> | <a href="rendering/">Rendering</a> | <a href="alignment/">Alignment</a> ]</b></p>
<h1>ALE 0.5.1 User Manual</h1>
<h2>Purpose</h2>
<p>This page summarizes ALE program operation and command-line usage. <!-- A list
of relevant URLs is provided at the end. -->
<p>Other manual pages in this section describe <a
href="rendering/">rendering</a> and <a href="alignment/">alignment</a>.
<p>For more information on ALE, see the <a
href="http://auricle.dyndns.org/ALE/">ALE Home Page</a>.
<h2>Program Operation and Usage</h2>
<h3>Parameter Meta-syntax</h3>
<table >
<tr>
<td><code>&nbsp;&lt;foo></code></td>
<td>A required parameter called <i>foo</i>.</td>
</tr>
<tr>
<td><code>[&lt;foo>]</code></td>
<td>An optional parameter called <i>foo</i>.
</tr>
<tr>
<td><code>[&lt;foo>]*</code></td>
<td>Zero or more parameters <i>foo</i>.
</tr>
</table>
<h3>Command-line syntax for Version Information</h3>
<p>The following command-line invocation can be used to print version
information and build options:
<pre>ale --version</pre>
The following is sample output from this invocation:
<pre>
ALE Version: 0.5.1
File handler: ImageMagick
Bits per channel: 8
</pre>
The above output indicates that the ALE version is 0.5.1, that ImageMagick is
being used to handle image files, and that a 24-bit color space is being used.
<h3>Command-line syntax for Help Output</h3>
When invoked with no options, or options detected as incorrect, ALE outputs a
help message specifying command-line usage and available options. The following
is a sample invocation:
<pre>ale</pre>
<h3>Command-line syntax for Image Processing</h3>
<p>The following is the normal command-line invocation for ALE, and is used to
process a series of frames into an output file:
<pre>ale [&lt;option>]* &lt;original-frame> [&lt;supplemental-frame>]* &lt;output-file></pre>
<p>The original-frame parameter, and each supplemental-frame parameter, should
match the filename of an image file. Output will be written to the output file
specified.
<p>Depending on compile options, the file handler used may be ImageMagick or an
internal PPM file handler (use the --version flag to check this). When
ImageMagick is used for file handling, input files can be any of the <a
href="http://imagemagick.sourceforge.net/www/formats.html">types</a> that
ImageMagick can handle, and the output file type should be specified by file
extension. The internal PPM file handler can be used to read and write PPM
files only. However, on many platforms, ImageMagick's <a
href="http://www.imagemagick.org/">command line utilties</a> can be used to
convert between PPM and other file formats.
<p>Options are outlined in the <a href="rendering/">rendering</a> and <a
href="alignment/">alignment</a> subsections.
<h2>Subsections</h2>
<ul>
<li><a href="rendering/">Rendering</a>
<li><a href="alignment/">Alignment</a>
</ul>
<!--
<h2>URLs</h2>
<h3>ALE home page</h3>
<p><a href="http://auricle.dyndns.org/ALE/">http://auricle.dyndns.org/ALE/</a></p>
<h3>File formats supported by ImageMagick</h3>
<p><a href="http://imagemagick.sourceforge.net/www/formats.html">http://imagemagick.sourceforge.net/www/formats.html</a></p>
<h3>ImageMagick command-line utilities</h3>
<p><a href="http://www.imagemagick.org/">http://www.imagemagick.org/</a></p>
-->
<br>
<hr>
<i>Copyright 2003 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,216 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Rendering</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Rendering</h1>
Rendering determines how an output image is constructed from a series of
aligned input frames. The incremental renderers, merging and drizzling, update
the output image after reading each new frame from the series, whereas the
non-incremental renderers wait until the last frame has been loaded to produce
output. More than one renderer can be involved in producing the final output image.
Available rendering options are outlined below.
<h2>Merging</h2>
Merging, the default incremental renderer, works most effectively on images
that have no large changes in scale (e.g. camera zooming). Since it uses
bilinear interpolation, output images are approximately convolved with the
triangle, or Bartlett, filter, and may appear to have reduced contrast and
resolution in comparison with other renderers.
<h2>Drizzling</h2>
The drizzling renderer is an incremental renderer that can usually produce
better images than merging, but it works most effectively with devices having
very little blur and optical distortion. Devices sampling very small angles of
the scene at each pixel are ideal; hence, if very fine staircase aliasing is
visible in the input frames, drizzling should work very well. (For creation of
higher resolution images with drizzling, use also the --scale option described
below.)
<pre>
--drizzle-diam=x Drizzle with input pixel diameter x (where 0 &lt; x &lt;= 1).
--drizzle-only If drizzling, output black for pixels with no drizzle data.
</pre>
<p>For more information about drizzling, see the paper by Richard Hook and
Andrew Fruchter, "Variable-Pixel Linear Combination", or the following URL:
<p><a href="http://www.cv.nrao.edu/adass/adassVI/hookr.html">http://www.cv.nrao.edu/adass/adassVI/hookr.html</a>
<h2>High-frequency enhancement</h2>
<p>This renderer uses an unsharp mask to enhance the contrast of high
frequencies. It can be used to compensate for systematic blurriness introduced
by merging, drizzling, or the image capture device. However, better results
will generally be achievable by using a separate postprocessing tool, such as
<a href="http://www.gimp.org">the GIMP</a> or <a
href="http://cinepaint.sourceforge.net/">CinePaint</a> (formerly called Film
GIMP). In addition to the built-in unsharp mask, the GIMP can make use of
Ernest Lippe's <a href="http://refocus.sourceforge.net/">refocus</a> plugin.
<pre>
--hf-enhance=x Enhance high frequency details by factor x. (0.0 is default)
</pre>
<h2>Irani-Peleg iterative image reconstruction</h2>
This renderer is by far the most general, and can be used to compensate for
blurring introduced by the image capture device. In order to use it most
effectively, an approximation of the projection function for the capture device
should be known. Two general classes of projection functions are supported: box
filters and custom filters.
<p>If rendering with the box filter option, manual experimentation can be used
to find a diameter that works well. Alternatively, ALE includes a script that
calibrates custom filters for devices, based on images captured from known
scenes.
<p>Two custom filter options are included: one for the IBM PC Camera Pro
(XVP610) in 320x240 mode, and one for interactive filter specification.
<p>Note that this option can take a long time to produce output, especially on
large images. If incremental output is enabled (see below), output is written after
each iteration is complete. Using more iterations will generally improve
output, up to the point of convergence, when additional iterations have no
effect. A dot is displayed to indicate the completion of each iteration.
<pre>
--ip &lt;d> &lt;i> Solve for a box filter with diameter &lt;d> over &lt;i> iterations.
--ipc &lt;c> &lt;i> Solve for device config &lt;c> over &lt;i> iterations.
</pre>
The available device configurations are as follows:
<pre>
xvp610_320x240
stdin
</pre>
<p>For more information on the backprojection technique of Michal Irani and Shmuel
Peleg, see their paper, "Improving Resolution by Image Registration", at
<p><a href="ftp://ftp.wisdom.weizmann.ac.il/pub/irani/PAPERS/SR_CVGIP91.pdf">ftp://ftp.wisdom.weizmann.ac.il/pub/irani/PAPERS/SR_CVGIP91.pdf</a>
<h2>Scale factor</h2>
Rendering with a larger scale factor causes internal data structures to store
more information, resulting in image output of the specified larger scale.
Larger scales can improve alignment precision and output image quality, but can
also increase alignment and rendering times.
<pre>
--scale=x Scale images by the factor x (where x is at least 1.0)
</pre>
<h2>Image extents</h2>
The --extend option records pixel data that falls outside of the region of the
first frame in the sequence. This can be useful for providing additional
alignment constraints or creating panoramic image mosaics. (See also the
description of the --follow option in the <a href="../alignment">alignment</a>
section.)
<pre>
--extend Increase image extents to accommodate all pixel data.
--no-extend Don't increase extents; crop to original frame. [default]
</pre>
<h2>Incremental output</h2>
By default, the output file is written every time a renderer completes an
update cycle. In order to suppress output until the final image is rendered,
specify the --no-inc option.
<pre>
--inc Produce incremental output. [default]
--no-inc Don't produce incremental output.
</pre>
<h2>Pixel replacement</h2>
<p>When using the merging renderer, --replace indicates that each new frame
should replace the corresponding region of the rendering, instead of being
merged with data from previous frames. This option was originally suggested by
Jeff Treece for use in stabilization of video streams. His approach to
stabilization is outlined below.
<h3>Video Stabilization</h3>
<p>If the files
<pre>0.ppm, 1.ppm, ..., 9.ppm</pre>
represent frames from an unstabilized video stream, then the following sequence
of commands may result in a stabilized sequence:
<pre>
ale --replace 0.ppm 1.ppm 1.stable.ppm
ale --replace 1.stable.ppm 2.ppm 2.stable.ppm
ale --replace 2.stable.ppm 3.ppm 3.stable.ppm
.
.
.
ale --replace 8.stable.ppm 9.ppm 9.stable.ppm
</pre>
<p>The resulting stabilized sequence would be:
<pre>0.ppm, 1.stable.ppm, 2.stable.ppm, ..., 9.stable.ppm</pre>
<h3>Option Syntax</h3>
<pre>
--replace Replace overlapping areas rather than merging.
--no-replace Do not replace. [default]
</pre>
<br>
<hr>
<i>Copyright 2003 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,155 @@
<html>
<title>Error Functions</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> | <a href="mc/">Monte Carlo</a> ]</b></p>
<h1>Error Functions</h1>
<p>Error functions are used to determine whether a transformation is "good" or
not, and in particular, whether one transformation is better or worse than
another. In particular, a smaller error indicates a better transformation.
<!--
The error functions used by ALE are based on two principles:
<ol>
<li>A relatively small change in camera position or orientation should be
reflected by a small transformation.
<li>When a new frame is merged, the accumulated image should change as little
as possible.
</ol>
-->
<!--
<p>Since sufficiently large transformations can move a new frame so far that it
no longer overlaps the accumulated image, it is important that the alignment
process not mistakenly move images too far, although in principle it is
possible, as in the case of a chain-link fence, that two fairly similar images
do, in fact, represent areas that are spatially separated. This is the
motivation for the first criterion.
<p>The second criterion is based on the general idea that, if two inputs to ALE
look vaguely like a petunia, the output should look like a petunia also. Hence
it should typically be the case that the accumulated image not change much when
new frames are merged.
-->
<p>ALE defines error functions for each pixel of the accumulated image, and
also a comprehensive error function that summarizes the error over all
pixels.
<h3>Pre-Alignment Exposure Registration</h3>
<p>When exposure registration is enabled, ALE performs an exposure registration
step prior to alignment. The resulting values are dependent on the initial
alignment (this can be either the default initial alignment or an alignment
loaded from a transformation data file). See the source code for details.
<h3>Per-Pixel Error Functions</h3>
<!-- <p>(Alternatives to normalization exist, including the use of inner products; see
Steve Mann's paper, available on the website linked in footnote 1, for a
discussion of alignment approaches.) -->
<!--
<p>Based on principle 2, ALE calculates the difference between each accumulated
image pixel and the value with which it would be merged given a candidate
transformation. This latter value is the <i>overlapping value</i>, as
described in the section on <a href="../../merging/">merging</a>. This difference
is then raised by the error metric exponent, as specified by the --metric
option. The exponent defaults to 2.0 for ALE versions 0.1.0 and later, or 1.0
for version 0.0.0. Hence,
-->
<p>The per-pixel error function for pixel <i>(i, j)</i> in the accumulated
image <i>A</i>, frame <i>B</i>, and transformation <i>T</i>, is:
<p><blockquote>
<pre>
<i>p(i, j, A, B, T) = Abs( A(i, j) - B(T_inverse(i, j)) )<sup>metric_exponent</sup></i>
</pre>
</blockquote>
<p>where <i>Abs()</i> is the absolute value function and <i>B(T_inverse(i,
j))</i> is determined by bilinear interpolation. If not specified by the
--metric option, <i>metric_exponent</i> defaults to 2.0 for ALE versions 0.1.0
and later, or 1.0 for version 0.0.0.
<p>For coordinates where B(T_inverse(i, j)) is not defined, the error is zero.
(Feedback from Angelo Pesce led to clarification of this point.)
<p>In addition to the per-pixel error function, a per-pixel <i>maximum error
estimator</i> is calculated, as follows:
<p><blockquote>
<pre>
<i>p_max(i, j, A, B, T) = Max( A(i, j), B(T_inverse(i, j)) )<sup>metric_exponent</sup></i>
</pre>
</blockquote>
<p>For coordinates where B(T_inverse(i, j)) is not defined, the maximum error
estimator is zero. (Feedback from Angelo Pesce led to clarification of this
point.)
<h3>Comprehensive Error Functions</h3>
There are two varieties of comprehensive error function used by ALE: an
<i>exhaustive</i> error function and, in versions 0.4.3 and later, a
<a href="mc/"><i>Monte Carlo</i></a> error function. Whereas the exhaustive function
evaluates the error for each pixel in the accumulated image, the <a href="mc/">Monte
Carlo</a> function evaluates only a subset of pixels. <!-- The latter may require
less time to compute, possibly at the expense of precision. -->
<p>If we consider <i>Sum[]</i> to provide the sum over whatever
subset of pixels we are sampling (including possibly the set of all pixels), then
the comprehensive error function, for accumulated image <i>A</i>, frame
<i>B</i>, and transformation <i>T</i>, is:
<p><blockquote>
<pre>
<i>E(A, B, T) = (Sum [ p(i, j, A, B, T) ] / Sum [ p_max(i, j, A, B, T) ])<sup>(1/metric_exponent)</sup></i>
</pre>
</blockquote>
<br><br>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any
medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,167 @@
<html>
<title>Monte Carlo Error Function</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Monte Carlo Error Function</h1>
Monte Carlo alignment can decrease the time required to align large images,
since performing coordinate transformations and memory accesses at every pixel
can be expensive. Sections in this page describe the motivation for Monte
Carlo alignment, the ratio calculations used, the sampling algorithm, cache
behavior for the algorithm, randomization approaches, typical deviations from
the specified ratios, special handling of level-of-detail, and practical
observations regarding the use of Monte Carlo alignment.
<h2>Motivation</h2>
Performing large numbers of coordinate transformations and memory accesses in
order to determine alignment error can be computationally expensive. One
approach to mitigating this expense is to use reduced level-of-detail.
However, using reduced level-of-detail can also reduce alignment precision. In
particular, reducing the level of detail by a factor of two can make impossible
the task of precisely aligning a horizontal line one pixel high. However, if
just a few pixels from the line are sampled at full detail, exact alignment is
possible.
<h2>Ratio Calculations</h2>
<p>In Monte Carlo alignment, a ratio
<blockquote>
<i>s = (expected # of pixel
samples) / (# of total pixels in the accumulated image)</i>
</blockquote>
is specified. From this ratio, a new ratio
<blockquote>
<i>u = (expected # of unsampled pixels) / (expected # of sampled pixels)</i>
</blockquote>
is calculated. Pixels are sampled in such a manner that <i>u</i> is
approximately satisified.
<p>At this stage, the region of overlap with the new frame is not considered.
With a limited area of overlap, the number of actual samples contributing to
the final error value will typically be reduced proportionally. (Angelo Pesce
has pointed out that better approaches may be possible, wherein explicit
calculation of overlapping areas reduces the number of coordinate
transformations performed.)
<h2>Sampling Algorithm</h2>
<p>Pixels are considered in order of index, where the accumulated image pixel
at position <i>(i, j)</i> is numbered with an index <i>(i * width + j)</i>.
In order of index, we skip and sample pixels in such a manner that the
expected size of a run of consecutive skipped pixels preceding a sampled pixel
is <i>u</i>. We select the size of each run of consecutive skipped pixels as
follows:
<p>If <i>2 * u</i> is an integer, then we draw uniformly from integer values in
the interval <i>[0,2u]</i>. If it is not an integer, then we draw from integer values in
the interval <i>[0,2u + 1]</i> in such a manner that integer values in
<i>[0,2u]</i> are equally likely to be chosen. (There is only one probability
distribution of this kind that satisfies the expected value <i>u</i>. Version
0.4.3 deviates slightly from this distribution, and so a deviation in the
expected value of <i>s</i> occurs, as outlined in this <a
href="ratios/">table</a>. This problem is fixed in version 0.4.4.)
<p>(Also, see the section below on interaction with level-of-detail.)
<h2>Cache behavior</h2>
<p>Since indices are monotonically increasing in memory address, this approach
to sampling may make effective use of memory cache where other approaches (e.g.
repeated random draws from the entire index space) would not.
<h2>Randomization</h2>
ALE versions 0.4.7 and earlier do not reseed the pseudorandom number generator,
and so a new random subset is selected every time the error function is
evaluated. Hence, as more or fewer of the pixels critical to alignment are
sampled, the reported alignment can worsen or improve even in the absence of
any change in transformation.
<p>With this approach, since many transformations are inspected during the
alignment of any given frame, it is likely, especially with greater precision
of alignment, that some measured differences between transformations are due to
a difference in sample sets rather than a difference in alignment accuracy.
<p>By reseeding the pseudorandom number generator, ALE versions 0.4.8 and later
instead use a consistent set of pixels from the accumulated image when
comparing two transformations. Tests sampling 3% of pixels from a set of
320x240 frames indicate that this approach improves alignment.
<h2>Sampling characteristics</h2>
For an image with 100,000 pixels and specified
<i>s</i> in the interval <i>[0.005,0.995]</i>, ALE's sampling method results in
a ratio <i>s</i> within 0.000003 of the specified <i>s</i>. This number
improves with image size. These results are outlined in the <a href="ratios/">table</a> linked
above. However, note that s only represents an expected value, and the actual number
of sampled pixels may vary by more than the numbers given here.
<h2>Interaction with level-of-detail</h2>
<p>When reduced level-of-detail is used, the number of reduced-detail pixels
sampled is taken to be a percentage of the total number of pixels in the
full-detail image, rather than as a percentage of the total number of pixels in
the reduced-detail image. (When this fraction of pixels in the full-detail
image is more than the number of reduced-detail pixels available, all
reduced-detail pixels are used.) This may improve the likelihood of successful
alignment, but may also add overhead to the alignment process.
<h2>Use of Monte Carlo Alignment</h2>
<p> If it is not known in advance what settings will work well for a series of
frames, it may be desirable to begin by sampling a small percentage of pixels,
saving the results of alignment, and then, if the output suggests that proper
alignment is occuring, performing more precise alignment with a larger
percentage of pixels on later passes, using smaller perturbation upper bounds.
If alignment problems occur on the first pass, the percentage of pixels can be
increased and alignment performed again.</p>
<br><br>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any
medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,250 @@
<html>
<head>
<title>Expected sample ratio for --mc &lt;x&gt; argument</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<pre>
Expected sample ratio for specified --mc &lt;x&gt; argument in a 100,000 pixel
image. This table illustrates the effects of a bug in ALE version 0.4.3.
Column A: Specified expected sample ratio x*10^-2
Column B: Expected sample ratio in release 0.4.4
Column C: Expected sample ratio in release 0.4.3
A B C (buggy)
0.005000 0.004997 0.004997
0.010000 0.009997 0.009997
0.015000 0.014997 0.014997
0.020000 0.019997 0.019997
0.025000 0.024997 0.024997
0.030000 0.029997 0.029995
0.035000 0.034997 0.034995
0.040000 0.039997 0.039997
0.045000 0.044997 0.044991
0.050000 0.049997 0.049997
0.055000 0.054997 0.054987
0.060000 0.059997 0.059984
0.065000 0.064997 0.064984
0.070000 0.069997 0.069975
0.075000 0.074997 0.074973
0.080000 0.079997 0.079997
0.085000 0.084997 0.084957
0.090000 0.089997 0.089964
0.095000 0.094997 0.094986
0.100000 0.099997 0.099997
0.105000 0.104997 0.104983
0.110000 0.109997 0.109945
0.115000 0.114997 0.114901
0.120000 0.119997 0.119895
0.125000 0.124997 0.124997
0.130000 0.129997 0.129858
0.135000 0.134997 0.134898
0.140000 0.139997 0.139847
0.145000 0.144997 0.144862
0.150000 0.149997 0.149795
0.155000 0.154997 0.154909
0.160000 0.159997 0.159719
0.165000 0.164997 0.164867
0.170000 0.169997 0.169756
0.175000 0.174997 0.174638
0.180000 0.179997 0.179839
0.185000 0.184997 0.184730
0.190000 0.189997 0.189526
0.195000 0.194997 0.194606
0.200000 0.199997 0.199997
0.205000 0.204997 0.204556
0.210000 0.209997 0.209354
0.215000 0.214997 0.214412
0.220000 0.219997 0.219750
0.225000 0.224997 0.224681
0.230000 0.229997 0.229272
0.235000 0.234997 0.234082
0.240000 0.239997 0.239128
0.245000 0.244997 0.244426
0.250000 0.249998 0.249997
0.255000 0.254998 0.254371
0.260000 0.259998 0.258926
0.265000 0.264998 0.263675
0.270000 0.269998 0.268631
0.275000 0.274998 0.273807
0.280000 0.279998 0.279218
0.285000 0.284998 0.284881
0.290000 0.289998 0.289338
0.295000 0.294998 0.293710
0.300000 0.299998 0.298243
0.305000 0.304998 0.302947
0.310000 0.309998 0.307830
0.315000 0.314998 0.312904
0.320000 0.319998 0.318180
0.325000 0.324998 0.323669
0.330000 0.329998 0.329386
0.335000 0.334998 0.334671
0.340000 0.339998 0.338773
0.345000 0.344998 0.343003
0.350000 0.349998 0.347366
0.355000 0.354998 0.351870
0.360000 0.359998 0.356520
0.365000 0.364998 0.361324
0.370000 0.369998 0.366290
0.375000 0.374998 0.371427
0.380000 0.379998 0.376742
0.385000 0.384998 0.382247
0.390000 0.389998 0.387950
0.395000 0.394998 0.393863
0.400000 0.399998 0.399998
0.405000 0.404998 0.403795
0.410000 0.409998 0.407690
0.415000 0.414998 0.411686
0.420000 0.419998 0.415788
0.425000 0.424998 0.419998
0.430000 0.429998 0.424322
0.435000 0.434998 0.428765
0.440000 0.439998 0.433332
0.445000 0.444998 0.438026
0.450000 0.449998 0.442855
0.455000 0.454998 0.447824
0.460000 0.459998 0.452939
0.465000 0.464998 0.458207
0.470000 0.469998 0.463635
0.475000 0.474998 0.469229
0.480000 0.479998 0.474998
0.485000 0.484998 0.480951
0.490000 0.489998 0.487095
0.495000 0.494998 0.493441
0.500000 0.499998 0.499998
0.505000 0.504998 0.503365
0.510000 0.509998 0.506801
0.515000 0.514998 0.510308
0.520000 0.519998 0.513887
0.525000 0.524998 0.517542
0.530000 0.529999 0.521275
0.535000 0.534999 0.525088
0.540000 0.539999 0.528984
0.545000 0.544999 0.532966
0.550000 0.549999 0.537036
0.555000 0.554999 0.541197
0.560000 0.559999 0.545453
0.565000 0.564999 0.549807
0.570000 0.569999 0.554262
0.575000 0.574999 0.558822
0.580000 0.579999 0.563491
0.585000 0.584999 0.568272
0.590000 0.589999 0.573169
0.595000 0.594999 0.578188
0.600000 0.599999 0.583332
0.605000 0.604999 0.588606
0.610000 0.609999 0.594016
0.615000 0.614999 0.599566
0.620000 0.619999 0.605262
0.625000 0.624999 0.611110
0.630000 0.629999 0.617116
0.635000 0.634999 0.623287
0.640000 0.639999 0.629628
0.645000 0.644999 0.636149
0.650000 0.649999 0.642856
0.655000 0.654999 0.649757
0.660000 0.659999 0.656862
0.665000 0.664999 0.664178
0.670000 0.669999 0.668341
0.675000 0.674999 0.670885
0.680000 0.679999 0.673468
0.685000 0.684999 0.676091
0.690000 0.689999 0.678755
0.695000 0.694999 0.681461
0.700000 0.699999 0.684210
0.705000 0.704999 0.687002
0.710000 0.709999 0.689839
0.715000 0.714999 0.692721
0.720000 0.719999 0.695651
0.725000 0.724999 0.698629
0.730000 0.729999 0.701657
0.735000 0.734999 0.704735
0.740000 0.739999 0.707864
0.745000 0.744999 0.711047
0.750000 0.749999 0.714285
0.755000 0.754999 0.717578
0.760000 0.759999 0.720929
0.765000 0.764999 0.724339
0.770000 0.769999 0.727810
0.775000 0.774999 0.731343
0.780000 0.780000 0.734939
0.785000 0.785000 0.738601
0.790000 0.790000 0.742331
0.795000 0.795000 0.746129
0.800000 0.800000 0.749999
0.805000 0.805000 0.753943
0.810000 0.810000 0.757961
0.815000 0.815000 0.762057
0.820000 0.820000 0.766233
0.825000 0.825000 0.770491
0.830000 0.830000 0.774834
0.835000 0.835000 0.779264
0.840000 0.840000 0.783783
0.845000 0.845000 0.788395
0.850000 0.850000 0.793103
0.855000 0.855000 0.797909
0.860000 0.860000 0.802817
0.865000 0.865000 0.807829
0.870000 0.870000 0.812949
0.875000 0.875000 0.818181
0.880000 0.880000 0.823529
0.885000 0.885000 0.828996
0.890000 0.890000 0.834586
0.895000 0.895000 0.840304
0.900000 0.900000 0.846154
0.905000 0.905000 0.852140
0.910000 0.910000 0.858268
0.915000 0.915000 0.864542
0.920000 0.920000 0.870968
0.925000 0.925000 0.877551
0.930000 0.930000 0.884297
0.935000 0.935000 0.891213
0.940000 0.940000 0.898305
0.945000 0.945000 0.905579
0.950000 0.950000 0.913043
0.955000 0.955000 0.920705
0.960000 0.960000 0.928571
0.965000 0.965000 0.936652
0.970000 0.970000 0.944954
0.975000 0.975000 0.953488
0.980000 0.980000 0.962264
0.985000 0.985000 0.971292
0.990000 0.990000 0.980583
0.995000 0.995000 0.990148

View File

@@ -0,0 +1,191 @@
<html>
<title>Alignment</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> | <a href="error/">Error Function</a> ]</b></p>
<h1>Alignment</h1>
ALE aligns each supplemental frame, in sequence, with the merged rendering
representing all previous frames. This page outlines the three supported
transformation classes, the algorithm used for alignment, and the properties of
the alignment algorithm. Following this is a discussion of practical use of
alignment options, including alignment classes and alignment in the case of
extended renderings.
<h2>Transformations</h2>
<p>ALE offers three classes of transformations: </p>
<table border>
<tr><td>Translations</td><td>introduced in version 0.0.0</td>
<tr><td>Euclidean transformations (excluding reflections)</td><td>introduced in version 0.1.0</td>
<tr><td>Projective transformations</td><td>introduced in version 0.2.0</td>
</table>
<!-- <p>ALE uses a forward transformation to map from a supplemental frame to the
accumulated image, and an inverse transformation to map from the accumulated
image to the supplemental frame. Alignment operates on the parameters of the
forward transformation. -->
<h2>Algorithm</h2>
<p>Alignment proceeds by a deterministic search, beginning with an initial
transformation and modifying this transformation through a series of
perturbations.
<p>The initial transformation may be loaded from a file or selected by default.
The default initial transformation is either the identity transformation or
(when the <code>--follow</code> option is specified) the most recently merged
frame's final alignment. (Note that changes in release 0.5.0 are not reflected
here; these changes affect the interaction of the --follow and --trans-load
flags.)
<p>Once the initial transformation is determined, an initial perturbation
amount is selected, and represents the step size by which each of the
transformation parameters are changed. In translational or Euclidean
alignment, the perturbation amount is applied to translation -- in units of
pixels on the two image axes -- and rotation -- in units of degrees about the
image center. (In version 0.4.8 and later, an additional configurable upper
bound constrains rotational perturbation separately, preventing, e.g., a
360 degree perturbation of rotation.) In the case of projective alignment, the
perturbation amount is applied to the position of the corners of the projected
quadrilateral in units of pixels, where the projection is from the boundary
of the supplemental image into the coordinate system of the accumulated image.
<p>If possible, transformation parameters are changed to decrease the <a
href="error/">error</a> between the two images being
aligned. The perturbation amount is halved whenever it is determined that no
parameter change of this size improves the alignment of the images. A lower
bound on the perturbation amount determines when the alignment is complete.
<p>The order in which parameters are considered for change is specified in the
source code, and has the following property: No modified parameter is
considered for further change until all other parameters have been considered.
A consequence of this property is that parameters are always considered in a
fixed (round robin) order.
<p>When multiple levels of detail are used, the error may be calculated on
images with a reduced level of detail. ALE versions 0.1.1 through 0.4.7 use a
level of detail twice as fine as the perturbation amount for perturbation
amounts larger than two, and full detail otherwise. Later versions default to
this behavior, but can be configured differently. Earlier versions do not use
reduced levels of detail.
<h2>Properties</h2>
<p>Several assumptions were made throughout the design and testing of the
algorithm outlined above. These assumptions are outlined below.
<p>The algorithm is based on a hill-climbing approach, which requires that any
local minimum reachable from the starting point by traveling a path of
decreasing error is also a global minimum (or, in this case, the correct
alignment). While it is possible that the algorithm outlined above succeeds in
some cases for which hill-climbing fails, it is still susceptible to entrapment
in local minima.
<p>As outlined above, depending on program options, transformation parameters
may be changed by perturbations of several units (degrees or pixels) early in
the alignment process. As long as no change of this magnitude moves the
transformation out of the 'bowl' in which the minimum error -- and hence
correct alignment -- lies, this is not a problem. However, it might break in
some cases where a hill-climbing approach would succeed. (Notably, simulated
annealing suffers from a similar problem, and it seems likely that a case could
be constructed in such a way that the algorithm outlined above -- like
simulated annealing -- could, contrarily, succeed where hill-climbing fails.)
<p>Finally, the use of reduced level-of-detail relies on a high signal-to-noise
ratio at low frequencies. Fortunately, this assumption seems to generally
hold, but camera defects or radio interference could violate the assumption,
possibly resulting in misalignment.
<h2>Use of Alignment Classes</h2>
<p>ALE is likely to be most useful when corresponding regions of different
frames can be aligned by one of the available alignment classes.
<p>As described by Steve Mann in his work on <a
href="http://wearcam.org/orbits/">Video Orbits</a>, the projective
transformation offers particular versatility for camera imaging of (ideal
Lambertian) flat scenes. In this case, any change in camera position and
orientation can be corrected as long as points always have a defined projection
onto the rendering plane (for which ALE uses the base of the pyramid
<b>R<sub>1</sub></b>).
<p>In camera imaging of scenes with depth, correction for orientation is almost
the same as for flat scenes, since, if focus and lens distortion is ignored, a
scene with depth is indistinguishable from a flat scene from the perspective of
a camera whose position is fixed.
<p>For sequences of camera images with small changes in position or
orientation, the projective transformations for alignment may closely
approximate Euclidean transformations; in this case, using Euclidean
transformations may achieve similar results and may require less time for
alignment, since there are fewer parameters to tweak (three parameters
instead of eight).
<p>In the case of flatbed scanners that preserve the relative height and width
of scans, any change in the position or orientation of flat objects can be
corrected using the Euclidean alignment class.</p>
<p>If a flatbed scanner does not preserve relative height and width, but does
preserve straight lines, then any change in the position or orientation of flat
objects can be corrected with the projective alignment class.
<p>However, even if a transformation is within the alignment class used, the
alignment algorithm may still be unable to approximate it.
<h2>Alignment in the case of Extended Renderings</h2>
<p>By using the --extend flag, ALE can be used to create image mosaics spanning
a spatial region larger than that represented by any single image in the frame
sequence. In these cases, if adjacent frames in the sequence tend to be more
closely aligned with each other than they are with the original frame, it may
be helpful to also use the --follow flag as a hint to the alignment algorithm.
</p>
<br><br>
<small>
</small>
<hr>
<i>Copyright 2002, 2003 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any
medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,93 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Drizzling Renderer</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Drizzling Renderer</h1>
<p>ALE versions 0.4.1 and later implement a drizzling algorithm based on that
outlined in research by Richard Hook and Andrew Fruchter.<sup>1</sup>
<h2>Algorithm</h2>
<p>In the drizzle rendering method, pixels from source images are associated
with a square region of given radius in the source image coordinate system.
Similarly, each pixel in the accumulated image, or target image, is associated
with a square region, such that each square region coincides with its neighbors
exactly at its edges. The source regions are then transformed according to the
known alignment between source and target, and the regions from all transformed
source images are combined to form the target image, where each source pixel
region contributes to each target pixel region linearly with the area of
overlap between the regions (as calculated in the target coordinate system).
<p>ALE uses an approximation to the above approach, wherein the area of overlap
is calculated in the coordinates of the source image and then multiplied by a
factor approximating any difference in scale between the source and target
images; for the purpose of these calculations, the region of the target pixel
is approximated by a rectangle in the source coordinate system having all sides
parallel to the source image coordinate axes.
<h2>Properties</h2>
<p>Assuming small drizzling radius, drizzling is approximately the same as
convolution of discrete pixel data with a box filter having the same radius as
the chosen drizzling radius. Given the box filter approximation, jittering
assumption, point sampling, and sufficiently small radius, drizzling should
provide an acceptable approximation of <b>T</b>. Until this is proven,
however, this result should be considered unreliable.
<small>
<p><sup>1</sup> More information on drizzling can be found in the paper by Hook and Fruchter,
"Variable-Pixel Linear Combination", published in vol. 125 of the ASP
Conference Series (eds. Gareth Hunt and H. E. Payne). This paper was also
published on-line at:
<p><a href="http://www.cv.nrao.edu/adass/adassVI/hookr.html">http://www.cv.nrao.edu/adass/adassVI/hookr.html</a>
</small>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,85 @@
<html>
<title>USM Renderer</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> <!-- | <a href="../../ba/big_about.html">Examples</a> --> ]</b></p>
<h1>USM Renderer</h1>
<p>The Unsharp Mask Renderer is a built-in post-processing step based on the
unsharp mask technique, which has been used to enhance high frequencies since
the days of photographic plate processing (see, for example, <a
href="http://www.scenic-route.com/tutorial/psp/tutor/unsharp/Unsharp.htm">this
page</a>). This renderer acts after all other rendering steps have completed,
except for Irani-Peleg rendering, which occurs afterward.
<h2>Properties</h2>
<p>Given a sequence of images that satisfy all predicates for merging (or
drizzling) except point sampling; given a known linear PSF; and given only
translations between frames, the result of merging (or drizzling) will be an
acceptable approximation of <b>T</b> convolved with the PSF. This does not
imply that deconvolution of this result will be an acceptable approximation of
<b>T</b>, however, since frequencies with low response may be reconstructed
with poor fidelity due to reduced precision. We use the low-response
approximation to ignore these frequencies. Assuming the USM approximation, the
remaining frequencies are reconstructed to form an acceptable approximation of
<b>T</b>. (Since this doesn't really constitute a proof, the results should be
considered unreliable.)
<p>
<small>
<!--
<sup>1</sup>Ernst Lippe. refocus: A Gimp plug-in for sharpening images. <a href="http://refocus.sourceforge.net/doc.html">http://refocus.sourceforge.net/doc.html</a><br>
<sup>2</sup>E.g. this approach was used in:
<br>Michal Irani and Shmuel Peleg. "Improving Resolution by Image Registration". <i>Graphical
Models and Image Processing.</i> Academic Press, May 1991. <a href="http://www.wisdom.weizmann.ac.il/~irani/abstracts/superResolution.html">http://www.wisdom.weizmann.ac.il/~irani/abstracts/superResolution.html</a> -->
</small>
<!--
<h2>Examples</h2>
<p><a href="../../ba/big_about.html">Examples</a> of post-enhancement are available.
-->
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,663 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE Version 0.6.0 Technical Description</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../../tech/">Up</a> | <a href="merging">Merging</a> | <a href="drizzling">Drizzling</a> | <a href="enhance/">Enhancement</a> | <a href="iterative/">Irani-Peleg</a> | <a href="alignment/">Alignment</a> ]</b></p>
<h1>ALE Version 0.6.0 Technical Description <!-- <small>(or the best approximation to date)</small> --> </h1>
<h2>Abstract</h2>
<p>ALE combines a series of input frames into a single output image possibly
having:</p>
<ul>
<li>Reduced noise.
<li>Reduced aliasing.
<li>Increased tonal resolution.
<li>Increased spatial resolution.
<li>Increased spatial extents.
</ul>
<p>This page discusses related work, models of program input, renderers used by
ALE, the alignment algorithm used, an overview of the structure of the
program, and examples for which the above output image characteristics are
satisfied.</p>
<p>ALE's approach to exposure registration and certainty-based rendering is not
discussed in the current version of this document. See the source code for
implementation details.
<p><b>Note: This document uses HTML 4 character entities. &nbsp;Sigma is '&Sigma;'; summation is '&sum;'</b>.</p>
<h2>Related Work</h2>
<p>The <a href="drizzling/">drizzling renderer</a> used in ALE is based on
Richard Hook and Andrew Fruchter's <a
href="http://www.cv.nrao.edu/adass/adassVI/hookr.html">drizzling technique</a>.
<p>Steve Mann's discussions (e.g. <a
href="http://wearcam.org/orbits/">here</a> and <a
href="http://wearcam.org/comparam.htm">here</a>) of increased spatial extents, projective
transformations, image processing on linear data, and weighting by certainty
functions, have influenced features incorporated by ALE.
<p>ALE incorporates an <a href="iterative/">iterative solver</a> based on Michal Irani and Shmuel
Peleg's iterative deblurring and super-resolution technique (see <a
href="http://www.wisdom.weizmann.ac.il/~irani/abstracts/superResolution.html">here</a>).
<h2>Models of Program Input</h2>
<h3>Scalars</h3>
<p>The following conventions are used in this document to denote sets of scalar values:</p>
<table>
<tr><th>Symbol</th><th>Meaning</th>
<tr><td><b>NN</b><td>Set of integers &ge; 0.
<tr><td><b>R</b><td>Set of real numbers.
<tr><td><b>R<sup>+</sup></b><td>Set of real numbers &ge; 0.
</table>
<h3>RGB triples</h3>
An <i>RGB triple</i> is a member of the set
<b>R<sup>+</sup>&times;R<sup>+</sup>&times;R<sup>+</sup></b>. Components of an
RGB triple <b>t</b> are denoted <b>t<sub>R</sub>, t<sub>G</sub>,
t<sub>B</sub></b>.
<h3>Discrete Images</h3>
<p>For <b>d<sub>1</sub>, d<sub>2</sub> &isin; NN</b>, A <i>discrete image</i>
<b>D</b> of size <b>(d<sub>1</sub>, d<sub>2</sub>)</b> is a function
<blockquote>
<b>D: {0, 1, &hellip;, d<sub>1</sub> - 1}&times;{0, 1, &hellip;, d<sub>2</sub> - 1} &rarr; R<sup>+</sup>&times;R<sup>+</sup>&times;R<sup>+</sup></b>
</blockquote>
<p>The set of all discrete images is denoted <b>DD</b>.
<h3>Continuous Images</h3>
<p>For <b>c<sub>1</sub>, c<sub>2</sub> &isin; R<sup>+</sup></b>, a <i>continuous image</i> <b>I</b> of size <b>(c<sub>1</sub>, c<sub>2</sub>)</b> is a function
<blockquote>
<b>I: [0, c<sub>1</sub>]&times;[0, c<sub>2</sub>] &rarr; R<sup>+</sup>&times;R<sup>+</sup>&times;R<sup>+</sup></b>
</blockquote>
<p>The set of all continuous images is denoted <b>CC</b>.
<!--
An <i>infinite continuous image</i> <b>I</b> is a function
<blockquote>
<b>I: (-&infin;, &infin;)&times;(-&infin;, &infin;) &rarr; R<sup>+</sup>&times;R<sup>+</sup>&times;R<sup>+</sup></b>
</blockquote>
-->
<h3>Position and Direction</h3>
<p>A <i>position</i> is a point in Euclidean 3-space <b>R<sup>3</sup></b>.
<p>A <i>direction</i> is a point on the unit 3-sphere <b>S<sub>3</sub></b>.
<h3>Scene</h3>
<p>A <i>scene</i> <b>S</b> is a function
<blockquote>
<b>S: R<sup>3</sup> &times; S<sub>3</sub> &rarr; R<sup>+</sup>&times;R<sup>+</sup>&times;R<sup>+</sup></b>
</blockquote>
<p>mapping a position and direction to an RGB triple. The set of all scenes is denoted <b>SS</b>.
<h3>View</h3>
<p>A <i>view</i> <b>V</b> is a function
<blockquote>
<b>V: SS &rarr; CC</b>
</blockquote>
<h3>Camera Snapshots</h3>
<p>A <i>camera snapshot</i> is defined as a triple consisting of:</p>
<ul>
<li>A scene <i><b>S</b></i>.
<li>A view <i><b>V</b></i>.
<li>A function <i><b>d: CC &rarr; DD</b></i>.
</ul>
<h3>Camera Input Frame Sequences</h3>
<p>For positive integer <b>N</b>, a sequence of camera snapshots
<b>{ K<sub>1</sub>, K<sub>2</sub>, &hellip;, K<sub>N</sub> }</b>, defined by the
triples <b>{ K<sub>j</sub> = (S<sub>j</sub>, V<sub>j</sub>, d<sub>j</sub>)
}</b> is a <i>camera input frame sequence</i> if, for all <b>j</b> and
<b>j'</b>, <b>S<sub>j</sub> = S<sub>j'</sub></b>.
<h3>Projective transformations</h3>
<p>A <i>projective transformation</i> is a transformation that maps lines to
lines. For more details, see:
<blockquote>
Heckbert, Paul. "Projective Mappings for Image Warping." Excerpted from his
Master's Thesis (UC Berkeley, 1989). 1995. <a href="http://www.cs.cmu.edu/afs/cs/project/classes-ph/862.95/www/notes/proj.ps">http://www.cs.cmu.edu/afs/cs/project/classes-ph/862.95/www/notes/proj.ps</a>
</blockquote>
<h3>Projective Snapshots</h3>
<p>A <i>projective snapshot</i> is defined as an <i>n</i>-tuple consisting of:</p>
<ul>
<li>A continuous image <i><b>&Sigma;</b></i>.
<li>A projective transformation <i><b>q</b></i> with restricted domain, such that <i><b>composite(&Sigma;, q) &isin; CC</b></i>
<li>A function <i><b>d: CC &rarr; DD</b></i>.
</ul>
<h3>Projective Input Frame Sequences</h3>
<p>For positive integer <b>N</b>, a sequence of projective snapshots <b>{
P<sub>1</sub>, P<sub>2</sub>, &hellip;, P<sub>N</sub> }</b>, defined by the
<i>n</i>-tuples <b>{ P<sub>j</sub> = (&Sigma;<sub>j</sub>, q<sub>j</sub>,
d<sub>j</sub>) }</b>, is a <i>projective input frame sequence</i> if, for all
<b>j</b> and <b>j'</b>, <b>&Sigma;<sub>j</sub> = &Sigma;<sub>j'</sub></b>.
<p>The first frame in the sequence of input frames is called the <i>original
frame</i>, and subsequent frames are called <i>supplemental frames</i>.
<h3>Construction of Projective Input Frame Sequences from Camera Input Frame Sequences</h3>
<p>Given a camera input frame sequence <b>{ K<sub>j</sub> = (S, V<sub>j</sub>,
d<sub>j</sub>) }</b>, if there exists a continuous image <b>&Sigma;</b> and a
sequence <b>{ q<sub>j</sub> }</b> of projective transformations with restricted
domain such that, for all <b>j</b>, <b>V<sub>j</sub>(S) =
q<sub>j</sub>(&Sigma;)</b>, then this camera input frame sequence admits a
corresponding projective input frame sequence <b>{ P<sub>j</sub> = (&Sigma;,
q<sub>j</sub>, d<sub>j</sub>) }</b>.
<p>Informally, two cases where such construction is possible for an ideal
pinhole camera are:
<ul>
<li>A sequence of frames taken from a fixed position in space, but with variable
orientation.
<li>A sequence of frames depicting a single flat, diffuse surface, taken from
arbitrary positions and orientations.
</ul>
<p>For more information about the properties of projective transformations,
see the first of Steve Mann's papers referenced in the Related Work section above.
<h3>Projective Renderer without Extension</h3>
<p>For a projective input frame sequence <b>{ P<sub>j</sub> = (&Sigma;,
q<sub>j</sub>, d<sub>j</sub>) }</b>, a <i>projective renderer without
extension</i> is an algorithm that outputs a discrete image approximation of
<b>composite(&Sigma;, q<sub>1</sub>)</b>. The assumptions used in calculating the approximation
vary across rendering methods.
<h3>Projective Renderer with Extension</h3>
<p>For a projective input frame sequence <b>{ P<sub>j</sub> = (&Sigma;,
q<sub>j</sub>, d<sub>j</sub>) }</b>, a <i>projective rendering method with
extension</i> is an algorithm that outputs a discrete image approximation of
<b>composite(&Sigma;', q<sub>1</sub>')</b>, where <b>q<sub>1</sub>'</b> extends
the domain of <b>q<sub>1</sub></b> so that its range is a superset of the
domain of <b>&Sigma;</b>, and <b>&Sigma;'</b> extends <b>&Sigma;</b> to match
the range of <b>q<sub>1</sub>'</b>. The assumptions used in calculating the
approximation vary across rendering methods.
<!--
<h3>Diffuse Surfaces</h3>
Given a camera input frame sequence <b>{ C<sub>1</sub>, C<sub>2</sub>,
&hellip;, C<sub>N</sub> }</b>, defined by the <i>n</i>-tuples
<b>{&nbsp;C<sub>j</sub> = (S, R<sub>j</sub>, I<sub>j</sub>, D<sub>j</sub>,
d<sub>j</sub>)&nbsp;}</b>, a surface in <b>S</b> is <i>diffuse</i> if the
radiance of each point on the surface (as measured by the canonical sensor) is
the same for all views <b>R<sub>j</sub></b> from which the point is visible.
<h3>The Extended Pyramid</h3>
<p>If the view pyramids <b>{ R<sub>1</sub>, R<sub>2</sub>, &hellip;,
R<sub>N</sub> }</b> of a sequence of <b>N</b> camera input frames share a
common apex and can be enclosed in a single rectangular-base pyramid <b>R</b>
sharing the same apex and having base edges parallel to the base edges of
<b>R<sub>1</sub></b>, then the smallest such <b>R</b> is the <i>extended pyramid</i>.
Otherwise, the extended pyramid is undefined.</p>
<p>If a camera input frame sequence has an extended pyramid <b>R</b>, then an
<i>extended image</i> is defined from <b>R</b> in a manner analogous to the definition
of the image <i><b>I</b></i> from the view pyramid <i><b>R</b></i> in the
definition of a camera snapshot.
-->
<h2>Renderers</h2>
<!--
<h3>Examples</h3>
Examples of rendering output are available on the <a href="../render/">rendering
page</a>.
-->
<h3>Extension</h3>
<p>All renderers can be used with or without extension (according to whether
the --extend flag is used). The target image for approximation (either
<b>composite(&Sigma;, q<sub>1</sub>)</b> or <b>composite(&Sigma;',
q<sub>1</sub>')</b>) is generically called <b>T</b>.
<h3>Renderer Types</h3>
<p>Renderers can be of incremental or non-incremental type. Incremental
renderers update the rendering as each new frame is loaded, while
non-incremental renderers update the rendering only after all frames have been
loaded.</p>
<p>Incremental renderers contain two data structures that are updated with each
new frame: an accumulated image <b>A</b> with elements <b>A<sub>x, y</sub></b>
and the associated weight array <b>W</b> with elements <b>W<sub>x, y</sub></b>.
The accumulated image stores the current rendering result, while the weight
array stores information about contributions to each accumulated image pixel.
<h3>Renderer Details</h3>
These pages offer detailed descriptions of renderers.
<ul>
<li>Incremental Renderers</li>
<ul>
<li><a href="merging/">Merging</a>
<li><a href="drizzling/">Drizzling</a>
</ul>
<li>Non-incremental Renderers</li>
<ul>
<li><a href="enhance/">Unsharp Masking</a>
<li><a href="iterative/">Irani-Peleg</a>
</ul>
</ul>
<h3>Rendering Predicates</h3>
<p>The following table lists predicates which may be useful in determining
whether the discrete-image output of a rendering method approximates <b>T</b>.
The section following this lists, for each renderer, a collection of predicates
which should result in <b>T</b> being approximated.</p>
<blockquote>
<table border cellpadding=5>
<tr>
<th>Predicate</td>
<th>Explanation</th>
<tr>
<td>Alignment</td>
<td>The projective input frame transformations <b>q<sub>j</sub></b> are known.</td>
<tr>
<td>Translation</td>
<td>All projective input frame transformations <b>q<sub>j</sub></b> are
translations.</td>
<tr>
<td>Point sampling</td>
<td><b>(&forall;j) (&forall;x &isin; Domain[q<sub>j</sub>]) (d<sub>j</sub>(composite(T, q<sub>j</sub>))(x) = composite(T, q<sub>j</sub>)(x))</b>.
<tr>
<td>Box Filter Approximation</td>
<td>An acceptable discrete approximation of <b>T</b> can be achieved by
partitioning it into a square grid and representing each square region by its
mean value.
<tr>
<td>Jittering Assumption 1</td>
<td>The average of several point samples drawn uniformly from a region of
<b>T</b> is an acceptable approximation for the mean value of the region.
<tr>
<td>Jittering Assumption 2</td>
<td>Each region in <b>T</b> corresponding to an output pixel has been sampled several
times at points drawn uniformly from the region.
<tr>
<td>Small radius</td>
<td>The radius parameter used for drizzling is chosen to be sufficiently small.
<tr>
<td>Barlett filter approximation</td>
<td>Convolution of <b>T</b> with a Bartlett (aka triangle) filter remains an
acceptable approximation of <b>T</b>.
<tr>
<td>Linear PSF only</td>
<td>There is no non-linear PSF component.
<tr>
<td>USM approximation</td>
<td>The Unsharp Mask technique provides an acceptable approximation of the
inverse convolution for the given linear point-spread function.
<tr>
<td>Correct PSF</td>
<td>The behavior of <b>d<sub>j</sub></b> is equivalent to convolution with the
given point-spread functions.
<tr>
<td>Low Response Approximation</td>
<td>Frequencies to which <b>d<sub>j</sub></b> has low response need not be
accurately reconstructed in the program output.
<tr>
<td>Convergence</td>
<td>The Irani-Peleg technique converges to the desired output for the given
input sequence. This condition is proven for special cases in the source
paper.
</table>
</blockquote>
<h3>Rendering Predicates by Renderer</h3>
<p>For each renderer, the following table gives a collection of rendering
predicates that should result in rendered output being an acceptable
approximation of <b>T</b>. Note that renderers may produce acceptable output
even when these predicates are not satisfied. Justification for the entries in
this table should appear in the detailed descriptions; if this is not the case,
then the values given should be considered unreliable.</p>
<ul>
<li><b>M</b> = Merging
<li><b>D</b> = Drizzling
<li><b>U</b> = USM Renderer after merging
<li><b>V</b> = USM Renderer after drizzling
<li><b>I</b> = Irani-Peleg Iterative Image Reconstruction
</ul>
<blockquote>
<table border cellpadding=5>
<tr>
<th>&nbsp;</td>
<th>M</th>
<th>D</th>
<th>U</th>
<th>V</th>
<th>I</th>
<tr>
<td>Alignment</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<tr>
<td>Translation</td>
<td>X</td>
<td>&nbsp;</td>
<td>X</td>
<td>X</td>
<td>&nbsp;</td>
<tr>
<td>Point sampling
<td>X</td>
<td>X</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<tr>
<td>Box Filter Approximation
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>&nbsp;</td>
<tr>
<td>Jittering Assumption 1
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>&nbsp;</td>
<tr>
<td>Jittering Assumption 2
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>&nbsp;</td>
<tr>
<td>Small radius</td>
<td>&nbsp;</td>
<td>X</td>
<td>&nbsp;</td>
<td>X</td>
<td>&nbsp;</td>
<tr>
<td>Bartlett filter approximation</td>
<td>X</td>
<td>&nbsp;</td>
<td>X</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<tr>
<td>Linear PSF</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>X</td>
<td>X</td>
<td>&nbsp;</td>
<tr>
<td>USM approximation</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>X</td>
<td>X</td>
<td>&nbsp;</td>
<tr>
<td>Correct PSF</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>X</td>
<td>X</td>
<td>X</td>
<tr>
<td>Low Response Approximation</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td>X</td>
<tr>
<td>Convergence</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>X</td>
</table>
</blockquote>
<h3>Space Complexity</h3>
Image storage space in memory for all renderers without extension is
<i>O(1)</i> in the number of input frames and <i>O(n)</i> in the number of pixels per
input frame. The worst-case image storage space in memory for all renderers
with extension is <i>O(n)</i> in the size of program input.
<h2>Alignment Algorithm</h2>
Details on the alignment algorithm used in ALE are <a href="alignment/">here</a>.
<h2>Program Structure</h2>
<p>First, a <a href="merging/">merging</a> renderer is instantiated. Then,
program flags are used to determine what other renderers should be
instantiated.
<p>An iterative loop supplies to the renderers each of the frames in sequence,
beginning with the original frame. The <a href="drizzling/">drizzling</a> and
<a href="merging/">merging</a> renderers are incremental renderers, and
immediately update their renderings with each new frame, while the <a
href="enhance/">USM</a> and <a
href="iterative/">Irani-Peleg</a> renderers do not act until the final frame
has been received.
<p>In the case of the incremental renderers, the original frame is used without
transformation, and each supplemental frame is transformed according to the
results of the <a href="alignment/">alignment</a> algorithm, which aligns each
new frame with the current rendering of the <a href="merging/">merging</a>
renderer.
<p>Once all frames have been aligned and merged, non-incremental renderers
produce renderings based on input frames, alignment information, and the output
of other renderers.</p>
<h2>Examples</h2>
Sections below outline examples of cases in which output images satisfy various criteria.
<p>For a projective input frame sequence <b>{ P<sub>k</sub> = (&Sigma;, q,
d<sub>k</sub>) }</b>, these examples use the shorthand
<blockquote><b>I = composite(&Sigma;, q)</b></b></blockquote>
and
<blockquote><b>D<sub>k</sub> = d<sub>k</sub>(I).</b></blockquote></p>
<h3>Reduced Noise</h3>
<p>Assume a projective input frame sequence <b>{ P<sub>k</sub> }</b> of <b>K</b> frames, defined
by n-tuples <b>{ P<sub>k</sub> = (&Sigma;, q, d<sub>k</sub>) }</b>, such that
<b>(&exist;a &gt; 0) (&forall;x &isin; Domain[q]) (&forall;y &isin; {R, G, B})
(I(x)<sub>y</sub> &gt; a/2)</b> and, for one
such <b>a</b>, <b>(&forall;x) (&forall;y) (D<sub>k</sub>(x)<sub>y</sub> =
I(x)<sub>y</sub> + n<sub>k,x,y</sub>)</b>, where <b>n<sub>k,x,y</sub></b> are
i.i.d. additive noise terms having uniform distribution over the interval
<b>(-a/2, a/2)</b>.
<p>In this case, rendering input frames by merging or drizzling averages the
additive noise terms of the input images to produce an output additive noise
term; when <b>K &ge; 2</b>, this output noise has a smaller expected absolute value than that of
any given input noise term.
<p>To prove this, first observe that rendered output image <b>O</b> (for drizzling or merging) averages the <b>K</b> inputs with
equal weight:
<blockquote><b>O(x)<sub>y</sub> = &sum;<sub>k</sub> (D<sub>k</sub>(x)<sub>y</sub> / K)</b></blockquote>
Substituting for <b>D<sub>k</sub></b>:
<blockquote><b>O(x)<sub>y</sub> = &sum;<sub>k</sub> [(I(x)<sub>y</sub> + n<sub>k,x,y</sub>) / K]</b></blockquote>
Moving the constant outside of the sum:
<blockquote><b>O(x)<sub>y</sub> = (I(x)<sub>y</sub> / K) * K + &sum;<sub>k</sub> (n<sub>k,x,y</sub> / K)</b></blockquote>
<blockquote><b>O(x)<sub>y</sub> = I(x)<sub>y</sub> + &sum;<sub>k</sub> (n<sub>k,x,y</sub> / K)</b></blockquote>
The last term in the equation above is the noise term for the output image. Leaving location
and channel implicit, the expected absolute value for this term is:
<blockquote><b>E<sub>out</sub> = E[|&sum;<sub>k</sub> (n<sub>k</sub> / K)|]</b></blockquote>
Since there is nonzero probability that both strictly negative and strictly positive terms appear in the sum, this gives rise to the strict inequality:
<blockquote><b>E<sub>out</sub> &lt; E[&sum;<sub>k</sub> |n<sub>k</sub> / K|]</b></blockquote>
By linearity of expectation, this is equivalent to:
<blockquote><b>E<sub>out</sub> &lt; &sum;<sub>k</sub> E[|n<sub>k</sub> / K|]</b></blockquote>
<blockquote><b>E<sub>out</sub> &lt; &sum;<sub>k</sub> E[|n<sub>k</sub>|] / K</b></blockquote>
Since the input noise distributions are identical, this reduces to:
<blockquote><b>E<sub>out</sub> &lt; E<sub>in</sub> * K / K</b></blockquote>
<blockquote><b>E<sub>out</sub> &lt; E<sub>in</sub></b></blockquote>
where <b>E<sub>in</sub> = E[|n<sub>k</sub>|]</b> for any choice of k.
<h3>Reduced Aliasing</h3>
Assume that an image has been sampled at the highest frequency to which the
sensors respond (i.e., half of the Nyquist frequency), resulting in aliasing,
and that four such images are available, dithered (i.e., in this case,
translated) so that the collection of samples from all images forms a regular
grid with twice the sampling rate of the original image. Rendering these four
images with correct alignment into an output image having the same dimensions
as this grid results in an image with no aliased frequencies.
<h3>Increased Tonal Resolution</h3>
<p>Assume a projective input frame sequence <b>{ P<sub>k</sub> }</b> of
<b>K</b> frames, defined by n-tuples <b>{ P<sub>k</sub> = (&Sigma;, q,
d<sub>k</sub>) }</b>, such that components of <b>I</b> assume a real value in
the interval <b>[0, 1]</b> and <b>(&forall; x, y, k)
(Probability[D<sub>k</sub>(x)<sub>y</sub> = 1] = 1 - Probability[D<sub>k</sub>(x)<sub>y</sub> = 0] = I(x)<sub>y</sub>])</b>.
<p>Since the transformations of all frames are identical, rendering with
merging or drizzling averages the values for each pixel <b>D<sub>k</sub>(x)</b>
over all values of <b>k</b>. Since the expected value of <b>D<sub>k</sub>(x)</b>
is equal to <b>I(x)</b>, the expected value of the corresponding pixel in the rendered
output is always equal to <b>I(x)</b>. However, the probability of obtaining a value
within a small neighborhood of <b>I(x)</b> is generally not high for small numbers of
frames.
<p>As the number of frames increases, however, the probability of
obtaining a value within a neighborhood of any given size approaches 1. Hence,
arbitrarily high tonal resolution can be achieved with arbitrarily small (but
non-zero) likelihood of error. The exact probability can be determined
according to the binomial distribution.
<p>(The above constitutes an outline of a proof, but there may be holes in it.)
<h3>Increased Spatial Resolution</h3>
The reduced aliasing example, above, serves also as an example of increased
spatial resolution.
<h3>Increased Spatial Extents</h3>
<p>Assume a projective input frame sequence such that each snapshot can be
associated with a point in the scene invisible from that snapshot, but visible
from some other snapshot.
<p>In this case, for every snapshot in the input sequence, the output rendering
will include at least one point not present in that snapshot.
<small>
</small>
<br>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,166 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Irani-Peleg Renderer</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Irani-Peleg Renderer</h1>
<p>ALE implements an iterative image reconstruction algorithm based on Michal
Irani and Shmuel Peleg's paper "Improving Resolution by Image Registration",
published in <i>Graphical Models and Image Processing</i>, Vol. 53, No. 3, May,
pp. 231-239, 1991, or available at:
<p><a href="http://www.wisdom.weizmann.ac.il/~irani/abstracts/superResolution.html">http://www.wisdom.weizmann.ac.il/~irani/abstracts/superResolution.html</a>
<p>This algorithm iteratively performs two steps: first, an
approximation of <b>T</b> is projected, based on a filter approximating
<b>d<sub>j</sub></b>, and data collected during <a
href="../alignment/">alignment</a>, to create a set of simulated input frames;
second, the per-pixel error -- between these simulated input frames and the
actual input frames -- is calculated, backprojected, and subtracted from the
approximation of <b>T</b>, resulting in a new approximation of <b>T</b>.
<h2>Initial Image Approximation</h2>
<p>ALE uses the results of previous rendering steps as the initial image
approximation.</p>
<h2>Projection and Back-projection filters</h2>
ALE provides command-line options for selecting forward-projection filters,
including box filters (release 0.4.2 and later) and custom filters (release
0.4.7 and later). The back-projection filters are constructed from the
forward-projection filters in such a way that condition (9) from Theorem 4.1
in the source paper is satisfied.
<h2>Transformation details</h2>
<p>ALE's method of transforming pixel areas between coordinate systems
approximates transformed pixel boundaries with axis-aligned rectangular
regions. Since boundaries are transformed into the coordinate systems of the
input frames, this approximation can be improved by using larger scale factors
(and hence reducing the size of transformed pixels).</p>
<h2>Multi-level operation</h2>
<p>The following is an edited excerpt from the comment headers for the source
file <code>d2/render/ipc.h</code>. For more information about ALE's
implementation of multi-level operation, see the relevant source files.
<pre>
* The algorithm in the source paper looks something like this (PSF' is the
* backprojection kernel, and corresponds to what the authors of the paper call
* AUX):
*
* ===============================================================
* Forward Backward Binary Operators
* ---------------------------------------------------------------
*
* scene(n) ------> scene(n+1) <--- summation
*
* | ^
* | |
* PSF PSF'
* | |
* | ---------+ <--- difference
* V / |
*
* simulated(n) real
*
* ===============================================================
*
* This assumes a single colorspace representation. However, consumer cameras
* sometimes perform sharpening in non-linear colorspace, whereas lens and
* sensor blurring occurs in linear colorspace. Hence, there can be two
* colorspaces involved; ALE accounts for this with linear and non-linear
* colorspace PSFs. Hence, the algorithm we use looks something like:
*
* ===============================================================
* Forward Backward Binary Operators
* ---------------------------------------------------------------
*
* scene(n) -----> scene(n+1) <--- summation
*
* | ^
* | |
* LPSF LPSF'
* | |
* | ----------+ <--- difference,
* V / | exposure
* re-estimation
* lsimulated(n) lreal(n)
*
* | ^
* | |
* unlinearize linearize
* | |
* V |
*
* lsim_nl(n) -----> lreal_nl(n) <--- summation
*
* | ^
* | |
* NLPSF NLPSF'
* | |
* | ----------+ <--- difference
* V / |
*
* nlsimulated(n) real_nl
*
* ^
* |
* unlinearize
* |
* |
*
* real
*
* ===============================================================
</pre>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,94 @@
<html>
<title>Merging</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Merging</h1>
Merging uses bilinear interpolation to determine each frame's contribution to
the accumulated image, with each contribution assigned equal weight. Where
bilinear interpolation does not define a value, the accumulated image pixel is
not updated. Sections below outline the properties of this approach.
<h2>Properties</h2>
<h3>Convolution with the Bartlett (triangle) filter as the limiting case</h3>
<p>Assuming predicates for translation and point sampling, bilinear
interpolation is equivalent to convolution with a Bartlett filter. Combined
with the box filter approximation, jittering assumptions, and Bartlett filter
approximation, the result of merging should be an acceptable approximation of
<b>T</b>. This should be proven at some point. Until then, this result should
be considered unreliable.
<h3>Density and false local minima</h3>
<p>Informally, the merging method outlined above always updates a dense set
of pixels in the accumulated image. In particular, any accumulated image pixel
whose center falls on a line between updated pixels is also an updated pixel.
<p>It is conceivable that this property reduces the likelihood of alignment
failure due to entrapment in local minima; hence, the merging renderer is
always used as a reference for the <a href="../alignment/">alignment</a>
algorithm. Except in cases where a large radius is used, <a
href="../drizzling/">drizzling</a> does not share these properties.</p>
<!--
<p>Define a dense update method to be one that
<p>The merging method outlined above has the property of always updating a
dense set of pixels in the accumulated image (i.e. any accumulated image pixel
whose center falls on a line between updated pixels is also an updated pixel,
and all updated pixels are connected by a path consisting of only updated
pixels), even when the accumulated image is of finer resolution than the new
frame. This ensures that the area of defined pixels in the accumulated image
is dense and that any uniform change in intensity between frames is reflected
uniformly over a dense area. The absence of these properties may cause
alignment to fail due to entrapment in local minima, and so merging is always
used internally to create the renderings used by the alignment algorithm.
Except in the case of a large pixel footprint, <a
href="../drizzling">drizzling</a> does not share these properties.
-->
<br><br>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,201 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Alignment</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Alignment</h1>
Alignment compares each supplemental frame in the sequence with an intermediate
rendering known as the reference image. Based on this comparison, a
transformation is assigned to the supplemental frame. Many different
transformations can be assigned before alignment of the frame is complete.
<h2>Match statistics</h2>
The match statistic is a single number indicating how well two frames are
aligned; this number is used to select or reject transformations during
alignment. After alignment is complete, ALE displays the final match
statistic. If the value is close to 100%, then the frames are well aligned.
Very low values can indicate misalignment. However, even frames that are very
well aligned do not usually achieve 100% alignment, and, for improving image
quality, ALE works most effectively when match values are less than 100%.
<h3>Match threshold</h3>
A match threshold can be specified; no images with final match statistics
falling below this threshold will contribute to the final output.
<pre>
--threshold=x Min. match threshold; a perfect match is 100. (0 is default)
</pre>
<h3>Alignment error metric exponent</h3>
The function calculated at each pixel to determine the match statistic is known
as the alignment error metric, and is of the form <i>(a-b)<sup>x</sup></i>.
The value <i>x</i> is known as the error metric exponent, and is 2 by default.
Larger numbers usually mean that alignment will be more influenced by smaller
image features.
<pre>
--metric=x Set the alignment error metric exponent. (2 is default)
</pre>
<h3>Alignment Channel Options</h3>
In calculating the per-pixel error metric, there are three ways in which ALE
can handle color channels. By default, ALE adds the channels before
calculating the match. However, ALE can also rely solely on the green color
channel or use all three channels separately.
<pre>
--align-all Align images using all color channels
--align-green Align images using the green channel
--align-sum Align images using a sum of channels [default]
</pre>
<h3>Monte Carlo Alignment</h3>
Aligning large images can take a very long time if all pixels are examined in
determining the match statistic, so it is often desirable to examine a smaller
number of pixels. The Monte Carlo alignment option allows this. The number of
pixels used is specified as a percentage, and smaller numbers usually mean
faster, but less precise, alignment.
<pre>
--mc &lt;x> Align using, on average, x% of available pixels (0 &lt; x &lt; 100)
--no-mc Align using all pixels. [default]
</pre>
<h2>Perturbation</h2>
Every dot displayed after an input filename indicates a change in perturbation
size. The size is initially set to be high, allowing large changes in
alignment to be evaluated, and is reduced as the locally optimal alignment is
found for each size. When this size drops below a specified lower bound, the
frame is considered to be aligned.
<h3>Perturbation bounds</h3>
These options determine the upper and lower bounds for perturbation size. The
perturb-upper and perturb-lower bounds apply to rotation (in degrees),
translation (in pixels), and the movement of the boundaries of a projected
frame (in pixels). The rot-upper bound disables rotational perturbation above
a certain perturbation size (in degrees). To disable alignment, set
perturb-upper to zero.
<pre>
--perturb-upper=x Perturbation upper bound in pixels/degrees (32.0 is default)
--perturb-lower=x Perturbation lower bound in pixels/degrees (.125 is default)
--rot-upper=x Rotation-specific perturbation upper bound (32.0 is default)
</pre>
<h3>Level of detail</h3>
<p>Alignment at large perturbation sizes is usually carried out on
reduced-detail images. To disable this, set lod-max to
log<sub>2</sub>(perturb-upper).
<pre>
--lod-max=x LOD scale factor is max(1, (2^floor(x))/perturb) (1 is def.)
</pre>
<h2>Transformations</h2>
The variables used to adjust alignment are called transformations, and map
points from a source image to a target image.
<p>There are three transformation classes that can be used by ALE. The
translational class applies only translations to the inputs, changing only the
position of images; the Euclidean class applies translations and rotations; and
the projective class applies general projective transformations, which are the
most general type of transformation supported by ALE.
<p>The Euclidean class is most appropriate for use with scanners and as a first
pass for projective transformations. The projective class is most appropriate
for use with cameras.
<p>Except when capturing flat scenes, ALE does not correct for perspective
changes, so movement of cameras should ideally be constrained so that no large
translations occur.
<h3>Transformation Class Options</h3>
<pre>
--translation Only adjust the position of images
--euclidean Adjust the position and orientation of images [default]
--projective Use projective transformations. Best quality, but slow.
</pre>
<h3>Transformation data file options</h3>
Transformations used in alignment can be loaded from a file or saved to a file.
This can be useful when performing alignment in several passes, or when
refining rendering options.
<p>Note that projective transformation data saved to a file cannot be used to
initialize other transformation types.
<pre>
--trans-load=x Load initial transformation settings from file x
--trans-save=x Save final transformation data in file x
</pre>
<h3>Alignment following</h3>
When frames are more closely aligned with adjacent frames in the sequence than
they are with the first frame in the sequence, alignment success can be
improved by specifying the --follow option. This option can be effective even
when initial alignment information is loaded from a file.
<pre>
--identity Frames align closely with the original frame. [default]
--follow Frames align closely with their immediate predecessor.
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,90 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: File Output</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE File Output</h1>
File output options determine the format in which rendered images are written.
Depending on the compilation options used, available file output options vary.
<h2>PPM Output</h2>
All builds of ALE support PPM output. PPM can be written in plain (ASCII) or
raw (binary) format. If ALE has been built without ImageMagick support, or if
the file type cannot be automatically determined by file extension, then raw
PPM output is used by default.
<pre>
--raw Write raw PPM output
--plain Write plain PPM output
</pre>
<h2>Extension-based file type determination</h2>
If ALE has been built with ImageMagick support, then the output file type can
be determined automatically by file extension. This is the default behavior
for ImageMagick builds. The <code>--auto</code> flag explicitly specifies that
the default behavior should be used. This flag generates an error on builds
compiled without ImageMagick support.
<pre>
--auto Determine file type automatically
</pre>
<h2>Output Color Depth</h2>
Output color depth of 8 or 16 bits of precision per color channel can be specified,
for 24-bit or 48-bit color, respectively.
<pre>
--8bpc Write 8 bit per channel output [default]
--16bpc Write 16 bit per channel output
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,164 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE 0.6.0 User Manual</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../../user/">Up</a> | <a href="file/">File Output</a> | <a href="rendering/">Rendering</a> | <a href="alignment/">Alignment</a> ]</b></p>
<h1>ALE 0.6.0 User Manual</h1>
<h2>Purpose</h2>
<p>This page summarizes ALE program operation and command-line usage.
<p>Manual pages linked from this section describe <a href="file/">file
output</a>, <a href="rendering/">rendering</a> and <a
href="alignment/">alignment</a>.
<p>For more information on ALE, see the <a
href="http://auricle.dyndns.org/ALE/">ALE Home Page</a>.
<h2>Parameter Meta-syntax</h2>
<table>
<tr>
<td><code>&nbsp;&lt;foo></code></td>
<td>A required parameter called <i>foo</i>.</td>
</tr>
<tr>
<td><code>[&lt;foo>]</code></td>
<td>An optional parameter called <i>foo</i>.
</tr>
<tr>
<td><code>[&lt;foo>]*</code></td>
<td>Zero or more parameters <i>foo</i>.
</tr>
</table>
<h2>Command-line syntax for Image Processing</h2>
<p>The following command-line invocation can be used to process a series of
frames into an output file:
<pre>ale [&lt;option>]* &lt;original-frame> [&lt;supplemental-frame>]* &lt;output-file></pre>
<h3>Option Arguments</h3>
<p>Options are outlined in the manual pages describing <a href="file/">file
output</a>, <a href="rendering/">rendering</a> and <a
href="alignment/">alignment</a>.
<h3>Image Files</h3>
<p>ALE can be configured at compile time to use one of two different file
handlers. Execute 'ale --version' to determine which file handler is being
used. The table below outlines the supported formats for each file handler.</p>
<table border>
<tr><th>Version Message</th><th>File Types Supported</th>
<tr><td valign=top>
<pre>File handler: ImageMagick</pre>
</td>
<td>
<p>Input and output files can be any of the <a
href="http://imagemagick.sourceforge.net/www/formats.html">formats</a> supported by
ImageMagick.
</td>
<tr><td valign=top>
<pre>File handler: PPM</pre>
<td>
<p>Input files must be PPM, and output files are written as PPM.
</table>
<p>Note that many external programs, including ImageMagick's <a
href="http://www.imagemagick.org/">command line utilities</a>, can be used to
convert between PPM and other formats.</p>
<p>See the README included in the source distribution for more information about
compile-time configuration of file handlers.</p>
<h2>Command-line syntax for Version Information</h2>
<p>The following command-line invocation can be used to print version
information and build options:
<pre>ale --version</pre>
The following is sample output from this invocation:
<pre>
ALE Version: 0.6.0
File handler: ImageMagick
Color data: SINGLE
Coordinate data: SINGLE
DFT: Built-in
Assertions: Disabled
</pre>
<p>The first line of output indicates the version of ALE source code being
used, while the remaining lines reflect the build options selected at compile
time.
<p>For more information about build options, see the README file included in
the source distribution.
<h2>Command-line syntax for Help Output</h2>
When invoked with no options, or options detected as incorrect, ALE outputs a
help message specifying command-line usage and available options. The following
is a sample invocation:
<pre>ale</pre>
<h2>Related Manual Pages</h2>
<ul>
<li><a href="file/">File Output</a>
<li><a href="rendering/">Rendering</a>
<li><a href="alignment/">Alignment</a>
</ul>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,284 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Rendering</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Rendering</h1>
Rendering determines how an output image is constructed from a series of
aligned input frames. The incremental renderers, merging and drizzling, update
the output image after reading each new frame from the series, whereas
non-incremental renderers wait until the last frame has been loaded before
producing output. More than one renderer can be involved in producing the
final output. Available rendering options are outlined below.
<h2>Merging</h2>
Merging, the default incremental renderer, works most effectively on images
that have no large changes in scale (e.g. camera zooming). Since it uses
bilinear interpolation, output images are approximately convolved with the
triangle, or Bartlett, filter, and may appear to have reduced contrast and
resolution when compared with the output of other renderers.
<h2>Drizzling</h2>
The drizzling renderer is an incremental renderer that can usually produce
better images than merging, but it works most effectively with devices having
very little blur and optical distortion. Devices sampling very small angles of
the scene at each pixel are ideal; hence, if very fine staircase aliasing is
visible in the input frames, drizzling should work very well. (For creation of
higher resolution images with drizzling, use also the --scale option described
below.)
<pre>
--drizzle-diam=x Drizzle with input pixel diameter x (where x &gt; 0)
--drizzle-only If drizzling, output black for pixels with no drizzle data.
</pre>
<p>For more information about drizzling, see the paper by Richard Hook and
Andrew Fruchter, "Variable-Pixel Linear Combination", or the following URL:
<p><a href="http://www.cv.nrao.edu/adass/adassVI/hookr.html">http://www.cv.nrao.edu/adass/adassVI/hookr.html</a>
<h2>Point-spread Function (PSF)</h2>
<p>Non-incremental renderers use a point-spread function to model the optical
and electronic properties of the capture device used. The PSF can be specified
in terms of a linear and non-linear component. The non-linear component is
disabled by default.
<h3>Determining the PSF</h3>
<p>The point-spread function can be approximated through trial-and-error or
based on known scenes. ALE includes a script that numerically approximates the
point-spread function based on images captured from known scenes. This script
can be found in the source distribution
(<code>d2/render/psf/ale-psf-calibrate</code>).
<h3>Device Specification</h3>
If a device is known to ALE, then its PSF can be implicitly set with the device
option.
<pre>
--device &lt;d> Set the capture device to &lt;d>.
</pre>
Available devices are as follows:
<pre>
xvp610_320x240 IBM PC Camera Pro (XVP610) in 320x240 mode.
</pre>
<h3>PSF specification</h3>
<p>The PSF can also be explicitly specified by using one or both of the psf
options. These options have precedence over the device option.
<pre>
--lpsf &lt;p> Set linear colorspace point-spread function to &lt;p>
--nlpsf &lt;p> Set non-linear colorspace point-spread function to &lt;p>
</pre>
Available explicit point-spread functions are as follows:
<pre>
box=&lt;d> Set the PSF to a box filter with diameter &lt;d>.
stdin Specify a custom filter at runtime.
&lt;p>+&lt;p> Summation of two functions
</pre>
<h2>Unsharp Mask (USM) Renderer</h2>
<p>This non-incremental renderer uses an unsharp mask to compensate for
blur introduced by the image capture device. It is fairly inexpensive
computationally, but it may not be effective in all cases.
<pre>
--usm &lt;m> Apply an unsharp mask with multiplier &lt;m>.
</pre>
<h2>Irani-Peleg iterative solver</h2>
<p>This non-incremental renderer is very general, and attempts to reconstruct the
original scene based on the captured frames and the PSF. Unlike the USM
renderer, it can compensate for blur introduced by the incremental
renderers, and it may be more effective than the USM renderer in compensating
for blur introduced by the image capture device.
<p>Note that this method can take a long time to produce output. If
incremental output is enabled (see below), output is written after each
iteration is complete. Using more iterations will generally improve output, up
to the point of convergence, when additional iterations have no effect. A dot
is displayed to indicate the completion of each iteration.
<pre>
--ips &lt;i> Run &lt;i> iterations.
</pre>
<p>For more information on the iterative backprojection technique of Michal Irani and
Shmuel Peleg, see their paper, "Improving Resolution by Image Registration", at
<p><a href="ftp://ftp.wisdom.weizmann.ac.il/pub/irani/PAPERS/SR_CVGIP91.pdf">ftp://ftp.wisdom.weizmann.ac.il/pub/irani/PAPERS/SR_CVGIP91.pdf</a>
<h2>Exposure Registration</h2>
<p>By default, ALE adjusts an exposure model to minimize differences in tone
between frames. The option <code>--exp-noregister</code> indicates that
exposure should be assumed uniform across all frames. In this case, no
adjustment is performed.</p>
<pre>
--exp-register Register exposure between frames. [default]
--exp-noregister Assume uniform exposure across all frames.
</pre>
For more information about analyzing and processing images having differing
exposures, see Steve Mann's comparametric paper, at
<p><a href="http://wearcam.org/comparam.htm">http://wearcam.org/comparam.htm</a>
<h2>Certainty-weighted Rendering</h2>
<p>The exposure model in ALE includes an associated certainty function, which
quantifies the reliability of sensor measurements. By default, this function
is raised to the zeroth power to obtain uniform certainty for all measurements.
To specify a different certainty exponent, the option <code>--cx</code> can be
used.
<pre>
--cx &lt;x> Render with certainty exponent &lt;x>
--no-cx Render with uniform certainty. [default]
</pre>
Note that ALE uses a one-sided certainty function, biased by
backprojection value, in Irani-Peleg rendering. In some cases, this approach
seems to offer better results than the unbiased function used in drizzling and
merging. For more information on the certainty weighting approach used by ALE,
see the ALE source code.
<p>For more information on Steve Mann's original approach to certainty-weighted
rendering, see his comparametric paper, at
<p><a href="http://wearcam.org/comparam.htm">http://wearcam.org/comparam.htm</a>
<h2>Scale factor</h2>
Rendering with a larger scale factor causes internal data structures to store
more information, resulting in image output of the specified larger scale.
Larger scales can improve alignment precision and output image quality, but can
also increase alignment and rendering times.
<pre>
--scale=x Scale images by the factor x (where x is at least 1.0)
</pre>
<h2>Image extents</h2>
The --extend option records pixel data that falls outside of the region of the
first frame in the sequence. This can be useful for providing additional
alignment constraints or creating panoramic image mosaics. (See also the
description of the --follow option in the <a href="../alignment">alignment</a>
section.)
<pre>
--extend Increase image extents to accommodate all pixel data.
--no-extend Don't increase extents; crop to original frame. [default]
</pre>
<h2>Incremental output</h2>
By default, the output file is written every time a renderer completes an
update cycle. In order to suppress output until the final image is rendered,
specify the --no-inc option.
<pre>
--inc Produce incremental output. [default]
--no-inc Don't produce incremental output.
</pre>
<h2>Pixel replacement</h2>
<p>When using the merging or drizzling renderer, --replace indicates that each
new frame should replace the corresponding region of the rendering, instead of
being averaged with data from previous frames. This option was originally
suggested by Jeff Treece for use in stabilization of video streams. His
approach to stabilization is outlined below.
<h3>Video Stabilization</h3>
<p>If the files
<pre>0.ppm, 1.ppm, ..., 9.ppm</pre>
represent frames from an unstabilized video stream, then the following sequence
of commands may result in a stabilized sequence:
<pre>
ale --replace 0.ppm 1.ppm 1.stable.ppm
ale --replace 1.stable.ppm 2.ppm 2.stable.ppm
ale --replace 2.stable.ppm 3.ppm 3.stable.ppm
.
.
.
ale --replace 8.stable.ppm 9.ppm 9.stable.ppm
</pre>
<p>The resulting stabilized sequence would be:
<pre>0.ppm, 1.stable.ppm, 2.stable.ppm, ..., 9.stable.ppm</pre>
<h3>Option Syntax</h3>
<pre>
--replace Replace overlapping areas when merging and drizzling.
--no-replace Do not replace. [default]
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,138 @@
<html>
<title>Error</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> | <a href="mc/">Monte Carlo</a> ]</b></p>
<h1>Error</h1>
<p>Error calculations are used to determine whether a transformation is "good"
or not, and in particular, whether one transformation is better or worse than
another. A smaller error indicates a better transformation, from the perspective
of the alignment algorithm.
<p>ALE defines an error value for each pixel of the alignment reference image, and also
comprehensive error, which summarizes the error over all pixels.
<h3>Pre-Alignment Exposure Registration</h3>
<p>When exposure registration is enabled, ALE performs an exposure registration
step prior to alignment. The result of this step is dependent on the initial
alignment (this can be either the default initial alignment or an alignment
loaded from a transformation data file). See the source for more details.
<h3>Per-Pixel Error</h3>
<!-- <p>(Alternatives to normalization exist, including the use of inner products; see
Steve Mann's paper, available on the website linked in footnote 1, for a
discussion of alignment approaches.) -->
<!--
<p>Based on principle 2, ALE calculates the difference between each alignment reference
image pixel and the value with which it would be merged given a candidate
transformation. This latter value is the <i>overlapping value</i>, as
described in the section on <a href="../../merging/">merging</a>. This difference
is then raised by the error metric exponent, as specified by the --metric
option. The exponent defaults to 2.0 for ALE versions 0.1.0 and later, or 1.0
for version 0.0.0. Hence,
-->
<p>The per-pixel error for pixel <i>(i, j)</i> in the alignment reference
image <i>A</i>, frame <i>B</i>, and transformation <i>T</i>, is:
<p><blockquote>
<pre>
<i>p(i, j, A, B, T) = Abs( A(i, j) - B(T_inverse(i, j)) )<sup>metric_exponent</sup></i>
</pre>
</blockquote>
<p>where <i>Abs()</i> is the absolute value function and <i>B(T_inverse(i,
j))</i> is determined by bilinear interpolation (unless a different interpolant
is specified using <code>--afilter</code>). If not specified by the --metric
option, <i>metric_exponent</i> defaults to 2.
<p>For coordinates where B(T_inverse(i, j)) is not defined, the error is zero.
(Feedback from Angelo Pesce led to clarification of this point.)
<p>In addition to per-pixel error, a per-pixel <i>maximum error
estimator</i> is calculated, as follows:
<p><blockquote>
<pre>
<i>p_max(i, j, A, B, T) = Max( A(i, j), B(T_inverse(i, j)) )<sup>metric_exponent</sup></i>
</pre>
</blockquote>
<p>For coordinates where B(T_inverse(i, j)) is not defined, the maximum error
estimator is zero. (Feedback from Angelo Pesce led to clarification of this
point.)
<h3>Comprehensive Error</h3>
<p>There are two varieties of comprehensive error used by ALE: <i>exhaustive</i>
error (enabled by <code>--no-mc</code>) and <a
href="mc/"><i>Monte Carlo</i></a> error (enabled by <code>--mc</code>).
Whereas the exhaustive approach evaluates the error for each pixel in the
alignment reference image, the <a href="mc/">Monte Carlo</a> approach evaluates
only a subset of pixels.
<p>If we consider <i>Sum[]</i> to provide the sum over whatever subset of
pixels we are sampling (including possibly the set of all pixels), then the
comprehensive error function, for alignment reference image <i>A</i>, frame
<i>B</i>, and transformation <i>T</i>, is:
<p><blockquote>
<pre>
<i>E(A, B, T) = (Sum [ p(i, j, A, B, T) ] / Sum [ p_max(i, j, A, B, T) ])<sup>(1/metric_exponent)</sup></i>
</pre>
</blockquote>
<br><br>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any
medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,160 @@
<html>
<title>Monte Carlo Error</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Monte Carlo Error</h1>
<p>Use of Monte Carlo error can decrease the time required to align large images,
since performing coordinate transformations and memory accesses at every pixel
can be expensive. Sections in this page describe the motivation for Monte
Carlo alignment, the ratio calculations used, the sampling algorithm, cache
behavior for the algorithm, randomization approaches, typical deviations from
the specified ratios, special handling of level-of-detail, and practical
observations regarding the use of Monte Carlo error.
<h2>Motivation</h2>
<p>Performing large numbers of coordinate transformations and memory accesses in
order to determine alignment error can be computationally expensive. One
approach to mitigating this expense is to use reduced level-of-detail.
However, using reduced level-of-detail can also reduce alignment precision. In
particular, reducing the level of detail by a factor of two can make impossible
the task of precisely aligning a horizontal line one pixel high. However, if
just a few pixels from the line are sampled at full detail, exact alignment is
possible.
<h2>Ratio Calculations</h2>
<p>In Monte Carlo alignment, a ratio
<blockquote>
<i>s = (expected # of pixel
samples) / (# of total pixels in the accumulated image)</i>
</blockquote>
is specified. From this ratio, a new ratio
<blockquote>
<i>u = (expected # of unsampled pixels) / (expected # of sampled pixels)</i>
</blockquote>
is calculated. Pixels are sampled in such a manner that <i>u</i> is
approximately satisified.
<p>At this stage, the region of overlap with the new frame is not considered.
With a limited area of overlap, the number of actual samples contributing to
the final error value will typically be reduced proportionally. (Angelo Pesce
has pointed out that better approaches may be possible, wherein explicit
calculation of overlapping areas reduces the number of coordinate
transformations performed.)
<h2>Sampling Algorithm</h2>
<p>Pixels are considered in order of index, where the accumulated image pixel
at position <i>(i, j)</i> is numbered with an index <i>(i * width + j)</i>.
In order of index, we skip and sample pixels in such a manner that the
expected size of a run of consecutive skipped pixels preceding a sampled pixel
is <i>u</i>. We select the size of each run of consecutive skipped pixels as
follows:
<p>If <i>2 * u</i> is an integer, then we draw uniformly from integer values in
the interval <i>[0,2u]</i>. If it is not an integer, then we draw from integer values in
the interval <i>[0,2u + 1]</i> in such a manner that integer values in
<i>[0,2u]</i> are equally likely to be chosen.
<p>(Also, see the section below on interaction with level-of-detail.)
<h2>Cache behavior</h2>
<p>Since indices are monotonically increasing in memory address, this approach
to sampling may make effective use of memory cache where other approaches (e.g.
repeated random draws from the entire index space) would not.
<h2>Randomization</h2>
<p>ALE versions 0.4.7 and earlier do not reseed the pseudorandom number generator,
and so a new random subset is selected every time the error is evaluated.
Hence, as more or fewer of the pixels critical to alignment are sampled, the
reported alignment can worsen or improve even in the absence of any change in
transformation.
<p>With this approach, since many transformations are inspected during the
alignment of any given frame, it is likely, especially with greater precision
of alignment, that some measured differences between transformations are due to
a difference in sample sets rather than a difference in alignment accuracy.
<p>By reseeding the pseudorandom number generator, ALE versions 0.4.8 and later
instead use a consistent set of pixels from the accumulated image when
comparing two transformations. Tests sampling 3% of pixels from a set of
320x240 frames indicate that this approach improves alignment.
<h2>Sampling characteristics</h2>
<p>For an image with 100,000 pixels and specified
<i>s</i> in the interval <i>[0.005,0.995]</i>, ALE's sampling method results in
a ratio <i>s</i> within 0.000003 of the specified <i>s</i>. This number
improves with image size. (The results are outlined in a <a
href="ratios/">table</a>.) However, note that s only represents an expected
value, and the actual number of sampled pixels may vary by more than the
numbers given here.
<h2>Interaction with level-of-detail</h2>
<p>When reduced level-of-detail is used, the number of reduced-detail pixels
sampled is taken to be a percentage of the total number of pixels in the
full-detail image, rather than as a percentage of the total number of pixels in
the reduced-detail image. (When this fraction of pixels in the full-detail
image is more than the number of reduced-detail pixels available, all
reduced-detail pixels are used.) This may improve the likelihood of successful
alignment, but may also add overhead to the alignment process.
<br><br>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any
medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,255 @@
<html>
<head>
<title>Expected sample ratio for --mc &lt;x&gt; argument</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TD {padding-left: 0; padding-right: 0; border-width: 0}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: 640; clear: left}
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF" LINK="#0000EF" VLINK="#55188A" ALINK="#FF0000">
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
7119814098<br>
</table>
<pre>
Expected sample ratio for specified --mc &lt;x&gt; argument in a 100,000 pixel
image. This table illustrates the effects of a bug in ALE version 0.4.3.
Column A: Specified expected sample ratio x*10^-2
Column B: Expected sample ratio in release 0.4.4
Column C: Expected sample ratio in release 0.4.3
A B C (buggy)
0.005000 0.004997 0.004997
0.010000 0.009997 0.009997
0.015000 0.014997 0.014997
0.020000 0.019997 0.019997
0.025000 0.024997 0.024997
0.030000 0.029997 0.029995
0.035000 0.034997 0.034995
0.040000 0.039997 0.039997
0.045000 0.044997 0.044991
0.050000 0.049997 0.049997
0.055000 0.054997 0.054987
0.060000 0.059997 0.059984
0.065000 0.064997 0.064984
0.070000 0.069997 0.069975
0.075000 0.074997 0.074973
0.080000 0.079997 0.079997
0.085000 0.084997 0.084957
0.090000 0.089997 0.089964
0.095000 0.094997 0.094986
0.100000 0.099997 0.099997
0.105000 0.104997 0.104983
0.110000 0.109997 0.109945
0.115000 0.114997 0.114901
0.120000 0.119997 0.119895
0.125000 0.124997 0.124997
0.130000 0.129997 0.129858
0.135000 0.134997 0.134898
0.140000 0.139997 0.139847
0.145000 0.144997 0.144862
0.150000 0.149997 0.149795
0.155000 0.154997 0.154909
0.160000 0.159997 0.159719
0.165000 0.164997 0.164867
0.170000 0.169997 0.169756
0.175000 0.174997 0.174638
0.180000 0.179997 0.179839
0.185000 0.184997 0.184730
0.190000 0.189997 0.189526
0.195000 0.194997 0.194606
0.200000 0.199997 0.199997
0.205000 0.204997 0.204556
0.210000 0.209997 0.209354
0.215000 0.214997 0.214412
0.220000 0.219997 0.219750
0.225000 0.224997 0.224681
0.230000 0.229997 0.229272
0.235000 0.234997 0.234082
0.240000 0.239997 0.239128
0.245000 0.244997 0.244426
0.250000 0.249998 0.249997
0.255000 0.254998 0.254371
0.260000 0.259998 0.258926
0.265000 0.264998 0.263675
0.270000 0.269998 0.268631
0.275000 0.274998 0.273807
0.280000 0.279998 0.279218
0.285000 0.284998 0.284881
0.290000 0.289998 0.289338
0.295000 0.294998 0.293710
0.300000 0.299998 0.298243
0.305000 0.304998 0.302947
0.310000 0.309998 0.307830
0.315000 0.314998 0.312904
0.320000 0.319998 0.318180
0.325000 0.324998 0.323669
0.330000 0.329998 0.329386
0.335000 0.334998 0.334671
0.340000 0.339998 0.338773
0.345000 0.344998 0.343003
0.350000 0.349998 0.347366
0.355000 0.354998 0.351870
0.360000 0.359998 0.356520
0.365000 0.364998 0.361324
0.370000 0.369998 0.366290
0.375000 0.374998 0.371427
0.380000 0.379998 0.376742
0.385000 0.384998 0.382247
0.390000 0.389998 0.387950
0.395000 0.394998 0.393863
0.400000 0.399998 0.399998
0.405000 0.404998 0.403795
0.410000 0.409998 0.407690
0.415000 0.414998 0.411686
0.420000 0.419998 0.415788
0.425000 0.424998 0.419998
0.430000 0.429998 0.424322
0.435000 0.434998 0.428765
0.440000 0.439998 0.433332
0.445000 0.444998 0.438026
0.450000 0.449998 0.442855
0.455000 0.454998 0.447824
0.460000 0.459998 0.452939
0.465000 0.464998 0.458207
0.470000 0.469998 0.463635
0.475000 0.474998 0.469229
0.480000 0.479998 0.474998
0.485000 0.484998 0.480951
0.490000 0.489998 0.487095
0.495000 0.494998 0.493441
0.500000 0.499998 0.499998
0.505000 0.504998 0.503365
0.510000 0.509998 0.506801
0.515000 0.514998 0.510308
0.520000 0.519998 0.513887
0.525000 0.524998 0.517542
0.530000 0.529999 0.521275
0.535000 0.534999 0.525088
0.540000 0.539999 0.528984
0.545000 0.544999 0.532966
0.550000 0.549999 0.537036
0.555000 0.554999 0.541197
0.560000 0.559999 0.545453
0.565000 0.564999 0.549807
0.570000 0.569999 0.554262
0.575000 0.574999 0.558822
0.580000 0.579999 0.563491
0.585000 0.584999 0.568272
0.590000 0.589999 0.573169
0.595000 0.594999 0.578188
0.600000 0.599999 0.583332
0.605000 0.604999 0.588606
0.610000 0.609999 0.594016
0.615000 0.614999 0.599566
0.620000 0.619999 0.605262
0.625000 0.624999 0.611110
0.630000 0.629999 0.617116
0.635000 0.634999 0.623287
0.640000 0.639999 0.629628
0.645000 0.644999 0.636149
0.650000 0.649999 0.642856
0.655000 0.654999 0.649757
0.660000 0.659999 0.656862
0.665000 0.664999 0.664178
0.670000 0.669999 0.668341
0.675000 0.674999 0.670885
0.680000 0.679999 0.673468
0.685000 0.684999 0.676091
0.690000 0.689999 0.678755
0.695000 0.694999 0.681461
0.700000 0.699999 0.684210
0.705000 0.704999 0.687002
0.710000 0.709999 0.689839
0.715000 0.714999 0.692721
0.720000 0.719999 0.695651
0.725000 0.724999 0.698629
0.730000 0.729999 0.701657
0.735000 0.734999 0.704735
0.740000 0.739999 0.707864
0.745000 0.744999 0.711047
0.750000 0.749999 0.714285
0.755000 0.754999 0.717578
0.760000 0.759999 0.720929
0.765000 0.764999 0.724339
0.770000 0.769999 0.727810
0.775000 0.774999 0.731343
0.780000 0.780000 0.734939
0.785000 0.785000 0.738601
0.790000 0.790000 0.742331
0.795000 0.795000 0.746129
0.800000 0.800000 0.749999
0.805000 0.805000 0.753943
0.810000 0.810000 0.757961
0.815000 0.815000 0.762057
0.820000 0.820000 0.766233
0.825000 0.825000 0.770491
0.830000 0.830000 0.774834
0.835000 0.835000 0.779264
0.840000 0.840000 0.783783
0.845000 0.845000 0.788395
0.850000 0.850000 0.793103
0.855000 0.855000 0.797909
0.860000 0.860000 0.802817
0.865000 0.865000 0.807829
0.870000 0.870000 0.812949
0.875000 0.875000 0.818181
0.880000 0.880000 0.823529
0.885000 0.885000 0.828996
0.890000 0.890000 0.834586
0.895000 0.895000 0.840304
0.900000 0.900000 0.846154
0.905000 0.905000 0.852140
0.910000 0.910000 0.858268
0.915000 0.915000 0.864542
0.920000 0.920000 0.870968
0.925000 0.925000 0.877551
0.930000 0.930000 0.884297
0.935000 0.935000 0.891213
0.940000 0.940000 0.898305
0.945000 0.945000 0.905579
0.950000 0.950000 0.913043
0.955000 0.955000 0.920705
0.960000 0.960000 0.928571
0.965000 0.965000 0.936652
0.970000 0.970000 0.944954
0.975000 0.975000 0.953488
0.980000 0.980000 0.962264
0.985000 0.985000 0.971292
0.990000 0.990000 0.980583
0.995000 0.995000 0.990148

View File

@@ -0,0 +1,180 @@
<html>
<title>Alignment</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> | <a href="error/">Error Function</a> ]</b></p>
<h1>Alignment</h1>
<p>ALE aligns each supplemental frame, in sequence, with an <i>alignment
reference image</i> constructed from previous frames. This page outlines
supported transformation classes, the algorithm used for alignment, and the
properties of the alignment algorithm. Following this is a discussion of
practical use of alignment options, including alignment classes and alignment
in the case of spatial extension.
<h2>Transformations</h2>
<p>ALE offers the following classes of transformations: </p>
<table border>
<tr><td>Translations</td><td>introduced in version 0.0.0</td>
<tr><td>Euclidean transformations (excluding reflections)</td><td>introduced in version 0.1.0</td>
<tr><td>Projective transformations</td><td>introduced in version 0.2.0</td>
<tr><td>Barrel distortion correction</td><td>introduced in version 0.7.0</td>
</table>
<h2>Algorithm</h2>
<p>Alignment proceeds by a deterministic search, beginning with an initial
transformation and modifying this transformation through a series of
perturbations.
<p>The initial transformation may be loaded from a file (when
<code>--trans-load</code> is used) or selected by default, or may be the
result of a global search (when <code>--gs</code> is used [0.7.1 only]). The
default initial transformation is either the transformation of the original
frame (when the <code>--identity</code> option is specified) or the most
recently aligned frame's final alignment (when the <code>--follow</code> option
is specified). When the initial transformation is loaded from a file, and if
the <code>--follow</code> option is specified, any changes to the alignment of
the previous frame are applied to the current frame at the outset.
<p>Once the initial transformation is determined, an initial perturbation
amount determines the step size by which each of the transformation parameters
are changed. In translational or Euclidean alignment, the perturbation amount
is applied to translation -- in units of pixels on the two image axes -- and
rotation -- in units of degrees about the image center. An additional
configurable upper bound, <code>--rot-upper</code>, constrains rotational
perturbation separately, preventing, e.g., a 360 degree perturbation of
rotation. In the case of projective alignment, the perturbation amount is
applied to the position of the corners of the projected quadrilateral in units
of pixels, where the projection is from the boundary of the supplemental frame
into the coordinate system of the alignment reference image. In the case of barrel
distortion correction, the perturbation amount is scaled by a multiplier
(<code>--bda-mult</code>) before being applied to each barrel distortion
coefficient (if any have been defined). The rate of change of barrel distortion
coefficients per frame can be limited with the option <code>--bda-rate</code>.
<p>If possible, transformation parameters are changed to decrease the <a
href="error/">error</a> between the supplemental frame and the alignment reference
image. The perturbation amount is halved whenever it is determined that no
parameter change of the current perturbation size improves the alignment of the
images. A lower bound on the perturbation amount determines when the alignment
is complete.
<!--
XXX: Even if this was true at one point, it appears to no longer be true.
<p>The order in which parameters are considered for change is specified in the
source code, and has the following property: No modified parameter is
considered for further change until all other parameters have been considered.
A consequence of this property is that parameters are always considered in a
fixed (round robin) order.
-->
<p>When multiple levels of detail are used, the error may be calculated on
images with a reduced level of detail. By default, this version of ALE uses a
level of detail twice as fine as the perturbation amount for perturbation
amounts larger than two, and full detail otherwise. This behavior can be changed
by adjusting the <code>--lod-max</code> option.
<!--
Is this useful to anyone?
<h2>Use of Alignment Classes</h2>
<p>ALE is likely to be most useful when corresponding regions of different
frames can be aligned by one of the available alignment classes.
<p>As described by Steve Mann in his work on <a
href="http://wearcam.org/orbits/">Video Orbits</a>, the projective
transformation offers particular versatility for camera imaging of (ideal
Lambertian) flat scenes.
<p>In camera imaging of scenes with depth, correction for orientation is almost
the same as for flat scenes, since, if focus and lens distortion is ignored, a
scene with depth is indistinguishable from a flat scene from the perspective of
a camera whose position is fixed.
<p>For sequences of camera images with small changes in position or
orientation, the projective transformations for alignment may closely
approximate Euclidean transformations; in this case, using Euclidean
transformations may achieve similar results and may require less time for
alignment, since there are fewer parameters to tweak (three parameters
instead of eight).
<p>In the case of flatbed scanners that preserve the relative height and width
of scans, any change in the position or orientation of flat objects can be
corrected using the Euclidean alignment class.</p>
<p>If a flatbed scanner does not preserve relative height and width, but does
preserve straight lines, then any change in the position or orientation of flat
objects can be corrected with the projective alignment class.
<p>However, even if a transformation is within the alignment class used, the
alignment algorithm may still be unable to approximate it.
<h2>Alignment in the case of Extended Renderings</h2>
<p>By using the --extend flag, ALE can be used to create image mosaics spanning
a spatial region larger than that represented by any single image in the frame
sequence. In these cases, if adjacent frames in the sequence tend to be more
closely aligned with each other than they are with the original frame, it may
be helpful to also use the --follow flag as a hint to the alignment algorithm.
</p>
-->
<br><br>
<small>
</small>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any
medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,122 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE Certainty</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Certainty</h1>
<p>When used with a sequence of differently-exposed images, the certainty
techniques implemented in ALE may produce output having higher fidelity overall
than that of any single exposure.
<h2>Motivation</h2>
<p>When multiple, differently-exposed images of the same scene are available,
variations of intensity visible in one image might not be visible in another.
In particular, if the difference between maximal light and dark values in the
scene exceeds the range of the image capture apparatus, then no single exposure
can faithfully record the scene. Using multiple exposures allows discernment
of at least as many details as any single exposure in the set can provide, and
may allow discernment of more details, and better estimates of intensities.
<h2>Related Work</h2>
<p>Steve Mann's original approach to certainty is described in his <a
href="http://wearcam.org/comparam.htm">comparametric paper</a>. ALE extends
his approach to Irani-Peleg rendering by defining certainty for (intensity,
correction) pairs (in versions 0.7.x) and by basing certainty on estimated
intensities (in version 0.8.0).
<h2>Two-sided Certainty</h2>
<p>Two-sided certainty operator <b>&kappa;</b> is used by ALE's incremental
renderer, and applies a parameterized heuristic function:
<blockquote>
<b>&kappa;d(i, j) = max(0.001, [1 - 4 * (0.5 - d(i, j))<sup>2</sup>]<sup>k</sup>)</b>
</blockquote>
Where all operations are applied componentwise, and <b>k</b> is the certainty
exponent parameter.
<h2>Symmetrically One-sided Certainty</h2>
<p>Symmetrically one-sided certainty is used by ALE's Irani-Peleg renderer in
versions 0.7.x, and is calculated using the direction of bias of a correction
<b>c(i, j)</b> against a modeled pixel value <b>m(i, j)</b>. The following
expression assumes the range of <b>m</b> to be <b>[0, 1]</b>, and expresses
condition using the C trinary if-else operator:
<blockquote>
<b>&Kappa;(c, m, i, j) = [c(i, j) * (m(i, j) - 0.5) > 0] ? 1 : &kappa;d(i, j)</b>
</blockquote>
<P>Where all operations are applied componentwise, and <b>&kappa;</b> is the
operator for two-sided certainty.</p>
<h2>Asymmetrically one-sided certainty</h2>
Asymmetrically one-sided certainty applies the one-sided condition asymmetrically.
<blockquote>
<b>&Kappa;'(c, m, i, j) = [c(i, j) > 0 && (m(i, j) - 0.5) > 0] ? 1 : &kappa;d(i, j)</b>
</blockquote>
<h2>Estimate-based Certainty</h2>
<p>Estimate-based certainty uses an estimate of intensity, rather than measured
intensity, to determine certainty, and can be used in a one-sided or two-sided
way. ALE version 0.8.0 uses estimate-based asymmetrically one-sided certainty
to weight Irani-Peleg correction values.</p>
<br>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,347 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE Rendering Chains</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Rendering Chains</h1>
<p>In cases of spatially non-uniform resolution, rendering chains can maintain low
aliasing in poorly-resolved regions while preserving detail in well-resolved
regions. Each chain is based on a sequence of rendering invariants, each
allowing first, last, average, minimum, or maximum pixel values to be rendered.
For a given invariant, exclusion regions are honored by default, but can
optionally be ignored. Finally, for a given invariant, resolution can be
limited to the minimum of the input and output images, to prevent aliasing, or
can use the full resolution of the output image, to prevent loss of fine
details.</p>
<h2>Parameters</h2>
Parameters for rendering chain or rendering invariant <b>r</b> are as follows:</b>
<blockquote>
<b>r(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>)</b>
<br><br>
<table>
<tr><th align=left>Parameter<th><pre> </pre><th align=left>Description</tr>
<tr><td>n</td><td></td><td> the number of images contributing to output</tr>
<tr><td>n'</td><td></td><td> the current image index</tr>
<tr><td>(i, j)</td><td></td><td> the output pixel position</tr>
<tr><td>(i', j')</td><td></td><td> the pixel position in the current image</tr>
<tr><td>E<sub>x</sub></td><td></td><td> linear exposure adjustment for image x</tr>
<tr><td>G</td><td></td><td> gamma correction</tr>
<tr><td>P<sub>x</sub></td><td></td><td> projective transformation for image x</tr>
<tr><td>B<sub>x</sub></td><td></td><td> barrel distortion for image x</tr>
<tr><td>d<sub>x</sub></td><td></td><td> image x</tr>
</table>
</blockquote>
Parameters for scaled sampling filter with exclusion (SSFE) <b>e</b> are as follows:
<blockquote>
<b>e(n', i, j, i', j', E, G, P, B, d)</b>
<br><br>
<table>
<tr><th align=left>Parameter<th><pre> </pre><th align=left>Description</tr>
<tr><td>n'</td><td></td><td> the current image index</tr>
<tr><td>(i, j)</td><td></td><td> the output pixel position</tr>
<tr><td>(i', j')</td><td></td><td> the input pixel position</tr>
<tr><td>E</td><td></td><td> linear exposure adjustment</tr>
<tr><td>G</td><td></td><td> gamma correction</tr>
<tr><td>P</td><td></td><td> projective transformation</tr>
<tr><td>B</td><td></td><td> barrel distortion</tr>
<tr><td>d</td><td></td><td> image</tr>
</table>
</blockquote>
Parameters for scaled sampling filter (SSF) <b>s</b> are as
follows:</b>
<blockquote>
<b>s(i, j, i', j', P, B, k)</b>
<br><br>
<table>
<tr><th align=left>Parameter<th><pre> </pre><th align=left>Description</tr>
<tr><td>(i, j)</td><td></td><td> the output pixel position</tr>
<tr><td>(i', j')</td><td></td><td> the input pixel position</tr>
<tr><td>P</td><td></td><td> projective transformation</tr>
<tr><td>B</td><td></td><td> barrel distortion</tr>
<tr><td>k</td><td></td><td> certainty values</tr>
</table>
</blockquote>
Parameters for sampling filter <b>f</b> are as follows:</b>
<blockquote>
<b>f(p)</b>
<br><br>
<table>
<tr><th align=left>Parameter<th><pre> </pre><th align=left>Description</tr>
<tr><td>p</td><td></td><td>position offset p = (i, j)</tr>
</table>
</blockquote>
<h2>Chains</h2>
<p>A chain <b>c</b> is based on a sequence of rendering invariants <b>v<sub>1</sub>, v<sub>2</sub>, ..., v<sub>max</sub></b>. For each <b>v<sub>x</sub></b>, define <b>w<sub>x</sub></b>:
<blockquote>
<b>w<sub>x</sub>(n, i, j, E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) = &sum;<sub>n'&isin;0..n</sub> &sum;<sub>(i', j')&isin;Dom[d<sub>n'</sub>]</sub> v<sub>x</sub>(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>)</b>
</blockquote>
If <b>w<sub>t</sub></b> is the weight threshold (ALE option 'wt'), and there exists a smallest <b>x</b> such that:
<blockquote>
<b>w<sub>x</sub>(n, i, j, E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) &ge; w<sub>t</sub></b>
</blockquote>
Then <b>c</b> gives:
<blockquote>
<b>c(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) = v<sub>x</sub>(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) / w<sub>x</sub>(n, i, j, E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>)</b>
</blockquote>
Otherwise, <b>c</b> gives:
<blockquote>
<b>c(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) = v<sub>max</sub>(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) / w<sub>max</sub>(n, i, j, E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>)</b>
</blockquote>
If both of the expressions above are undefined, then <b>c</b> gives:
<blockquote>
<b>c(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) = 0</b>
</blockquote>
<h2>Invariants</h2>
<p>There are five types of rendering invariants, all of which are parameterized
with a scaled sampling filter with exclusion, denoted here by the symbol <b>e</b>. In particular, an
invariant can be of initial, final, maximal, minimal, or average type.
<h3>Initial</h3>
<p>If an invariant <b>v</b> is of initial type, then choose the smallest <b>m</b> such that
the following expression is non-zero:
<blockquote>
<b>&sum;<sub>(i',j')&isin;Dom[d<sub>m</sub>]</sub> e(m, i, j, i', j', E<sub>m</sub>, G, P<sub>m</sub>, B<sub>m</sub>, d<sub>m</sub>)</b>
</blockquote>
If such an <b>m</b> can be chosen, then, using the C trinary if-else operator to express condition:
<blockquote>
<b>v(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) = (n' == m) ? e(m, i, j, i', j', E<sub>m</sub>, G, P<sub>m</sub>, B<sub>m</sub>, d<sub>m</sub>) : 0</b>
</blockquote>
Otherwise:
<blockquote> <b>v(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) = 0</b>
</blockquote>
<h3>Final</h3>
<p>If an invariant <b>v</b> is of final type, then choose the largest <b>m</b> such that
the following expression is non-zero:
<blockquote>
<b>&sum;<sub>(i',j')&isin;Dom[d<sub>m</sub>]</sub> e(m, i, j, i', j', E<sub>m</sub>, G, P<sub>m</sub>, B<sub>m</sub>, d<sub>m</sub>)</b>
</blockquote>
If such an <b>m</b> can be chosen, then, using the C trinary if-else operator to express condition:
<blockquote>
<b>v(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) = (n' == m) ? e(m, i, j, i', j', E<sub>m</sub>, G, P<sub>m</sub>, B<sub>m</sub>, d<sub>m</sub>) : 0</b>
</blockquote>
Otherwise:
<blockquote> <b>v(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) = 0</b>
</blockquote>
<h3>Minimal</h3>
<p>If an invariant <b>v</b> is of minimal type, then choose <b>m</b> such that the following
expression is defined and minimal:
<blockquote>
<b>&sum;<sub>(i',j')&isin;Dom[d<sub>m</sub>]</sub> E<sub>m</sub><sup>-1</sup>G<sup>-1</sup>d<sub>m</sub>(i',j') * e(m, i, j, i', j', E<sub>m</sub>, G, P<sub>m</sub>, B<sub>m</sub>, d<sub>m</sub>) / &sum;<sub>(i',j')&isin;Dom[d<sub>m</sub>]</sub> e(m, i, j, i', j', E<sub>m</sub>, G, P<sub>m</sub>, B<sub>m</sub>, d<sub>m</sub>)</b>
</blockquote>
If such an <b>m</b> can be chosen, then, using the C trinary if-else operator to express condition:
<blockquote>
<b>v(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) = (n' == m) ? e(m, i, j, i', j', E<sub>m</sub>, G, P<sub>m</sub>, B<sub>m</sub>, d<sub>m</sub>) : 0</b>
</blockquote>
Otherwise:
<blockquote>
<b>v(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) = 0</b>
</blockquote>
<h3>Maximal</h3>
<p>If an invariant <b>v</b> is of maximal type, then choose <b>m</b> such that the following
expression is defined and maximal:
<blockquote>
<b>&sum;<sub>(i',j')&isin;Dom[d<sub>m</sub>]</sub> E<sub>m</sub><sup>-1</sup>G<sup>-1</sup>d<sub>m</sub>(i',j') * e(m, i, j, i', j', E<sub>m</sub>, G, P<sub>m</sub>, B<sub>m</sub>, d<sub>m</sub>) / &sum;<sub>(i',j')&isin;Dom[d<sub>m</sub>]</sub> e(m, i, j, i', j', E<sub>m</sub>, G, P<sub>m</sub>, B<sub>m</sub>, d<sub>m</sub>)</b>
</blockquote>
If such an <b>m</b> can be chosen, then, using the C trinary if-else operator to express condition:
<blockquote>
<b>v(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) = (n' == m) ? e(m, i, j, i', j', E<sub>m</sub>, G, P<sub>m</sub>, B<sub>m</sub>, d<sub>m</sub>) : 0</b>
</blockquote>
Otherwise:
<blockquote>
<b>v(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) = 0</b>
</blockquote>
<h3>Average</h3>
<p>If an invariant <b>v</b> is of average type, then:
<blockquote>
<b>v(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>) = e(n', i, j, i', j', E<sub>n'</sub>, G, P<sub>n'</sub>, B<sub>n'</sub>, d<sub>n'</sub>)</b>
</blockquote>
<h2>Scaled Sampling Filter with Exclusion (SSFE)</h2>
<p>A scaled sampling filter with exclusion <b>e</b> is parameterized with a scaled sampling filter <b>s</b>, and
can be of two types: it can either honor exclusion regions or not. Define
<b>is_exclude(n', i, j)</b> to be false if point <b>(i, j)</b> is not excluded
for frame <b>n'</b>, or if exclusion regions are not being honored. Then,
using the C trinary if-else operator to express condition:
<blockquote>
<b>e(n', i, j, i', j', E, G, P, B, d) = is_exclude(n', i, j) ? 0 : s(i, j, i', j', P, B, &kappa;G<sup>-1</sup>E<sup>-1</sup>d)</b>
</blockquote>
<p>Where <b>&kappa;</b> is the operator for <a href="../certainty/">certainty</a>.
<h2>Scaled Sampling Filter (SSF)</h2>
<p>Define <b>bayer(i, j)</b> to be a function that returns an RGB value whose
channels are either zero or one, depending on whether that color is sampled at
<b>(i, j)</b>.
<p>A scaled sampling filter <b>s</b> is parameterized with a sampling filter
<b>f</b>, and can be one of two types: fine or coarse. If it is fine, then,
using <b>P</b> and <b>B</b> as functions:
<blockquote>
<b>s(i, j, i', j', P, B, k) = bayer(i', j') * k(i', j') * f(B(P(i', j')) - (i, j))</b>
</blockquote>
<p>If SSF <b>s</b> is coarse, then color channels are handled separately,
depending on their density relative to the output image, at point <b>(i, j)</b>
in the output image. In particular, bayer patterns can cause some colors to be
more dense than others. If the local density of channel <b>h</b> is lower in
each dimension than the density of channel <b>h</b> in the output image, then:
<blockquote>
<b>[s(i, j, i', j', P, B, k)]<sub>h</sub> = [bayer(i', j') * k(i', j') * f((i', j') - P<sup>-1</sup>(B<sup>-1</sup>(i, j)))]<sub>h</sub></b>
</blockquote>
<p>Otherwise, if channel <b>h</b> is locally less dense by a factor <b>d</b> in
exactly one dimension of the input image, then set <b>d_pair</b> equal to
<b>(1, d)</b> or <b>(d, 1)</b>, according to the dimension, and:
<blockquote>
<b>[s(i, j, i', j', P, B, k)]<sub>h</sub> = [bayer(i', j') * k(i', j') * f(d_pair * (B(P(i', j')) - (i, j)))]<sub>h</sub></b>
</blockquote>
<p>Otherwise, channel <b>h</b> is locally at least as dense in both dimensions of
the input image as it is dense in the output image. In this case:
<blockquote>
<b>[s(i, j, i', j', P, B, k)]<sub>h</sub> = [bayer(i', j') * k(i', j') * f(B(P(i', j')) - (i, j))]<sub>h</sub></b>
</blockquote>
<h2>Sampling Filter</h2>
<p>Sampling filters can be one of the following:</p>
<table>
<tr><th align=left>Type</th><th><pre> </pre></th><th align=left>Description</th></tr>
<tr><td>sinc<td><td>Sinc filter: (sin &pi;x) / (&pi;x)</td>
<tr><td>lanc:&lt;x&gt;<td><td>Lanczos, diameter x.
<tr><td>triangle:&lt;x&gt;<td><td>Triangle, diameter x.
<tr><td>box:&lt;x&gt;<td><td>Box, diameter x.
<tr><td>zero<td><td>Zero function
<tr><td>&lt;f&gt;*&lt;f&gt;<td><td>Pointwise multiplication (windowing)
</table>
<br>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.4 KiB

View File

@@ -0,0 +1,222 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE Version 0.7.x/0.8.x Technical Description</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../../tech/">Up</a> ]</b></p>
<h1>ALE Version 0.7.x/0.8.x Technical Description <!-- <small>(or the best approximation to date)</small> --> </h1>
<h2>Purpose</h2>
<p>This page discusses motivation, related work, models of program input,
renderers, and the alignment algorithm, but does not cover the 3D scene
reconstruction code in versions 0.7.2 and later. Note also that some changes
in 0.8.x might not yet be covered. For information on ALE program operation and
usage, see the User Manual for <a href="../ale-0.7.x-user/">0.7.x</a> or <a
href="../ale-0.8.x-user/">0.8.x</a>.</p>
<p><b>Note: This document uses HTML 4 character entities. &nbsp;Sigma is '&Sigma;'; summation is '&sum;'</b>.</p>
<h2>Motivation</h2>
<p>Several factors in the imaging pipeline can affect output, sometimes
degrading image quality, either individually or through combination. Lens
effects include barrel or pincushion distortion; the camera sensor and
electronics can produce blurring, signal aliasing, noise, quantization, and
non-linear effects; analog video signals can degrade in transmission; and
various compression techniques and digital enhancements on- or off-camera can
destroy image features. In some cases, a better image can be produced through
combining information contained in different images.</p>
<table>
<tr><td align=center><img src="conceptual_pipeline.png"></td></tr>
<tr><td align=center><i>Imaging Pipeline</i></td></tr>
</table>
<h2>Related Work</h2>
<p>Richard Hook and Andrew Fruchter's <a
href="http://www.cv.nrao.edu/adass/adassVI/hookr.html">drizzling technique</a> was designed
to combine dithered undersampled images. Previous versions of ALE supported this
technique; the current version supports an approximation.
<p>Steve Mann's work (e.g. <a href="http://wearcam.org/orbits/">here</a> and <a
href="http://wearcam.org/comparam.htm">here</a>), on spatial extents,
projective transformations, linear-colorspace image processing, and weighting
by certainty functions, motivated ALE's adoption of these features. A
modified, "one-sided" approach to certainty is used by ALE's Irani-Peleg
renderer, to better accommodate extremely bright features that exceed the range
of all input images. This approach is modified further in 0.8.0 to rely on
estimated (instead of measured) intensities, which may allow further reduction
of noise in some cases.
<p>ALE incorporates an iterative solver based on Michal Irani and Shmuel
Peleg's <a
href="http://www.wisdom.weizmann.ac.il/~irani/abstracts/superResolution.html">iterative
deblurring and super-resolution</a> technique. It has been extended to handle
convolutions occurring in tandem in different colorspaces, and has been
modified for certainty weighting.
<p>ALE's treatment of barrel distortion, using a polynomial in distance from
the image center, is based on that of Helmut Dersch's Panorama Tools. ALE's
approach adjusts the linear (first-order) coefficient so that the corners of
the transformed frame remain in place.</p>
<h2>Program Inputs</h2>
<p>Define an <i>image</i> to be a function mapping a subset of 2D Euclidean space to
an RGB colorspace; define a <i>discrete image</i> to be an image defined only
at coordinates having integral components; define a <i>spatial discretization</i>
to be an operator that restricts the domain of an image to a set of points
having integral components, thus producing a discrete image; define a <i>spatial
extension</i> to be an operator that extends the domain of a discrete image by
assigning the value of the nearest neighbor point.
<p>Ignoring noise and color quantization, ALE assumes that each input frame
<b>d<sub>x</sub></b> is a discrete image that can be obtained by applying a
sequence of operators, including transformations, exposure adjustment,
convolutions, gamma correction, spatial discretization, and spatial extension,
to some image <b>d</b>, as follows:
<blockquote><b>
d<sub>x</sub> = DNCGDLE<sub>x</sub>B<sub>x</sub>P<sub>x</sub>d
</b></blockquote>
Where:
<ul>
<li><b>P<sub>x</sub></b> is a projective transformation
<li><b>B<sub>x</sub></b> is a barrel/pincushion distortion transformation
<li><b>E<sub>x</sub></b> is linear exposure adjustment
<li><b>L</b> is a convolution in linear colorspace
<li><b>D</b> is a spatial discretization
<li><b>G</b> is gamma correction
<li><b>C</b> is a spatial extension
<li><b>N</b> is a convolution in non-linear colorspace
</ul>
(When ALE aligns using Euclidean transformations, <b>P<sub>x</sub></b> are
assumed to be Euclidean.)
<p>The presence of an extension operator between <b>G</b> and <b>N</b> is
suspect, and is somewhat inelegant in the case of digitally processed data, but
although such extension may require careful selection of <b>N</b>, it does not
restrict the set of possible models. It is only included because it creates a
parallelism between <b>N</b> and <b>L</b> that makes implementation easier.
In a more sophisticated implementation, it could be removed.</p>
<h2>Incremental Rendering</h2>
<p>If <b>L</b> and <b>N</b> are assumed to behave as identity operators, then each
pixel in each input frame corresponds to a single point in <b>d</b>. In this
case, it may be possible to apply filtering operations to input frame pixels
directly. One caveat, however, is that different parts of the output may be
sampled with unequal density in the input frame sequence; hence, a filtering
approach that is uniform over all regions could cause significant aliasing or
detail loss. Instead, ALE uses a non-uniform approach. If <b>I<sub>n</sub>(i,
j)</b> is an output pixel, at position <b>(i, j)</b>, updated for input frames
zero through <b>n</b>, then:
<blockquote>
<b>I<sub>n</sub>(i, j) = </b>&sum;<sub>n'&isin;0..n</sub>&sum;<sub>(i',j')&isin;Dom[d<sub>n'</sub>]</sub> <b>E<sub>n'</sub><sup>-1</sup>G<sup>-1</sup>d<sub>n'</sub>(i',j') * c(n, n', i, j, i', j', E<sub>0</sub>, ..., E<sub>n</sub>, G, P<sub>0</sub>, ..., P<sub>n</sub>, B<sub>0</sub>, ..., B<sub>n</sub>, d<sub>0</sub>, ..., d<sub>n</sub>)</b>
</blockquote>
<p>Where <b>c</b> is a <a href="chain/">rendering chain</a>. Note that for most
types of rendering chains, the above expression can be simplified considerably.
<h2>Irani-Peleg Rendering</h2>
ALE's Irani-Peleg renderer iteratively updates the final output of incremental
rendering, with update operator U:
<blockquote>
<b>J<sub>0</sub> = I<sub>final</sub></b>
<br>
<b>J<sub>1</sub> = UJ<sub>0</sub></b>
<br>
.
<br>
.
<br>
.
<br>
<b>J<sub>k</sub> = UJ<sub>k-1</sub></b>
</blockquote>
Where <b>U</b> is the <a href="ip_update_rule/">Irani-Peleg update rule</a>.
<h2>Spatial Extension and Space Complexity</h2>
<p>By default, the output image is of fixed size, limited to the extents of
<b>d<sub>0</sub></b>, the first image in the input sequence; the 'extend' option
specifies that output should accommodate all regions of all input images.
<p>When rendering an output image of fixed size, image storage space in memory
for all non-median rendering types is <i>O(1)</i> in the number of input frames
and <i>O(n)</i> in the number of pixels per input frame, since at most one
input image is loaded into memory at any time. For median-value rendering,
storage is O(n) in the number of input frames. When using projectively-aligned
input images, however, renderings that accommodate all regions of all input
images can generate arbitrarily large output for a bounded input size, and can
use an arbitrarily large amount of memory.
<h2>Alignment Algorithm</h2>
<p>Details on the alignment algorithm used in ALE are <a href="alignment/">here</a>.</p>
<h2>3D Scene Reconstruction</h2>
<p>The scene reconstruction code is still very experimental and is not
currently covered by this document. For more information, see the user manual
and source code.
<br>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p class="footer">Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,309 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE Irani-Peleg Update Rule</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Irani-Peleg Update Rule</h1>
The Irani-Peleg update operator <b>U</b> is used iteratively to update the
final output of incremental rendering:
<blockquote>
<b>J<sub>0</sub> = I<sub>final</sub></b>
<br>
<b>J<sub>1</sub> = UJ<sub>0</sub></b>
<br>
<b>J<sub>2</sub> = UJ<sub>1</sub></b>
<br>
.
<br>
.
<br>
.
<br>
<b>J<sub>k</sub> = UJ<sub>k-1</sub></b>
</blockquote>
<h2>Modeling of the imaging process</h2>
<p>Given transformations <b>P<sub>x</sub></b> and <b>B<sub>x</sub></b>, linear
exposure adjustment <b>E<sub>x</sub></b>, linear and non-linear convolutions
<b>L</b> and <b>N</b>, discretization operator <b>D</b>, and extension operator
<b>C</b>, the imaging process can be modeled, starting with <b>s</b>, a
discrete approximation of the scene, as:
<blockquote>
<b>d<sub>x</sub> = DNCGDLE<sub>x</sub>B<sub>x</sub>P<sub>x</sub>Cs</b>
</blockquote>
<p>Note the extension operator to the left of <b>s</b>, which was not present
in the similar equation appearing on the main page. Since we are using only a
discrete approximation of the scene, it must first be made continuous, in order
to fit within the framework developed on the main page. As noted before, the
second extension operator, between <b>G</b> and <b>N</b>, is included for
convenience of implementation, and does not restrict the generality of the model.
<h2>Pixel-to-pixel weighting</h2>
<p>Since pixel values in <b>DLE<sub>x</sub>B<sub>x</sub>P<sub>x</sub>Cs</b> are
linear in pixel values of <b>Cs</b>, and hence linear in pixel values of
<b>s</b>, and since, similarly, pixel values of <b>d<sub>x</sub></b> are linear
in pixel values of <b>GDLE<sub>x</sub>B<sub>x</sub>P<sub>x</sub>Cs</b>, we can
define arrays of values <b>a</b> and <b>b</b> such that:
<blockquote>
<b>DLE<sub>x</sub>B<sub>x</sub>P<sub>x</sub>Cs(i, j) = &sum;<sub>(i', j')</sub> a<sub>x,i,j,i',j'</sub> * s(i', j')</b>
<br><br>
<b>d<sub>x</sub>(i, j) = &sum;<sub>(i', j')</sub> b<sub>x,i,j,i',j'</sub> * GDLE<sub>x</sub>B<sub>x</sub>P<sub>x</sub>Cs(i', j')</b>
</blockquote>
Hence, using <b>G</b> as a gamma correction function:
<blockquote>
<b>d<sub>x</sub>(i, j) = &sum;<sub>(i', j')</sub> b<sub>x,i,j,i',j'</sub> * G(&sum;<sub>(i'', j'')</sub> a<sub>x,i',j',i'',j''</sub> * s(i'', j''))</b>
</blockquote>
Note that, since <b>G</b> is non-linear, the inner sum cannot be moved outside of the enclosing parentheses.
<h2>Error calculation</h2>
<p>Given the model described above, we now have two ways to calculate a pixel value <b>d<sub>x</sub>(i, j)</b>: directly, from the input frame, or indirectly, from the scene approximation <b>s</b>. Hence, we can calculate an error between the two methods:
<blockquote>
<b>e<sub>x</sub>(i, j) = d<sub>x</sub>(i, j) - &sum;<sub>(i', j')</sub> b<sub>x,i,j,i',j'</sub> * G(&sum;<sub>(i'', j'')</sub> a<sub>x,i',j',i'',j''</sub> * s(i'', j''))</b>
</blockquote>
<h2>Backprojection (single stage)</h2>
Assume for the moment that our model of <b>d<sub>x</sub></b> were restricted in the following way, using a scene approximation <b>s'</b>:
<blockquote>
<b>d<sub>x</sub>(i, j) = &sum;<sub>(i', j')</sub> b<sub>x,i,j,i',j'</sub> * s'(i', j')</b>
</blockquote>
<p>This includes, as a special case, the scenario originally outlined by Irani and
Peleg, which considered a single convolution step. In this case, we can use a
backprojection array <b>c</b> to produce an updated image <b>Us'</b>:
<blockquote>
<b>Us'(i, j) = s'(i, j) + (1 / x<sub>max</sub>) * &sum;<sub>x</sub> &sum;<sub>(i', j')</sub> c<sub>x,i,j,i',j'</sub> * e<sub>x</sub>(i', j')</b>
</blockquote>
<p>For certain limited cases, Irani and Peleg have proved this update rule to
converge exponentially to the original scene. However, since the model used by
ALE includes two convolution steps that cannot, in general, be combined, ALE
uses a different update rule.
<h2>Backprojection (two-stage)</h2>
<p>The two-stage backprojection rule below could easily be extended to any
arbitrary number of stages, but ALE currently supports only two stages, in
accordance with the two-colorspace imaging model outlined above. The rule,
using <b>G<sup>-1</sup></b> as an inverse gamma correction function, is:</p>
<blockquote>
<b>Us(i, j) = s(i, j) + (1 / x<sub>max</sub>) &sum;<sub>x</sub> &sum;<sub>(i', j')</sub> c<sub>x,i,j,i',j'</sub> * (G<sup>-1</sup>(GDLE<sub>x</sub>B<sub>x</sub>P<sub>x</sub>Cs(i', j') + &sum;<sub>(i'', j'')</sub> f<sub>x,i',j',i'',j''</sub> * e<sub>x</sub>(i'',j'')) - DLE<sub>x</sub>B<sub>x</sub>P<sub>x</sub>Cs(i', j'))</b>
</blockquote>
<p>Where <b>f</b> is a second backprojection array. Schematically, the update
process looks something like the diagram below, based on an excerpt from the
ALE source code. The exposure re-estimation step shown in the diagram has not
been described here, but is available for inspection in the source. Also,
since ALE stores images internally using a linear representation, they must
first be converted back to a non-linear representation, as shown at the very
bottom of the diagram.</p>
<table border><tr><td>
<pre>
* The algorithm in the paper by Irani and Peleg looks something like this
* (PSF' is the backprojection kernel, and corresponds to what the authors of
* the paper call AUX):
*
* ===============================================================
* Forward Backward Binary Operators
* ---------------------------------------------------------------
*
* scene(n) ------> scene(n+1) <--- summation
*
* | ^
* | |
* PSF PSF'
* | |
* | ---------+ <--- difference
* V / |
*
* simulated(n) real
*
* ===============================================================
*
* The above approach assumes a single colorspace representation. However,
* consumer cameras sometimes perform sharpening in non-linear colorspace,
* whereas lens and sensor blurring occurs in linear colorspace. Hence, there
* can be two colorspaces involved; ALE accounts for this with linear and
* non-linear colorspace PSFs. Hence, the algorithm we use looks something
* like:
*
* ===============================================================
* Forward Backward Binary Operators
* ---------------------------------------------------------------
*
* scene(n) -----> scene(n+1) <--- summation
*
* | ^
* | |
* LPSF LPSF'
* | |
* | ----------+ <--- difference,
* V / | exposure
* re-estimation
* lsimulated(n) lreal(n)
*
* | ^
* | |
* unlinearize linearize
* | |
* V |
*
* lsim_nl(n) -----> lreal_nl(n) <--- summation
*
* | ^
* | |
* NLPSF NLPSF'
* | |
* | ----------+ <--- difference
* V / |
*
* nlsimulated(n) real_nl
*
* ^
* |
* unlinearize
* |
* |
*
* real
*
* ===============================================================
</pre>
</td></tr></table>
<h2>Backprojection Arrays</h2>
<p>The rules used for calculating backprojection arrays <b>c</b> and <b>f</b> are as follows:</p>
<blockquote>
<b>c<sub>x,i,j,i',j'</sub> = Y * b<sub>x,i,j,i',j'</sub></b>
<br><br>
<b>f<sub>x,i,j,i',j'</sub> = Z * a<sub>x,i,j,i',j'</sub></b>
</blockquote>
<p>Such that:
<!-- Ka and Kb had been swapped. Fixed August 8, 2004 --dhilvert -->
<blockquote>
<b>Y = - 0.9 / (max<sub>&omega;</sub> |FK<sub>b</sub>(&omega;)|)</b>
<br><br>
<b>Z = - 0.9 / (max<sub>&omega;</sub> |FK<sub>a</sub>(&omega;)|)</b>
</blockquote>
<p>where <b>F</b> is the fourier transform, <b>K<sub>a</sub></b> is the convolution kernel for <b>a</b>
in its native coordinate system, and <b>K<sub>b</sub></b> is the convolution kernel for <b>b</b> in its native coordinate
system.
<h2>Convergence for special cases</h2>
<p>In cases where at least one of <b>L</b>, <b>N</b>, or <b>G</b> is the
identity operator, or if <b>G</b> is linear, the technique outlined above can
be expressed in terms of the original method by Irani and Peleg, and will
converge exponentially if it meets the convergence criteria outlined in their
paper. Note that ALE makes certain approximations to obtain projection and
backprojection arrays that may hinder convergence in some cases. In particular,
the calculation of overlap areas involving non-identity transformations is not
exact.</p>
<h2>Certainty</h2>
<p>ALE's implementation of certainty for Irani-Peleg rendering modifies the rule
described above. Write the original rule as:</p>
<blockquote>
<b>Us(i, j) = s(i, j) + (1 / x<sub>max</sub>) &sum;<sub>x</sub> correction<sub>x</sub>(i, j)</b>
</blockquote>
<p>where <b>correction<sub>x</sub></b> represents the back-projected correction
for frame <b>x</b>. Let the re-estimated linear value <b>comp_real</b>,
<code>lreal(n)</code> in the diagram above, be defined as:
<blockquote>
<b>comp_real<sub>x</sub>(i, j) = G<sup>-1</sup>(GDLE<sub>x</sub>B<sub>x</sub>P<sub>x</sub>Cs(i, j) + &sum;<sub>(i'', j'')</sub> f<sub>x,i,j,i'',j''</sub> * e<sub>x</sub>(i'',j''))</b>
</blockquote>
Then the certainty-based rule for versions 0.7.x is:
<blockquote>
<b>Us(i, j) = s(i, j) + &sum;<sub>x</sub> &Kappa;(correction<sub>x</sub>, E<sub>x</sub>comp_real<sub>x</sub>, i, j) * correction<sub>x</sub>(i, j) / &sum;<sub>x</sub> K(correction<sub>x</sub>, E<sub>x</sub>comp_real<sub>x</sub>, i, j)</b>
</blockquote>
<p>Where <b>&Kappa;</b> is the symmetrically one-sided <a href="../certainty/">certainty</a> function.
<p>For version 0.8.0, the rule is:</p>
<blockquote>
<b>Us(i, j) = s(i, j) + &sum;<sub>x</sub> &Kappa;'(correction<sub>x</sub>, s, i, j) * correction<sub>x</sub>(i, j) / &sum;<sub>x</sub> &Kappa;'(correction<sub>x</sub>, s, i, j)</b>
</blockquote>
<p>Where <b>&Kappa;'</b> is the asymmetrically one-sided <a href="../certainty/">certainty</a> function. Note that this expression substitutes <b>s</b> for <b>E<sub>x</sub>comp_real<sub>x</sub></b>, resulting in estimate-based certainty.
<br>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,96 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: 3D Modeling</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE 3D Modeling [Very Experimental]</h1>
<p>When considering images captured by a camera, the projective class of 2D
transformations can compensate for arbitrary changes in position and
orientation when the scene consists of a diffuse flat surface, and arbitrary
changes in orientation (but not position) otherwise. In order to support
changes of position and orientation in the general case, it is necessary to
construct a 3D model of the scene. ALE currently has no reliable method for
doing this, but the scene reconstruction code included in versions 0.7.2 and
later may be a useful starting point for developing such a method.
<h2>View Angle</h2>
<p>In versions 0.7.3 and above, the diagonal view angle of the camera can be
specified on the command line. If no value is specified, the default value is
either device specific (if a device with a known view angle is specified), 43.7
degrees [ALE 0.7.3 and above], or 90 degrees [ALE 0.7.2].
<pre>
--view-angle &lt;x> Set the diagonal view angle to &lt;x> degrees. [ALE 0.7.3 and above]
</pre>
<h2>View Output [Very Experimental]</h2>
The view output option provides a reconstruction of the scene as viewed from a
particular frame's vantage point.
<pre>
--3dv &lt;n> &lt;o> Render file &lt;o> from a 3D model using the &lt;n>th frame view. [Very Experimental]
</pre>
<h2>Depth Output [Very Experimental]</h2>
The depth output option provides reconstructed depth information associated
with a view.
<pre>
--3dd &lt;n> &lt;o> Render 3D depth information &lt;o> for the view from frame &lt;n>. [Very Experimental]
</pre>
<br>
<hr>
<i>Copyright 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,182 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Transformation Data Files</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Transformation Data Files</h1>
Transformation data files are useful when performing alignment in several
passes or refining rendering options, and are necessary for specifying
barrel/pincushion distortion parameters. They also offer a way to manually
specify alignment when ALE cannot automatically align images.
<h2>Multiple-pass alignment</h2>
To align images in multiple passes, load the saved results of each previous
pass, as follows:
<pre>
$ ale --trans-save=a.t &lt;first pass arguments&gt;
$ ale --trans-load=a.t --trans-save=b.t &lt;second pass arguments&gt;
$ ale --trans-load=b.t --trans-save=c.t &lt;third pass arguments&gt;
.
.
.
</pre>
<h2>Rendering option refinement</h2>
To refine rendering options using the same alignment, first save the alignment
for the first option set, and then load the saved alignment information with
each subsequent option set, setting the perturbation upper bound to zero to
prevent a new alignment pass from occurring:
<pre>
$ ale --trans-save=a.t &lt;first option set&gt;
$ ale --trans-load=a.t --perturb-upper=0 &lt;second option set&gt;
$ ale --trans-load=a.t --perturb-upper=0 &lt;third option set&gt;
.
.
.
</pre>
<h2>Alignment file syntax (version 2)</h2>
There are two varieties of alignment file syntax that are both read and written
by ALE 0.7.0. The most basic of these is version 2. Version 3 is slightly
more complex, and is covered in the next section.
At the highest level, version 2 transformation data files contain the following
components: (a) a version command, and (b) a sequence of transformation
commands, one for each supplemental frame. Each line of text should contain at
most one command, between which optional comments may be interspersed. A
transformation command can be Euclidean, projective, or default. Euclidean and
projective commands take several arguments, including the width and height of
the supplemental frame. Default commands take no arguments. Commands are
outlined in more detail below.
<h3>Version command</h3>
<p>The version 2 version command is as follows:</p>
<pre>
V 2
</pre>
<h3>Euclidean commands</h3>
<p>The structure of a Euclidean command is as follows:</p>
<pre>
E &lt;image width&gt; &lt;image height&gt; &lt;x-offset&gt; &lt;y-offset&gt; &lt;rotation-angle&gt;
</pre>
<h3>Projective commands</h3>
<p>Projective commands map the four corners of the supplemental frame to four
points in the rendering coordinate system:</p>
<pre>
P &lt;image width&gt; &lt;image height&gt; &lt;top-left-x&gt; &lt;top-left-y&gt; &lt;blx&gt; &lt;bly&gt; &lt;brx&gt; &lt;bry&gt; &lt;trx&gt; &lt;try&gt;
</pre>
<h3>Default commands</h3>
Default commands can be explicitly written as follows:
<pre>
D
</pre>
Alternatively, if there are more frames than alignment commands (euclidean,
projective, or default), then the last supplemental frames in the frame
sequence will be assigned the default command.
<h3>Comments</h3>
Comments can be inserted with the following syntax:
<pre>
# This comment extends to the end of this line. I can write anything I want here.
</pre>
<h2>Alignment file syntax (version 3)</h2>
Version 3 syntax is required for specifying transformations for the original
frame, and for specifying barrel/pincushion distortion parameters.
<p>In version 3, the first transformation command is associated with the
original frame, instead of being associated with the first supplemental frame.
Also, barrel/pincushion distortion commands can precede each projective,
Euclidean, or default command.
<h3>Version command</h3>
<p>The version 3 version command is as follows:</p>
<pre>
V 3
</pre>
<h3>Barrel/pincushion distortion command</h3>
In version 3, barrel/pincushion distortion commands are supported. Distortion
is modeled as a transformation affecting the distance of image features from the
image center. The distorted distance is expressed as a polynomial function of
the undistorted distance. Zeroth and first order coefficients are fixed or
automatically determined; additional coefficients can be specified explicitly,
using the following syntax:
<pre>
B &lt;n&gt; &lt;coefficient 2&gt; &lt;coefficient 3&gt; ... &lt;coefficient n+1&gt;
</pre>
<p>Barrel/pincushion distortion commands should precede the projective, Euclidean,
or default transformation command for the corresponding frame.</p>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,319 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Alignment</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Alignment</h1>
<p>Alignment compares each supplemental frame in the sequence with an intermediate
incremental rendering known as the alignment reference image. Based on this
comparison, a transformation is assigned to the supplemental frame. Many
different transformations can be assigned before alignment of the frame is
complete.
<p>This manual page offers an overview of alignment options; linked from this
page is a sub-page offering more detail on <a href="file/">transformation
data files</a>.
<h2>Transformations</h2>
<p>The variables used to adjust alignment are called transformations; they map
points from the source image coordinate system to a target coordinate system
(the rendering coordinate system).
<p>ALE supports three transformation classes -- translational, euclidean, and
projective -- as well as barrel/pincushion distortion correction. The
translational class applies only translations to the inputs, changing only the
positions of images; the Euclidean class applies translations and rotations;
and the projective class applies general projective transformations.
Additionally, barrel/pincushion distortion correction can be applied to each
frame. The Euclidean class is most appropriate for use with scanners, or as a
first pass for projective transformations. The projective class and
barrel/pincushion distortion correction are most appropriate for use with
cameras. Except when capturing flat scenes, ALE does not correct perspective
changes, so movement of cameras should ideally be constrained so that no large
translations occur.
<h3>Transformation Class Options</h3>
<pre>
--translation Only adjust the position of images
--euclidean Adjust the position and orientation of images [default]
--projective Use projective transformations. Best quality, but slow.
</pre>
For more information on barrel distortion correction, see the sub-page on
<a href="file/">transformation data files</a>.
<h3>Transformation data file options</h3>
<p>Transformations used in alignment can be loaded from, or saved to, a <a
href="file/">transformation data file</a>. This can be useful when performing
alignment in several passes, or when refining rendering options. A
transformation data file is required for barrel/pincushion distortion
correction.
<pre>
--trans-load=x Load initial transformation settings from file x
--trans-save=x Save final transformation data in file x
</pre>
<h3>Alignment following</h3>
<p>The --follow option hints that frames tend to be more closely aligned with
adjacent frames in the sequence than with the original frame. This hint can be
useful even when initial alignment information is loaded from a file.
<pre>
--identity Frames align closely with the original frame. [default]
--follow Frames align closely with their immediate predecessor.
</pre>
<h2>Match statistics</h2>
<p>The match statistic indicates how well a transformed frame aligns with the
alignment reference image; it is used to select or reject transformations
during alignment. After alignment of a particular frame is complete, ALE
displays the corresponding final match statistic. If the value is close to
100%, then the frames are well aligned; very low values can indicate
misalignment; but even frames that are very well aligned typically do not
achieve 100% alignment. For improving image quality, ALE works most
effectively when match values are lower than 100%.
<h3>Match threshold</h3>
<p>A match threshold can be specified; no images with final match statistics
falling below this threshold will contribute to the final output.
<pre>
--threshold=x Min. match threshold; a perfect match is 100. (0 is default)
</pre>
<h3>Alignment failure</h3>
<p>When an image fails to meet the match threshold, a transformation is still
assigned to the frame (e.g., for writing to a <a href="file/">transformation
data file</a>). The assigned transformation can be either the optimal
alignment found (this is default) or the default transformation.
<pre>
--fail-optimal Frames beneath threshold are aligned optimally. [default]
--fail-default Frames beneath threshold keep their default alignment.
</pre>
<h3>Alignment error metric exponent</h3>
<p>The function calculated at each pixel to determine the match statistic is called
the alignment error metric, and is of the form <i>(a-b)<sup>x</sup></i>.
The value <i>x</i> is called the error metric exponent, and is 2 by default.
Larger numbers indicate that alignment will be more influenced by smaller
image features.
<pre>
--metric=x Set the alignment error metric exponent. (2 is default)
</pre>
<h3>Alignment Channel Options</h3>
<p>In calculating the per-pixel error metric, there are three ways in which ALE
can handle color channels. By default, ALE adds the channels before
calculating the match, but it can also be configured to rely solely on the
green color channel, or to use all three channels separately.
<pre>
--align-all Align images using all color channels
--align-green Align images using the green channel
--align-sum Align images using a sum of channels [default]
</pre>
<h3>Monte Carlo Alignment</h3>
<p>Aligning large images can take a very long time if all pixels are examined in
determining the match statistic, so it is often desirable to examine a smaller
subset of pixels. The Monte Carlo alignment option allows this. The number of
pixels used is specified as a percentage, and smaller numbers usually mean
faster, but less precise, alignment. For defaults, see the <a href="../defaults/">
default settings</a> page.
<pre>
--mc &lt;x&gt; Align using, on average, x% of available pixels (0 &lt; x &lt; 100)
--no-mc Align using all pixels.
</pre>
<h3>Alignment weight map</h3>
<p>Typically, measured differences at each pixel in the alignment reference
image contribute equally to the match statistic. To weight pixels differently,
a weight map can be used. The scale of the map should correspond with that of
the alignment reference image, and if the upper-left corner of the map does not
coincide with the upper-left corner of the first frame in the sequence, then a
non-zero offset should be specified to indicate the difference. See also <a
href="../exclusion/">exclusion regions</a>.
<pre>
--wm &lt;f&gt; &lt;x&gt; &lt;y&gt; Use weight map image &lt;f&gt; at offset (&lt;x&gt;, &lt;y&gt;)
</pre>
<h3>Frequency weighting</h3>
<p>If ALE is compiled with FFTW support, then a high-pass-filtered version of
the alignment reference image can be used to weight reference image pixels'
contributions to the match statistic. Frequency limiting can occur as a
fraction of the highest horizontal frequency, the highest vertical frequency,
or the highest average frequency. Limit values should range between 0 (pass
all) and 1 (pass none). If any limit is assigned a value of 1, no alignment
will occur, since all frequencies will have been excluded. An output file can
optionally be specified for high-pass filtered data.</p>
<pre>
--fl &lt;h&gt; &lt;v&gt; &lt;a&gt; High-pass filters: horizontal &lt;h&gt;, vertical &lt;v&gt;, average &lt;a&gt;.
--flshow &lt;o&gt; Write high-pass filtered data to file &lt;o&gt;.
</pre>
<h3>Algorithmic weighting</h3>
<p>This option writes the current alignment reference image and definition map
to specified files, executes a specified program with these arguments, and then
reads back alignment weights. This option requires POSIX libraries, and
requires that ALE have been built with POSIX support enabled.</p>
<pre>
--wmx &lt;e&gt; &lt;r&gt; &lt;d&gt; Write reference &lt;r&gt;, definition &lt;d&gt;, execute `&lt;e&gt; &lt;f&gt; &lt;d&gt;`,
read weights &lt;r&gt; back.
</pre>
<h2>Perturbation</h2>
<p>The perturbation size determines the magnitude by which alignment parameters
are changed. The size is initially set to be large, allowing large changes in
alignment to be evaluated, and is reduced as the locally optimal alignment is
found for each size. When this size drops below a specified lower bound, the
frame is considered to be aligned.
<h3>Perturbation bounds</h3>
<p>These options determine the upper and lower bounds for perturbation size. The
perturb-upper and perturb-lower bounds apply to rotation (in degrees),
translation (in pixels), and the movement of the boundaries of a projected
frame (in pixels). By appending the '%' character, values may optionally be
specified as a percentage of the number of pixels in the smallest image
dimension (0.7.1-patch1 and later). The rot-upper bound disables rotational
perturbation above a certain perturbation size (in degrees). To disable
alignment, set perturb-upper to zero.
<pre>
--perturb-upper=x Perturbation upper bound in pixels/degrees (14% is default) [0.7.1, and earlier, default to 32.0]
('x%' uses a fraction of the smallest image dimension.) [0.7.1-patch1 and later]
--perturb-lower=x Perturbation lower bound in pixels/degrees (.125 is default)
('x%' uses a fraction of the smallest image dimension.) [0.7.1-patch1 and later]
--rot-upper=x Rotation-specific perturbation upper bound (32.0 is default)
</pre>
<h3>Barrel/pincushion distortion adjustment multiplier and rate</h3>
<p>When using barrel/pincushion distortion parameters, any frame-to-frame
adjustments to these parameters are made in a manner dependent on the
perturbation size. A multiplier, the barrel distortion adjustment multiplier,
is used to determine the perturbation of these parameters, based on the generic
perturbation size. Additionally, the frame-to-frame rate of change of each
barrel distortion parameter can be limited to a specified maximum. To disable
frame-to-frame adjustment of barrel/pincushion distortion parameters, set
bda-mult to zero. Setting bda-rate to zero disables rate limitation.
<pre>
--bda-mult=x Barrel distortion adjustment multiplier (0.0001 is default)
--bda-rate=x Barrel distortion rate of change maximum (0.0004 is default)
</pre>
<h3>Level of detail</h3>
<p>Alignment at large perturbation sizes is usually carried out on
reduced-detail images. To disable this, set lod-max to
log<sub>2</sub>(perturb-upper).
<pre>
--lod-max=x LOD scale factor is max(1, (2^floor(x))/perturb) (1 is def.)
</pre>
<h3>Perturbation Types (experimental; 0.7.1-patch1 and later)</h3>
<p>Perturbations are normally performed in output image coordinates. To perform
perturbations in source image coordinates, specify <code>--perturb-source</code>.
<pre>
--perturb-output Apply perturbations in output image coordinates. [default] [0.7.1-patch1 and later]
--perturb-source Apply perturbations in source image coordinates. [0.7.1-patch1 and later]
</pre>
<h3>Global Searching (experimental; 0.7.0-patch1 and later)</h3>
<p>In cases where important image features do not have sufficient overlap using
default alignment parameters (determined by <code>--identity</code> and
<code>--follow</code>), a number of translations can be applied to the default
parameters in order to find a new alignment starting point. Since this process
searches the entire region of the alignment reference image, it is called a
global (as opposed to local) search. To avoid misalignment, a minimum overlap
area can be specified [0.7.1-patch2 and later].
<pre>
--gs &lt;type> Set global search to &lt;type>, one of: [0.7.0-patch1 and later]
local Local alignment only [default]
inner Alignment reference image inner region
outer Alignment reference image outer region
all Union of inner and outer
central inner if below threshold or better; else, outer.
--gs-mo &lt;x> Set &lt;x> pixel min. overlap for global search. (16 is default) [0.7.1-patch2 and later]
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,152 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Default Settings</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Default Settings</h1>
<p>ALE offers five different default settings, each of which emphasizes
image quality, speed, or some other rendering characteristic, as follows:</p>
<pre>
--q0 Low quality, high speed. [default]
--qn Low noise, moderate speed.
--q1 Moderate quality and speed.
--q2 High quality, low speed.
--qr Range-extended high quality.
</pre>
<p>These settings specify defaults for other options: <code>--dchain</code>, <code>--achain</code>,
<code>--mc</code>, <code>--ips</code>, <code>--exp-extend</code>, and <code>--cx</code>. For
more information about these options, see the <a href="../alignment/">alignment</a> and <a href="../rendering/">rendering</a>
manual pages. Details regarding these defaults are provided in the following sections.
<h2>High speed (--q0)</h2>
<code>--q0</code> emphasizes speed over image quality. This option is default, and
sets other options' defaults as follows:
<pre>
--dchain fine:box:1,triangle:2
--achain triangle:2
--mc 30
--ips 0
--exp-noextend
--no-cx
</pre>
<h2>Low noise (--qn)</h2>
<code>--qn</code> emphasizes low noise over resolution and rendering speed, and
sets the following defaults:
<pre>
--dchain sinc*lanc:6
--achain sinc*lanc:6
--mc 50
--ips 0
--exp-noextend
--no-cx
</pre>
<h2>Balanced quality and speed (--q1)</h2>
<code>--q1</code> balances image quality and rendering speed, offering higher
resolution than <code>--qn</code>. It sets the following defaults:
<pre>
--dchain fine:sinc*lanc:6,sinc*lanc:6
--achain sinc*lanc:6
--mc 50
--ips 0
--exp-noextend
--no-cx
</pre>
<h2>High quality (--q2)</h2>
<p><code>--q2</code> favors image quality over rendering speed, offering greater
emphasis for high-frequency details than <code>--q0</code>, <code>--qn</code>,
or <code>--q1</code>. It depends on the <code>--lpsf</code> and
<code>--nlpsf</code> options, which can be set indirectly via the
<code>--device</code> option. (More information about these options can be
found on the <a href="../rendering/psf">PSF</a> and <a href="../device/">device</a> pages.) <code>--q2</code>
sets the following defaults:
<pre>
--dchain sinc*lanc:8
--achain sinc*lanc:8
--no-mc
--ips 4
--exp-noextend
--no-cx
</pre>
<h2>Range extension (--qr)</h2>
<p><code>--qr</code> is similar to <code>--q2</code>, but offers improved
rendering when input images have been taken with unequal exposures. In other
cases, it might exacerbate noise in light and dark regions, and so should not
be used. This option sets the following defaults:
<pre>
--dchain sinc*lanc:8
--achain sinc*lanc:8
--no-mc
--ips 6
--exp-extend
--cx 0.7
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,101 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Devices</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Devices</h1>
<p>Device specification is optional. Specifying a device allows automatic
determination of <a href="../rendering/psf/">point-spread functions</a>,
refinement of the correspondence between incident light and pixel values (e.g.
power law), and refinement of certainty calculation.
<pre>
--device &lt;d&gt; Set the capture device to &lt;d&gt;.
</pre>
<p>Available devices are as follows:</p>
<table border>
<tr><td>canon_300d_raw_linear<td>Canon 300D (Digital Rebel) raw, linear data. [0.7.2 and later]
<tr><td>canon_300d_raw_linear+50mm_1.4<td>Canon 300D with EF 50mm f/1.4 lens, unspecified aperture.
<tr><td>canon_300d_raw_linear+50mm_1.4@1.4<td>Canon 300D with EF 50mm f/1.4 lens, aperture 1.4.
<tr><td>canon_300d_raw_linear+50mm_1.8<td>Canon 300D with EF 50mm f/1.8 lens, unspecified aperture.
<tr><td>canon_300d_raw_linear+85mm_1.8<td>Canon 300D with EF 85mm f/1.8 lens, unspecified aperture.
<tr><td>ov7620_raw_linear<td>OmniView OV7620 in raw RGB, linear mode. [0.7.0-patch1 and later]
<tr><td>xvp610_640x480<td>IBM PC Camera Pro (XVP610) in 640x480 mode.
<tr><td>xvp610_320x240<td>IBM PC Camera Pro (XVP610) in 320x240 mode.
</table>
<p>These device options are described in more detail below.
<h2>Canon 300D (Digital Rebel) [0.7.2 and later]</h2>
<p>Direct support for CRW files depends on the ImageMagick configuration, and
may not be available on all platforms. Dave Coffin's <a
href="http://www.cybercom.net/~dcoffin/dcraw/">dcraw</a> program, invoked with
arguments -d -4, will produce a raw, linear PPM file suitable for use with this
device configuration. JPEG files produced by the 300D cannot be directly used
as inputs for this configuration, since they are gamma-corrected rather than
linear.</p>
<h2>OV7620 [0.7.0-patch1 and later]</h2>
<p>Standard OV7620 drivers may not include options for setting raw RGB or linear
modes. Linux users may apply a <a href="/ov7620/">driver patch</a> to access
these modes. Setting the module option <code>rgb_raw=2</code> places the camera
into the desired mode.</p>
<h2>XVP610</h2>
<p>Users of XVP610 cameras and Linux may wish to apply a <a href="/xvp610/">driver patch</a>. This version of ALE expects that this patch has been applied.
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,75 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Exclusion Regions</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Exclusion Regions</h1>
<p>ALE offers exclusion regions as a way to disallow certain areas from being
used in alignment and (optionally) rendering. Spatial coordinates are
expressed in the rendering coordinate system (prior to scaling). In cases
where the default transformation is used with the original frame, this is
identical to the unscaled original frame coordinate system, taking the
upper-left corner to be (0, 0). Frame numbering begins with 0, which represents
the original frame.
<p>All specified volumes are excluded from alignment (except where they affect
the alignment reference image), and are excluded from rendering by default.
(See the <a href="../rendering/chains/">rendering chains</a> page for
information on how to ignore exclusion regions.) Exclusion region syntax is
as follows:
<pre>
--ex &lt;args&gt; Exclude a specified volume.
&lt;args&gt; are space-delimited horizontal,
vertical, and frame limits:
&lt;xmin&gt; &lt;xmax&gt; &lt;ymin&gt; &lt;ymax&gt; &lt;fmin&gt; &lt;fmax&gt;
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,107 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: File Output</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE File Output</h1>
<p>File output options determine the format in which rendered images are written,
and how frequently they are written. Depending on the compilation options used,
available file output options vary.
<h2>Output Color Depth</h2>
<p>Output color depth of 8 or 16 bits of precision per color channel can be specified,
for 24-bit or 48-bit color, respectively.
<pre>
--8bpc Write 8 bit per channel output [default]
--16bpc Write 16 bit per channel output
</pre>
<h2>Extension-based file type determination</h2>
<p>If ALE has been built with ImageMagick support, then the output file type can
be determined automatically by file extension. This is the default behavior
for ImageMagick builds. The <code>--auto</code> flag explicitly specifies that
the default behavior should be used; it generates an error on builds compiled
without ImageMagick support.
<pre>
--auto Determine file type automatically
</pre>
<h2>PPM Output</h2>
<p>All builds of ALE support PPM output. PPM can be written in plain (ASCII) or
raw (binary) format. If ALE has been built without ImageMagick support, or if
the file type cannot be automatically determined by file extension, then raw
PPM output is used by default.
<pre>
--raw Write raw PPM output
--plain Write plain PPM output
</pre>
<h2>Incremental Output</h2>
<p>By default, ALE writes intermediate results periodically throughout the rendering
process. This behavior can be disabled, however, so that output is written only
after rendering is complete.
<pre>
--inc Produce incremental output. [default]
--no-inc Don't produce incremental output.
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,216 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE 0.7.x User Manual</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../../user/">Up</a> ]</b></p>
<h1>ALE 0.7.x User Manual</h1>
<h2>Purpose</h2>
<p>This page summarizes program operation and command-line usage for ALE
versions 0.7.0, 0.7.0-patch1, 0.7.1, 0.7.1-patch1, 0.7.1-patch2, and 0.7.2.
Features specific to a particular version are annotated (e.g. [ALE 0.7.1
only]).
<p>Manual pages linked from this section describe <a href="defaults/">default
settings</a>, <a href="file/">file output</a>, <a
href="alignment/">alignment</a>, <a href="rendering/">rendering</a>, <a
href="exclusion/">exclusion regions</a>, <a href="device/">devices</a>, and
<a href="3d/">3D scene reconstruction</a> (Very experimental; ALE 0.7.2 and
later).
<p>For more information on ALE, see the <a
href="http://auricle.dyndns.org/ALE/">ALE Home Page</a>.
<h2>Parameter Meta-syntax</h2>
<table>
<tr>
<td><code>&nbsp;&lt;foo></code></td>
<td>A required parameter called <i>foo</i>.</td>
</tr>
<tr>
<td><code>[&lt;foo>]</code></td>
<td>An optional parameter called <i>foo</i>.
</tr>
<tr>
<td><code>[&lt;foo>]*</code></td>
<td>Zero or more parameters <i>foo</i>.
</tr>
</table>
<h2>Command-line syntax for Image Processing</h2>
<p>The following command-line invocation can be used to process a series of
frames into an output file:
<pre>ale [&lt;option>]* &lt;original-frame> [&lt;supplemental-frame>]* &lt;output-file></pre>
<h3>Option Arguments</h3>
<p>Certain basic modes of operation, emphasizing image quality, speed, or other
rendering characteristics, are now established in the form of <a
href="defaults/">default settings</a>.
<p>Other options are outlined in the manual pages describing <a
href="file/">file output</a>, <a href="rendering/">rendering</a>, <a
href="alignment/">alignment</a>, <a href="exclusion/">exclusion
regions</a>, <a href="device/">devices</a>, and <a href="3d/">3D scene
reconstruction</a> (Very experimental; ALE 0.7.2 and later).
<h3>Image Files</h3>
<p>ALE can be configured at compile time to use one of two different file
handlers. Execute 'ale --version' to determine which file handler is being
used. The table below outlines the supported formats for each file handler.</p>
<table class="inline">
<td>
<table border>
<tr><th>Version Message</th><th>File Types Supported</th></tr>
<tr><td valign=top>
<pre>File handler: ImageMagick</pre>
</td>
<td>
Input and output files can be any of the <a
href="http://imagemagick.sourceforge.net/www/formats.html">formats</a> supported by
ImageMagick.
</td></tr>
<tr><td valign=top>
<pre>File handler: PPM</pre>
<td>
Input files must be PPM, and output files are written as PPM.
</td></tr>
</table>
</table>
<p>Note that many external programs, including ImageMagick's <a
href="http://www.imagemagick.org/">command line utilities</a>, can be used to
convert between PPM and other formats.</p>
<p>See the README included in the source distribution of ALE for more information about
compile-time configuration of file handlers.</p>
<h2>Command-line syntax for Version Information</h2>
<p>The following command-line invocation can be used to print version
information and build options:
<pre>ale --version</pre>
The following is sample output from this invocation:
<pre>
ALE Version: 0.7.2
File handler: ImageMagick
Color data: SINGLE
Coordinate data: SINGLE
DFT: Built-in
Assertions: Disabled
</pre>
<p>The first line of output indicates the version of ALE source code being
used; the remaining lines reflect the build options selected at compile
time.
<p>For more information about build options, see the README file included in
the ALE source distribution.
<h2>Command-line syntax for Help Output</h2>
<p>When invoked with no arguments, or an insufficient number of file arguments,
ALE outputs a help message specifying command-line usage and available help
topics. The following is a sample invocation:
<pre>ale</pre>
<h3>Help Topics</h3>
More information about specific help topics can be obtained with an invocation
of the following form:
<pre>ale &lt;help option&gt;</pre>
Available help options, and their corresponding help topics, are outlined
below:
<pre>
--hu Usage.
--hq Default settings.
--hf Image files.
--he Exclusion regions.
--ha Alignment (not exposure-related).
--hr Rendering (not exposure-related).
--hx Exposure.
--ht Transformation data files.
--hl Filtering (PSFs, rendering chains).
--hd Devices.
--hv Video stream processing (Experimental).
--h3 3D Modeling (Very Experimental). [ALE 0.7.2 and later]
--hz Undocumented options.
--hA Concatenate all help pages. [ALE 0.7.1 and later]
</pre>
<h2>Related Manual Pages</h2>
<ul>
<li><a href="defaults/">Default Settings</a>
<li><a href="file/">File Output</a>
<li><a href="rendering/">Rendering</a>
<li><a href="alignment/">Alignment</a>
<li><a href="exclusion/">Exclusion Regions</a>
<li><a href="device/">Devices</a>
<li><a href="3d/">3D Modeling</a> [ALE 0.7.2 and later]
</ul>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p class="footer">Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,172 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Rendering Chains</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Rendering Chains</h1>
<p>The ALE incremental renderer is configured using rendering chains. Rendering chains are
constructed hierarchically from: invariants, SSFEs (scaled sampling filters
with exclusion), SSFs (scaled sampling filters), and sampling filters. Each of
these components is described in a section below. Defaults are outlined in the
final section.
<h2>Chains</h2>
<p>The chain is the top level of the rendering chain hierarchy, and is composed of a
sequence of invariants. Syntactically, a chain is specified as a number of
invariants separated by commas:
<blockquote>
<code>invariant<sub>1</sub>,invariant<sub>2</sub>,invariant<sub>3</sub>,...,invariant<sub>n</sub></code>
</blockquote>
<p>Each rendered pixel is assigned a value at the first invariant whose weight
exceeds the weight threshold, or otherwise at the last invariant in the sequence.
<h3>Chain Options</h3>
<pre>
--wt &lt;w&gt; Set weight threshold for defined pixels (default is 0.8).
--dchain &lt;g&gt; Use chain &lt;g&gt; to render the default output.
--ochain &lt;g&gt; &lt;o&gt; Use chain &lt;g&gt; to render output file &lt;o&gt;.
--achain &lt;g&gt; Use chain &lt;g&gt; to render the alignment reference image.
</pre>
<h3>Chain Examples</h3>
<pre>
triangle:2 ALE 0.6.0 merging (roughly)
fine:box:1 Drizzling (roughly)
fine:sinc*lanc:8 High-frequency preservation
last:nex:sinc*lanc:8 Useful for video stabilization
fine:box:1,triangle:2 Multi-resolution rendering
fine:sinc*lanc:8,sinc*lanc:8 Multi-resolution rendering
</pre>
<h2>Invariants</h2>
<p>Invariants determine whether the rendered pixel value should be taken from a
single frame, or from an average of all frames. If from a single frame, it can
be the first, last, minimal, or maximal pixel value. By default, the average
is used. The syntax is as follows:
<blockquote>
<table>
<tr><th align=left>Syntax</th><th><pre> </pre></th><th align=left>Description</th></tr>
<tr><td>avg:&lt;SSFE&gt;<td><td>Average value
<tr><td>max:&lt;SSFE&gt;<td><td>Maximum value
<tr><td>min:&lt;SSFE&gt;<td><td>Minimum value
<tr><td>first:&lt;SSFE&gt;<td><td>First value
<tr><td>last:&lt;SSFE&gt;<td><td>Last value
<tr><td>&lt;SSFE&gt;<td><td>Same as avg:&lt;SSFE&gt;
</table>
</blockquote>
<h2>Scaled Sampling Filter with Exclusion (SSFE)</h2>
<p>SSFEs qualify SSFs, indicating whether exclusion regions should be honored.
<blockquote>
<table>
<tr><th align=left>Syntax</th><th><pre> </pre></th><th align=left>Description</th></tr>
<tr><td>ex:&lt;SSF&gt;<td><td>Honor exclusion regions
<tr><td>nex:&lt;SSF&gt;<td><td>Don't honor exclusion regions
<tr><td>&lt;SSF&gt;<td><td>Same as ex:&lt;SSF&gt;
</table>
</blockquote>
<h2>Scaled Sampling Filter (SSF)</h2>
<p>SSFs indicate whether filtering should occur at the resolution of the output
image, or at the minimum of input and output image resolutions. The former prevents loss
of details; the latter prevents aliasing.
<blockquote>
<table>
<tr><th align=left>Syntax</th><th><pre> </pre></th><th align=left>Description</th></tr>
<tr><td>fine:&lt;SF&gt;<td><td>Filter at full output image resolution
<tr><td>coarse:&lt;SF&gt;<td><td>Filter at minimum resolution
<tr><td>&lt;SF&gt;<td><td>Same as coarse:&lt;SF&gt;
</table>
</blockquote>
<h3>SSF Options</h3>
<pre>
--afilter &lt;s&gt; Use SSF &lt;s&gt; to interpolate points in alignment.
</pre>
<h2>Sampling Filter (SF)</h2>
<p>SFs are used to limit bandwidth. Primitive functions and pointwise multiplication of these
functions (windowing) are available.
<blockquote>
<table>
<tr><th align=left>Syntax</th><th><pre> </pre></th><th align=left>Description</th></tr>
<tr><td>sinc<td><td>Sinc filter: (sin &pi;x) / (&pi;x)</td>
<tr><td>lanc:&lt;x&gt;<td><td>Lanczos, diameter x.
<tr><td>triangle:&lt;x&gt;<td><td>Triangle, diameter x.
<tr><td>box:&lt;x&gt;<td><td>Box, diameter x.
<tr><td>zero<td><td>Zero function
<tr><td>&lt;f&gt;*&lt;f&gt;<td><td>Pointwise multiplication (windowing)
</table>
</blockquote>
<h2>Defaults</h2>
<p>ALE defaults are as follows:</p>
<pre>
dchain Varies by <a href="../../defaults/">default setting</a>
achain Varies by <a href="../../defaults/">default setting</a>
afilter internal (approximates triangle:2)
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,201 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Rendering</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Rendering</h1>
<p>Rendering determines how an output image is constructed from a series of
aligned input frames, and occurs in two stages: incremental rendering and
Irani-Peleg rendering. Additional rendering options include exposure
registration, certainty-weighted rendering, spatial extension, range extension,
scaling, and bayer pattern specification. Experimental options for video
stream processing are also available.
<h2>Incremental Rendering</h2>
<p>The incremental renderer uses configurable <a href="chains/">rendering
chains</a> to determine the output image. It can increase resolution and
reduce aliasing, but it cannot reduce blur.
<h2>Irani-Peleg Rendering</h2>
<p>The Irani-Peleg renderer uses configurable <a href="psf/">point-spread
functions</a> to model blur, which is then reduced by an iterative
backprojection technique. For iteration defaults, see the <a
href="../defaults/"> default settings</a> page.
<pre>
--ips &lt;i&gt; Run &lt;i&gt; iterations.
</pre>
<h2>Exposure Registration</h2>
<p>By default, ALE adjusts an exposure model to minimize differences in tone
between frames. The option <code>--exp-noregister</code> indicates that
exposure should be assumed uniform across all frames. In this case, no
adjustment is performed.</p>
<pre>
--exp-register Register exposure between frames. [default]
--exp-noregister Assume uniform exposure across all frames.
</pre>
<h2>Certainty-weighted Rendering</h2>
<p>The exposure model in ALE includes an associated certainty function, which
quantifies the reliability of sensor measurements. By default, this function
is raised to the zeroth power, to obtain uniform certainty for all measurements.
To specify a different certainty exponent, the option <code>--cx</code> can be
used. This option is best used in combination with <code>--exp-extend</code>
(see below) and <code>--ips</code>. For defaults, see the <a href="../defaults/">
default settings</a> page.
<pre>
--cx &lt;x> Render with certainty exponent &lt;x>
--no-cx Render with uniform certainty.
</pre>
<h2>Scale factor</h2>
<p>Rendering with a larger scale factor results in image output of the specified
larger scale. Larger scales can improve alignment precision and output image
quality, but can also increase alignment and rendering times.
<pre>
--scale=x Scale images by the factor x (where x is at least 1.0)
</pre>
<h2>Image extents</h2>
<p>The --extend option records pixel data that falls outside of the region of the
first frame in the sequence. This can be useful for providing additional
alignment constraints or creating panoramic image mosaics. (For mosaics, see
also the description of the --follow option in the <a
href="../alignment">alignment</a> section.)
<pre>
--extend Increase image extents to accommodate all pixel data.
--no-extend Don't increase extents; crop to original frame. [default]
</pre>
<h2>Exposure extents</h2>
<p>By default, ALE restricts the output range to that of the original frame.
To adjust the output range to accommodate the ranges of all input frames,
specify <code>--exp-extend</code>. For defaults, see the <a href="../defaults/">
default settings</a> page.
<pre>
--exp-extend Extend range to include all calculated values.
--exp-noextend Restrict to the original frame's range.
</pre>
<h2>Bayer pattern specification</h2>
<p>Many cameras sample only one color channel per output pixel. To ignore the
other channels, a bayer pattern can be specified. In versions prior to 0.7.3,
device-specific bayer patterns override the command-line specification. In
version 0.7.3 and later, the reverse holds.
<pre>
--bayer &lt;b&gt; Set default bayer pattern to &lt;b&gt;, one of:
(clockwise from top left pixel)
rgbg Red-green-blue-green
gbgr Green-blue-green-red
grgb Green-red-green-blue
bgrg Blue-green-red-green
none RGB-RGB-RGB-RGB
Default is none or device-specific.
</pre>
<h2>Video stream processing (Experimental)</h2>
<p>If a sequence of frames represents a video stream, then, in addition to
producing a single output image, ALE can also produce one or more sequences of
processed frames, corresponding to one or more occurrences of the
<code>--visp</code> option. This option has its own associated scaling option,
as well as an option to show excluded regions as dimmed wherever possible.</p>
<pre>
--visp &lt;args&gt; Process a video sequence.
&lt;args&gt; are:
&lt;chain&gt; &lt;stabilization-type&gt; &lt;prefix&gt; &lt;suffix&gt;
&lt;chain&gt; is an incremental rendering chain.
&lt;stabilization-type&gt; is one of:
ma:&lt;x&gt; Moving average over 2*&lt;x&gt; + 1 frames
sf:&lt;x&gt; Stabilize to single frame number &lt;x&gt;
identity Same as ma:0
&lt;prefix&gt; is an output file prefix
&lt;suffix&gt; is an output file suffix
--visp-scale=&lt;x&gt; Use scale &lt;x&gt; for VISP output. (default is 1.0)
--exshow For single-invariant chains, show --ex regions dimmed.
</pre>
<h3>Video stream processing example</h3>
<p>To mimic the behavior of repeated applications of the 0.6.0
<code>--replace</code> option over a sequence of frames, the following
<code>--visp</code> option could be used.
<pre>
--visp last:nex:triangle:2 sf:0 frame .jpg
</pre>
<p>For better filtering, the following option could be used instead:
<pre>
--visp last:nex:sinc*lanc:6 sf:0 frame .jpg
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,91 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Point Spread Functions</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Point Spread Functions</h1>
<p>The ALE Irani-Peleg renderer uses a point-spread function to model the optical
and electronic properties of the capture device used. The PSF can be specified
in terms of one linear and one non-linear component.
<h3>PSF specification</h3>
<p>The PSF can be explicitly specified by using one or both of the psf options.
<pre>
--lpsf &lt;p> Set linear colorspace point-spread function to &lt;p>
--nlpsf &lt;p> Set non-linear colorspace point-spread function to &lt;p>
</pre>
Available explicit point-spread functions are as follows:
<pre>
box=&lt;d> Set the PSF to a box filter with diameter &lt;d>.
circle=&lt;d> Set the PSF to a circular filter with diameter &lt;d>. [ALE 0.7.1 and later.]
stdin Specify a custom filter at runtime.
stdin_vg stdin with vertically-oriented gaps after every 8th pixel.
&lt;p>+&lt;p> Summation of two functions
&lt;p>^&lt;p> Convolution of two functions. [ALE 0.7.3 and later.]
&lt;n>*&lt;p> Multiplication by a scalar &lt;n>. [ALE 0.7.3 and later.]
</pre>
If a device is known to ALE, then its PSF can be implicitly set with the
<code>--device</code> option. (See the <a href="../../device/">device</a> page
for more information.) If a device is not specified, then the default linear
PSF component is <code>box=1</code>. The non-linear PSF component is disabled
by default.
<h3>Determining the PSF</h3>
<p>The PSF can be approximated based on images of known scenes. The ALE source
distribution includes an experimental script that numerically approximates the
PSF in this way (<code>d2/render/psf/ale-psf-calibrate</code>). Other, more
efficient methods for approximating the PSF are likely possible, however.
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,258 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: 3D Scene Reconstruction</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE 3D Scene Reconstruction</h1>
<p>In general, 3D modeling of scenes may allow handling of cases that per-frame
projective transformations do not allow, such as registering frames having
different viewpoints over a non-flat or specular scene, or recovery of depth
from frames having different viewpoints. ALE's implementation of 3D scene
reconstruction is considered experimental in versions prior to 0.8.3.
<h2>Models</h2>
<p>The method of modeling used in 0.8.2 and later is spatial subdivision based on
regions of interest, followed by iterative update of the estimated occupancy
and color of each region of interest. (For a general discussion of occupancy,
see Hans Moravec's work on depth recovery.) In 0.8.1, the method of modeling
is decomposition and deformation of a surface. In earlier versions, a
per-frame, per-pixel model of depth is used.
<h2>Recovered Color and Depth Output</h2>
<p>The color and depth output options provide a reconstruction of the scene as
viewed from a particular frame's vantage point, or from an arbitrary camera
view [0.8.2 and later]. In 0.8.2 and later, normalization of output values by
accumulated occupancy can optionally be disabled for unfiltered views. Version
0.8.3 adds support for options --et and --3dpx, which can be useful for 3D
cropping applications. --et specifies the minimum accumulated weight required
for a pixel to be defined, allowing refinements of crops based on clip planes
(<code>--rc</code> and <code>--fc</code>) established prior to scene
reconstruction, whereas --3dpx specifies a region of space to be removed
after scene reconstruction. 0.8.3 uses depth image pixels to determine such spatial regions,
leaving the pixels undefined, whereas 0.8.4 removes scene geometry prior to
rendering, allowing rendering of background objects after the foreground has been removed.
<pre>
--3dv &lt;n> &lt;o> Render, to file &lt;o>, colors as viewed from frame &lt;n>.
--3dd &lt;n> &lt;o> Render, to file &lt;o>, depths as viewed from frame &lt;n>.
--3dvp &lt;args> &lt;o> Render, to file &lt;o>, colors viewed with projective &lt;args>. [0.8.2 and later]
--3ddp &lt;args> &lt;o> Render, to file &lt;o>, depths viewed with projective &lt;args>. [0.8.2 and later]
&lt;args> are W H V x y z P Y R:
W image width.
H image height.
V camera view angle.
x translation x component.
y translation y component.
z translation z component.
P rotation around x-axis.
Y rotation around y-axis.
R rotation around z-axis.
--occ-norm Normalize output with accumulated occupancy. [default] [0.8.2 and later]
--occ-nonorm Don't normalize output with accumulated occupancy. [0.8.2 and later]
--et &lt;x> Set encounter threshold &lt;x> for defined pixels. [default is 0] [0.8.3 and later]
--3dpx &lt;args> Exclude a specified spatial volume following full-scene [0.8.3]
reconstruction, assuming a single depth at each point
in the output. &lt;args> are:
&lt;xmin> &lt;xmax> &lt;ymin> &lt;ymax> &lt;zmin> &lt;zmax>
--3dpx &lt;args> Exclude a specified spatial volume following full-scene [0.8.4 and later]
reconstruction. &lt;args> are:
&lt;xmin> &lt;xmax> &lt;ymin> &lt;ymax> &lt;zmin> &lt;zmax>
</pre>
<h2>Filtering [0.8.4 and later]</h2>
Version 0.8.4 adds support for filtering color values from the inputs to
produce final color renderings. This is now the default. Determining surface
depth and gradient for filtering the inputs draws from a set of depth pixels
within a disc whose radius can be specified with the --3d-dmr and --3d-fmr
options.
Filtering color from views distributed on a disc (about the camera origin) of
specified aperture allows simulation of focus effects; such effects can be
controlled with the --focus option.
<pre>
--3d-filter Use filtering for 3D color output. [default]
--3d-nofilter Don't use filtering for 3D color output.
--3d-dmr &lt;x> Set radius for filtering median depth to &lt;x> [default 0]
--3d-fmr &lt;x> Set radius for filtering median diff to &lt;x> [default 0]
--focus &lt;ft> &lt;op> Create focus region with type &lt;ft> and options &lt;op>:
Focus type:
d &lt;d> focus at distance &lt;d>
p &lt;x> &lt;y> focus at point (x, y)
Space-separated options may include zero or more of:
ci=&lt;ci> camera index [default 0]
fr=&lt;fr> focal range [default 0]
ht=&lt;ht> horizontal tilt gradient [default 0]
vt=&lt;vt> vertical tilt gradient [default 0]
ap=&lt;ap> aperture diameter [default 3]
sc=&lt;sc> sample count [default 3]
sx=&lt;sx> start x coordinate [default -Inf]
ex=&lt;ex> end x coordinate [default Inf]
sy=&lt;sy> start y coordinate [default -Inf]
ey=&lt;ey> end y coordinate [default Inf]
sd=&lt;sd> start depth [default 0]
ed=&lt;ed> end depth [default Inf]
sr=&lt;sr> view sample randomization:
aperture per aperture [default]
pixel per pixel
fs=&lt;fs> focal statistic, one of:
mean mean of views [default]
median median of views
</pre>
<h2>Camera parameter adjustment</h2>
<p>In versions 0.8.1 and later, camera parameters can be adjusted according to
control points to decrease the error between points in different frames.
Perturbation bounds for adjustment can be specified, including an additional
upper bound on view angle perturbation, and a stereo threshold can be set for
discarding control points after adjustment is complete. An initial camera view
angle can also be specified. Versions 0.8.2 and later allow calculation of
error by median rather than mean, and also allow disabling of adjustment of
orientation and/or position.
<pre>
--view-angle &lt;x> Set the initial diagonal view angle to &lt;x> degrees.
(Default is 43.7 degrees or device-specific.)
--cpp-upper=&lt;x> Set upper bound &lt;x> for camera parameter perturbation, [0.8.1 and later]
in pixels or degrees [default is 32]
--cpp-lower=&lt;x> Set lower bound &lt;x> for camera parameter perturbation, [0.8.1 and later]
in pixels or degrees [default is 0.125]
--va-upper=&lt;x> View-angle perturbation upper bound in degrees [default is 32] [0.8.1 and later]
--st &lt;x> Control point stereo threshold is &lt;x> pixels. [default is 4] [0.8.1 and later]
--cpp-err-mean Use RMS error to determine camera parameters. [default] [0.8.2 and later]
--cpp-err-median Use median error to determine camera parameters. [0.8.2 and later]
--vp-adjust Adjust the view point [default] [0.8.2 and later]
--vp-noadjust Do not adjust the view point [0.8.2 and later]
--vo-adjust Adjust the view orientation [default] [0.8.2 and later]
--vo-noadjust Do not adjust the view orientation [0.8.2 and later]
</pre>
<h2>Transformation data files [0.8.2 and later]</h2>
Transformation data file options allow reading and writing of camera position,
orientation, and view angle information.
<pre>
--3d-trans-load=x Load initial transformation settings from file x [0.8.2 and later]
--3d-trans-save=x Save final transformation data in file x [0.8.2 and later]
</pre>
<h2>Transformation data file format [0.8.2 and later]</h2>
<p>The transformation data file uses the following format, starting with a version
command, and then describing view angle and euclidean transformation of each
frame in turn:
<pre>
W 0
V &lt;view angle>
E &lt;width> &lt;height> &lt;X> &lt;Y> &lt;Z> &lt;P> &lt;Y> &lt;R>
V &lt;view angle>
E &lt;width> &lt;height> &lt;X> &lt;Y> &lt;Z> &lt;P> &lt;Y> &lt;R>
.
.
.
V &lt;view angle>
E &lt;width> &lt;height> &lt;X> &lt;Y> &lt;Z> &lt;P> &lt;Y> &lt;R>
</pre>
<h2>Model costs [0.8.1 only]</h2>
<p>After the cameras are adjusted, a 2D surface is decomposed and deformed to
reduce local cost measures, calculated from angles between neighboring
triangles, edge lengths, and differences in color between different views.
Multipliers for edge length and angle costs can be specified on the
command line.</p>
<pre>
--ecm &lt;x> Set edge length cost multiplier &lt;x>. [default is 0.001] [0.8.1 only]
--acm &lt;x> Set angle cost multiplier &lt;x>. [default is 0.001] [0.8.1 only]
</pre>
<h2>Model rules [0.8.2 and later]</h2>
<p>In versions 0.8.2 and later, clip planes can be specified, and a color falloff
exponent for pairwise occupancy estimation can be specified. Larger exponents
are more forgiving of color differences between pixels in different frames.
In versions 0.8.3 and later, error contributions from cameras outside of the
generating pair can be assigned non-zero multipliers (<code>--tcem</code>), the
number of occupancy and color update iterations can be specified
(<code>--oui</code>), the number of points in space generated for each pixel
pair can be specified (<code>--pa</code>), and the type of frame pairings can
be specified (<code>--pc</code>).
<pre>
--di-upper &lt;x> Decimate primary input resolution by at most 2^x [default is 0] [0.8.4 and later]
--di-lower &lt;x> Decimate input resolutions by at least 2^x [default is 0] [0.8.4 and later]
--do-try &lt;x> Decimate output resolution by 2^x if possible [default is 0] [0.8.4 and later]
--oc Clip scene to output regions. [0.8.4 and later]
--no-oc Do not clip scene to output regions. [default] [0.8.4 and later]
--fc &lt;x> Set front-clip to &lt;x> (0 &lt; x &lt; 1) [default is 0] [0.8.2 and later]
--rc &lt;x> Set rear-clip to &lt;x> (1 &lt; x &lt; inf) [default is inf] [0.8.2 and later]
--fx &lt;x> Set falloff exponent to &lt;x> [default is 0] [0.8.2 and later]
--tcem &lt;x> Set third-camera error multiplier to &lt;x> [default is 0] [0.8.3 and later]
--oui &lt;x> Set occupancy update iterations to &lt;x> [default is 10] [0.8.3 and later]
--pa &lt;x> Set pairwise ambiguity to &lt;x> [default is 3] [0.8.3 and later]
--pc &lt;type> Set the type of pairwise comparisons: [0.8.3 and later]
auto Determine comparisons automatically. [default]
all Perform all comparisons.
</pre>
<br>
<hr>
<i>Copyright 2004, 2005, 2006 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,182 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Transformation Data Files</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Transformation Data Files</h1>
Transformation data files are useful when performing alignment in several
passes or refining rendering options, and are necessary for specifying
barrel/pincushion distortion parameters. They also offer a way to manually
specify alignment when ALE cannot automatically align images.
<h2>Multiple-pass alignment</h2>
To align images in multiple passes, load the saved results of each previous
pass, as follows:
<pre>
$ ale --trans-save=a.t &lt;first pass arguments&gt;
$ ale --trans-load=a.t --trans-save=b.t &lt;second pass arguments&gt;
$ ale --trans-load=b.t --trans-save=c.t &lt;third pass arguments&gt;
.
.
.
</pre>
<h2>Rendering option refinement</h2>
To refine rendering options using the same alignment, first save the alignment
for the first option set, and then load the saved alignment information with
each subsequent option set, setting the perturbation upper bound to zero to
prevent a new alignment pass from occurring:
<pre>
$ ale --trans-save=a.t &lt;first option set&gt;
$ ale --trans-load=a.t --perturb-upper=0 &lt;second option set&gt;
$ ale --trans-load=a.t --perturb-upper=0 &lt;third option set&gt;
.
.
.
</pre>
<h2>Alignment file syntax (version 2)</h2>
There are two varieties of alignment file syntax that are both read and written
by ALE 0.7.0. The most basic of these is version 2. Version 3 is slightly
more complex, and is covered in the next section.
At the highest level, version 2 transformation data files contain the following
components: (a) a version command, and (b) a sequence of transformation
commands, one for each supplemental frame. Each line of text should contain at
most one command, between which optional comments may be interspersed. A
transformation command can be Euclidean, projective, or default. Euclidean and
projective commands take several arguments, including the width and height of
the supplemental frame. Default commands take no arguments. Commands are
outlined in more detail below.
<h3>Version command</h3>
<p>The version 2 version command is as follows:</p>
<pre>
V 2
</pre>
<h3>Euclidean commands</h3>
<p>The structure of a Euclidean command is as follows:</p>
<pre>
E &lt;image width&gt; &lt;image height&gt; &lt;x-offset&gt; &lt;y-offset&gt; &lt;rotation-angle&gt;
</pre>
<h3>Projective commands</h3>
<p>Projective commands map the four corners of the supplemental frame to four
points in the rendering coordinate system:</p>
<pre>
P &lt;image width&gt; &lt;image height&gt; &lt;top-left-x&gt; &lt;top-left-y&gt; &lt;blx&gt; &lt;bly&gt; &lt;brx&gt; &lt;bry&gt; &lt;trx&gt; &lt;try&gt;
</pre>
<h3>Default commands</h3>
Default commands can be explicitly written as follows:
<pre>
D
</pre>
Alternatively, if there are more frames than alignment commands (euclidean,
projective, or default), then the last supplemental frames in the frame
sequence will be assigned the default command.
<h3>Comments</h3>
Comments can be inserted with the following syntax:
<pre>
# This comment extends to the end of this line. I can write anything I want here.
</pre>
<h2>Alignment file syntax (version 3)</h2>
Version 3 syntax is required for specifying transformations for the original
frame, and for specifying barrel/pincushion distortion parameters.
<p>In version 3, the first transformation command is associated with the
original frame, instead of being associated with the first supplemental frame.
Also, barrel/pincushion distortion commands can precede each projective,
Euclidean, or default command.
<h3>Version command</h3>
<p>The version 3 version command is as follows:</p>
<pre>
V 3
</pre>
<h3>Barrel/pincushion distortion command</h3>
In version 3, barrel/pincushion distortion commands are supported. Distortion
is modeled as a transformation affecting the distance of image features from the
image center. The distorted distance is expressed as a polynomial function of
the undistorted distance. Zeroth and first order coefficients are fixed or
automatically determined; additional coefficients can be specified explicitly,
using the following syntax:
<pre>
B &lt;n&gt; &lt;coefficient 2&gt; &lt;coefficient 3&gt; ... &lt;coefficient n+1&gt;
</pre>
<p>Barrel/pincushion distortion commands should precede the projective, Euclidean,
or default transformation command for the corresponding frame.</p>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,331 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Alignment</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Alignment</h1>
<p>Alignment compares each supplemental frame in the sequence with an intermediate
incremental rendering known as the alignment reference image. Based on this
comparison, a transformation is assigned to the supplemental frame. Many
different transformations can be assigned before alignment of the frame is
complete.
<p>This manual page offers an overview of alignment options; linked from this
page is a sub-page offering more detail on <a href="file/">transformation
data files</a>.
<h2>Transformations</h2>
<p>The variables used to adjust alignment are called transformations; they map
points from the source image coordinate system to a target coordinate system
(the rendering coordinate system).
<p>ALE supports three transformation classes -- translational, euclidean, and
projective -- as well as barrel/pincushion distortion correction. The
translational class applies only translations to the inputs, changing only the
positions of images; the Euclidean class applies translations and rotations;
and the projective class applies general projective transformations.
Additionally, barrel/pincushion distortion correction can be applied to each
frame. The Euclidean class is most appropriate for use with scanners, or as a
first pass for projective transformations. The projective class and
barrel/pincushion distortion correction are most appropriate for use with
cameras. Except when capturing flat scenes, ALE does not correct perspective
changes, so movement of cameras should ideally be constrained so that no large
translations occur.
<h3>Transformation Class Options</h3>
<pre>
--translation Only adjust the position of images
--euclidean Adjust the position and orientation of images [default]
--projective Use projective transformations. Best quality, but slow.
</pre>
For more information on barrel distortion correction, see the sub-page on
<a href="file/">transformation data files</a>.
<h3>Transformation data file options</h3>
<p>Transformations used in alignment can be loaded from, or saved to, a <a
href="file/">transformation data file</a>. This can be useful when performing
alignment in several passes, or when refining rendering options. A
transformation data file is required for barrel/pincushion distortion
correction.
<pre>
--trans-load=x Load initial transformation settings from file x
--trans-save=x Save final transformation data in file x
</pre>
<h3>Alignment following</h3>
<p>The --follow option hints that frames tend to be more closely aligned with
adjacent frames in the sequence than with the original frame. This hint can be
useful even when initial alignment information is loaded from a file.
<pre>
--identity Frames align closely with the original frame. [default]
--follow Frames align closely with their immediate predecessor.
</pre>
<h2>Match statistics</h2>
<p>The match statistic indicates how well a transformed frame aligns with the
alignment reference image; it is used to select or reject transformations
during alignment. After alignment of a particular frame is complete, ALE
displays the corresponding final match statistic. If the value is close to
100%, then the frames are well aligned; very low values can indicate
misalignment; but even frames that are very well aligned typically do not
achieve 100% alignment. For improving image quality, ALE works most
effectively when match values are lower than 100%.
<h3>Match threshold</h3>
<p>A match threshold can be specified; no images with final match statistics
falling below this threshold will contribute to the final output.
<pre>
--threshold=x Min. match threshold; a perfect match is 100. (0 is default)
</pre>
<h3>Alignment failure</h3>
<p>When an image fails to meet the match threshold, a transformation is still
assigned to the frame (e.g., for writing to a <a href="file/">transformation
data file</a>). The assigned transformation can be either the optimal
alignment found (this is default) or the default transformation.
<pre>
--fail-optimal Frames beneath threshold are aligned optimally. [default]
--fail-default Frames beneath threshold keep their default alignment.
</pre>
<h3>Alignment error metric exponent</h3>
<p>The function calculated at each pixel to determine the match statistic is called
the alignment error metric, and is of the form <i>(a-b)<sup>x</sup></i>.
The value <i>x</i> is called the error metric exponent, and is 2 by default.
Larger numbers indicate that alignment will be more influenced by smaller
image features.
<pre>
--metric=x Set the alignment error metric exponent. (2 is default)
</pre>
<h3>Alignment Channel Options</h3>
<p>In calculating the per-pixel error metric, there are three ways in which ALE
can handle color channels. By default, ALE adds the channels before
calculating the match, but it can also be configured to rely solely on the
green color channel, or to use all three channels separately.
<pre>
--align-all Align images using all color channels
--align-green Align images using the green channel
--align-sum Align images using a sum of channels [default]
</pre>
<h3>Monte Carlo Alignment</h3>
<p>Aligning large images can take a very long time if all pixels are examined in
determining the match statistic, so it is often desirable to examine a smaller
subset of pixels. The Monte Carlo alignment option allows this. The number of
pixels used is specified as a percentage, and smaller numbers usually mean
faster, but less precise, alignment. For defaults, see the <a href="../defaults/">
default settings</a> page.
<pre>
--mc &lt;x&gt; Align using, on average, x% of available pixels (0 &lt; x &lt; 100)
--no-mc Align using all pixels.
</pre>
<h3>Alignment weight map</h3>
<p>Typically, measured differences at each pixel in the alignment reference
image contribute equally to the match statistic. To weight pixels differently,
a weight map can be used. The scale of the map should correspond with that of
the alignment reference image, and if the upper-left corner of the map does not
coincide with the upper-left corner of the first frame in the sequence, then a
non-zero offset should be specified to indicate the difference. See also <a
href="../exclusion/">exclusion regions</a>.
<pre>
--wm &lt;f&gt; &lt;x&gt; &lt;y&gt; Use weight map image &lt;f&gt; at offset (&lt;x&gt;, &lt;y&gt;)
</pre>
<h3>Frequency weighting</h3>
<p>If ALE is compiled with FFTW support, then a high-pass-filtered version of
the alignment reference image can be used to weight reference image pixels'
contributions to the match statistic. Frequency limiting can occur as a
fraction of the highest horizontal frequency, the highest vertical frequency,
or the highest average frequency. Limit values should range between 0 (pass
all) and 1 (pass none). If any limit is assigned a value of 1, no alignment
will occur, since all frequencies will have been excluded. An output file can
optionally be specified for high-pass filtered data.</p>
<pre>
--fl &lt;h&gt; &lt;v&gt; &lt;a&gt; High-pass filters: horizontal &lt;h&gt;, vertical &lt;v&gt;, average &lt;a&gt;.
--flshow &lt;o&gt; Write high-pass filtered data to file &lt;o&gt;.
</pre>
<h3>Certainty weighting</h3>
<p>Certainty weighting causes contributions to alignment error to be weighted
by certainty values.</p>
<pre>
--cw Weight alignment error by certainty.
--no-cw Don't weight alignment error by certainty. [default]
</pre>
<h3>Algorithmic weighting</h3>
<p>This option writes the current alignment reference image and definition map
to specified files, executes a specified program with these arguments, and then
reads back alignment weights. This option requires POSIX libraries, and
requires that ALE have been built with POSIX support enabled.</p>
<pre>
--wmx &lt;e&gt; &lt;r&gt; &lt;d&gt; Write reference &lt;r&gt;, definition &lt;d&gt;, execute `&lt;e&gt; &lt;f&gt; &lt;d&gt;`,
read weights &lt;r&gt; back.
</pre>
<h2>Perturbation</h2>
<p>The perturbation size determines the magnitude by which alignment parameters
are changed. The size is initially set to be large, allowing large changes in
alignment to be evaluated, and is reduced as the locally optimal alignment is
found for each size. When this size drops below a specified lower bound, the
frame is considered to be aligned.
<h3>Perturbation bounds</h3>
<p>These options determine the upper and lower bounds for perturbation size. The
perturb-upper and perturb-lower bounds apply to rotation (in arclength),
translation (in pixels), and the movement of the boundaries of a projected
frame (in pixels). By appending the '%' character, values may optionally be
specified as a percentage of the number of pixels in the smallest image
dimension. The rot-upper bound disables rotational perturbation above a
certain perturbation size (in degrees). To disable alignment, set
perturb-upper to zero.
<pre>
--perturb-upper=x Perturbation upper bound pixels/arclength (14% is default)
('x%' uses a fraction of the smallest image dimension.)
--perturb-lower=x Perturbation lower bound pixels/arclength (.125 is default)
('x%' uses a fraction of the smallest image dimension.)
--rot-upper=x Rotation-specific upper bound in degrees (32.0 is default)
</pre>
<h3>Barrel/pincushion distortion adjustment multiplier and rate</h3>
<p>When using barrel/pincushion distortion parameters, any frame-to-frame
adjustments to these parameters are made in a manner dependent on the
perturbation size. A multiplier, the barrel distortion adjustment multiplier,
is used to determine the perturbation of these parameters, based on the generic
perturbation size. Additionally, the frame-to-frame rate of change of each
barrel distortion parameter can be limited to a specified maximum. To disable
frame-to-frame adjustment of barrel/pincushion distortion parameters, set
bda-mult to zero. Setting bda-rate to zero disables rate limitation.
<pre>
--bda-mult=x Barrel distortion adjustment multiplier (0.0001 is default)
--bda-rate=x Barrel distortion rate of change maximum (0.0004 is default)
</pre>
<h3>Level of detail</h3>
<p>Alignment at large perturbation sizes is usually carried out on
reduced-detail images. To disable this, set lod-max to
log<sub>2</sub>(perturb-upper).
<pre>
--lod-max=x LOD scale factor is max(1, (2^floor(x))/perturb) (1 is def.)
</pre>
<h3>Perturbation Types (experimental)</h3>
<p>Perturbations are normally performed in output image coordinates. To perform
perturbations in source image coordinates, specify <code>--perturb-source</code>.
<pre>
--perturb-output Apply perturbations in output image coordinates. [default]
--perturb-source Apply perturbations in source image coordinates.
</pre>
<h3>Global Searching</h3>
<p>In cases where important image features do not have sufficient overlap using
default alignment parameters (determined by <code>--identity</code> and
<code>--follow</code>), a number of translations can be applied to the default
parameters in order to find a new alignment starting point. Since this process
searches the entire region of the alignment reference image, it is called a
global (as opposed to local) search. To avoid misalignment, a minimum overlap
area can be specified. In versions 0.8.1 and later, the search type 'points'
searches for a control point metric minimum.
<pre>
--gs &lt;type> Set global search to &lt;type>, one of:
local Local alignment only [default]
inner Alignment reference image inner region
outer Alignment reference image outer region
all Union of inner and outer
central inner if below threshold or better; else, outer.
points Align by control points. Ignores gs-mo. [0.8.1 and later]
--gs-mo &lt;x> Set &lt;x> pixel min. overlap for global search. (16 is default)
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,121 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Control Points</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>Control Points [0.8.1 and later]</h1>
<p>Control points are used for 2D and 3D alignment, and to constrain 3D scene
models. Control point data is loaded from a control point file. Scripts to
generate and manipulate control point files are included in the
<code>scripts</code> directory of the source distribution; the file
specification is outlined in the final section below.
<h2>Loading a Control Point File</h2>
The --cpf-load= option is used to load data from a control point file.
<pre>
--cpf-load=&lt;f> Load control point data from file &lt;f> [0.8.1 and later]
</pre>
<h2>Control Point File Format (version 0)</h2>
The version 0 control point file format consists of a version command followed
by a sequence of control points, with one control point per line of the file.
<pre>
V 0
<i>Control Point 1</i>
<i>Control Point 2</i>
<i>Control Point 3</i>
.
.
.
</pre>
<p>Control points can be one of three types:</p>
<h3>Type A control points</h3>
Type A control points specify a sequence of 2D points, one for each frame,
where each point is specified as a pair of floating point numbers. If there is
no data for a frame, then "nan" should be specified. E.g.:
<pre>
A 20 30 nan nan 10 10 10 15
A 23 22 25 25 nan nan nan nan
</pre>
<h3>Type B control points</h3>
Type B control points specify a 3D coordinate. E.g.:
<pre>
B 10 30 -400
B 10 15 -425
</pre>
<h3>Type C control points</h3>
Type C control points specify both 2D and 3D data. There is a single 3D point
specified, as well as one 2D point for each frame. The 3D point appears at the
end of the line. E.g.:
<pre>
C 20 30 nan nan 10 10 10 15 10 30 -400
C 23 22 25 25 nan nan nan nan 10 15 -425
</pre>
<br>
<hr>
<i>Copyright 2005 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,165 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Default Settings</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Default Settings</h1>
<p>ALE offers five different default settings, each of which emphasizes
image quality, speed, or some other rendering characteristic, as follows:</p>
<pre>
--q0 Low quality, high speed. [default]
--qn Low noise, moderate speed.
--q1 Moderate quality and speed.
--q2 High quality, low speed.
--qr Range-extended high quality.
</pre>
<p>These settings specify defaults for other options: <code>--dchain</code>, <code>--achain</code>,
<code>--mc</code>, <code>--ips</code>, <code>--exp-extend</code>, and <code>--cx</code>. For
more information about these options, see the <a href="../alignment/">alignment</a> and <a href="../rendering/">rendering</a>
manual pages. Details regarding these defaults are provided in the following sections.
<h2>High speed (--q0)</h2>
<code>--q0</code> emphasizes speed over image quality. This option is default, and
sets other options' defaults as follows:
<pre>
--dchain fine:box:1,triangle:2
--achain triangle:2
--mc 30
--ips 0
--exp-noextend
--no-cx
</pre>
<h2>Low noise (--qn)</h2>
<code>--qn</code> emphasizes low noise over resolution and rendering speed, and
sets the following defaults:
<pre>
--dchain sinc*lanc:6
--achain sinc*lanc:6
--mc 50
--ips 0
--exp-noextend
--no-cx
</pre>
<h2>Balanced quality and speed (--q1)</h2>
<code>--q1</code> balances image quality and rendering speed, offering higher
resolution than <code>--qn</code>. In versions 0.8.1 and later, this option
uses median values, which can be very memory-intensive to calculate. The
following defaults are used in versions 0.8.1 and later:
<pre>
--dchain median:fine:sinc*lanc:8,triangle:2 [0.8.1 and later]
--achain triangle:2 [0.8.1 and later]
--mc 50
--ips 0
--exp-noextend
--no-cx
</pre>
In 0.8.0, the following defaults are used:
<pre>
--dchain fine:sinc*lanc:6,sinc*lanc:6 [0.8.0]
--achain sinc*lanc:6 [0.8.0]
--mc 50
--ips 0
--exp-noextend
--no-cx
</pre>
<h2>High quality (--q2)</h2>
<p><code>--q2</code> favors image quality over rendering speed, offering greater
emphasis for high-frequency details than <code>--q0</code>, <code>--qn</code>,
or <code>--q1</code>. It depends on the <code>--lpsf</code> and
<code>--nlpsf</code> options, which can be set indirectly via the
<code>--device</code> option. (More information about these options can be
found on the <a href="../rendering/psf">PSF</a> and <a href="../device/">device</a> pages.) <code>--q2</code>
sets the following defaults:
<pre>
--dchain sinc*lanc:8
--achain sinc*lanc:8
--no-mc
--ips 4
--exp-noextend
--no-cx
</pre>
<h2>Range extension (--qr)</h2>
<p><code>--qr</code> is similar to <code>--q2</code>, but offers improved
rendering when input images have been taken with unequal exposures. In other
cases, it might exacerbate noise in light and dark regions, and so should not
be used. This option sets the following defaults:
<pre>
--dchain sinc*lanc:8
--achain sinc*lanc:8
--no-mc
--ips 6
--exp-extend
--cx 0.7
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,101 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Devices</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Devices</h1>
<p>Device specification is optional. Specifying a device allows automatic
determination of <a href="../rendering/psf/">point-spread functions</a>,
refinement of the correspondence between incident light and pixel values (e.g.
power law), and refinement of certainty calculation.
<pre>
--device &lt;d&gt; Set the capture device to &lt;d&gt;.
</pre>
<p>Available devices are as follows:</p>
<table border>
<tr><td>canon_300d_raw_linear<td>Canon 300D (Digital Rebel) raw, linear data.
<tr><td>canon_300d_raw_linear+50mm_1.4<td>Canon 300D with EF 50mm f/1.4 lens, unspecified aperture.
<tr><td>canon_300d_raw_linear+50mm_1.4@1.4<td>Canon 300D with EF 50mm f/1.4 lens, aperture 1.4.
<tr><td>canon_300d_raw_linear+50mm_1.8<td>Canon 300D with EF 50mm f/1.8 lens, unspecified aperture.
<tr><td>canon_300d_raw_linear+85mm_1.8<td>Canon 300D with EF 85mm f/1.8 lens, unspecified aperture.
<tr><td>ov7620_raw_linear<td>OmniView OV7620 in raw RGB, linear mode.
<tr><td>xvp610_640x480<td>IBM PC Camera Pro (XVP610) in 640x480 mode.
<tr><td>xvp610_320x240<td>IBM PC Camera Pro (XVP610) in 320x240 mode.
</table>
<p>These device options are described in more detail below.
<h2>Canon 300D (Digital Rebel)</h2>
<p>Direct support for CRW files depends on the ImageMagick configuration, and
may not be available on all platforms. Dave Coffin's <a
href="http://www.cybercom.net/~dcoffin/dcraw/">dcraw</a> program, invoked with
arguments -d -4, will produce a raw, linear PPM file suitable for use with this
device configuration. JPEG files produced by the 300D cannot be directly used
as inputs for this configuration, since they are gamma-corrected rather than
linear.</p>
<h2>OV7620</h2>
<p>Standard OV7620 drivers may not include options for setting raw RGB or linear
modes. Linux users may apply a <a href="/ov7620/">driver patch</a> to access
these modes. Setting the module option <code>rgb_raw=2</code> places the camera
into the desired mode.</p>
<h2>XVP610</h2>
<p>Users of XVP610 cameras and Linux may wish to apply a <a href="/xvp610/">driver patch</a>. This version of ALE expects that this patch has been applied.
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,88 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Exclusion Regions</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Exclusion Regions</h1>
<p>ALE offers exclusion regions as a way to disallow certain areas from being
used in alignment and (optionally) rendering. Spatial coordinates are
expressed in the rendering coordinate system (prior to scaling). In cases
where the default transformation is used with the original frame, this is
identical to the unscaled original frame coordinate system, taking the
upper-left corner to be (0, 0). Frame numbering begins with 0, which represents
the original frame.
<h2>Rectangular Exclusion</h2>
<p>All specified volumes are excluded from alignment (except where they affect
the alignment reference image), and are excluded from rendering by default.
(See the <a href="../rendering/chains/">rendering chains</a> page for
information on how to ignore exclusion regions.) Exclusion region syntax is
as follows:
<pre>
--ex &lt;args&gt; Exclude a specified volume.
&lt;args&gt; are space-delimited horizontal,
vertical, and frame limits:
&lt;xmin&gt; &lt;xmax&gt; &lt;ymin&gt; &lt;ymax&gt; &lt;fmin&gt; &lt;fmax&gt;
</pre>
<h2>Cropping</h2>
Cropping excludes the spatial complement of an area over a specified set of
frames.
<pre>
--crop &lt;args&gt; Exclude the spatial complement of an area over a
specified set of frames. &lt;args&gt; are:
&lt;xmin&gt; &lt;xmax&gt; &lt;ymin&gt; &lt;ymax&gt; &lt;fmin&gt; &lt;fmax&gt;
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,119 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: File Output</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE File Output</h1>
<p>File output options determine the format in which rendered images are written,
and how frequently they are written. Depending on the compilation options used,
available file output options vary.
<h2>Output Color Depth</h2>
<p>Output color depth of 8 or 16 bits of precision per color channel can be specified,
for 24-bit or 48-bit color, respectively.
<pre>
--8bpc Write 8 bit per channel output [default]
--16bpc Write 16 bit per channel output
</pre>
<h2>Extension-based file type determination</h2>
<p>If ALE has been built with ImageMagick support, then the output file type can
be determined automatically by file extension. This is the default behavior
for ImageMagick builds. The <code>--auto</code> flag explicitly specifies that
the default behavior should be used; it generates an error on builds compiled
without ImageMagick support.
<pre>
--auto Determine file type automatically
</pre>
<h2>PPM Output</h2>
<p>All builds of ALE support PPM output. PPM can be written in plain (ASCII) or
raw (binary) format. If ALE has been built without ImageMagick support, or if
the file type cannot be automatically determined by file extension, then raw
PPM output is used by default.
<pre>
--raw Write raw PPM output
--plain Write plain PPM output
</pre>
<h2>Incremental Output</h2>
<p>By default, ALE writes intermediate results periodically throughout the rendering
process. This behavior can be disabled, however, so that output is written only
after rendering is complete.
<pre>
--inc Produce incremental output. [default]
--no-inc Don't produce incremental output.
</pre>
<h2>Undefined Values [0.8.3 and later]</h2>
<p>By default, ALE colors undefined values black. To assign nearest-neighbor colors
to undefined pixels, the <code>--def-nn</code> option can be used. This option is only
available in versions 0.8.3 and later.
<pre>
--def-nn &lt;R> Use nearest-neighbor defined values within [0.8.3 and later]
radius &lt;R>, zero outside. Default radius is 0.
</pre>
<br>
<hr>
<i>Copyright 2003, 2004, 2005 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,219 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE 0.8.x User Manual</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../../user/">Up</a> ]</b></p>
<h1>ALE 0.8.x User Manual</h1>
<h2>Purpose</h2>
<p>This page summarizes program operation and command-line usage for ALE
versions 0.8.0 through 0.8.4. Features specific to a particular version
are annotated (e.g. [ALE 0.8.1 and later]).
<p>Manual pages linked from this section describe <a href="defaults/">default
settings</a>, <a href="file/">file output</a>, <a
href="alignment/">alignment</a>, <a href="rendering/">rendering</a>, <a
href="exclusion/">exclusion regions</a>, <a href="cp/">control points</a>, <a href="ui/">user interfaces</a>, <a
href="device/">devices</a>, and <a href="3d/">3D scene reconstruction</a>.
<p>For more information on ALE, see the <a
href="http://auricle.dyndns.org/ALE/">ALE Home Page</a>.
<h2>Parameter Meta-syntax</h2>
<table>
<tr>
<td><code>&nbsp;&lt;foo></code></td>
<td>A required parameter called <i>foo</i>.</td>
</tr>
<tr>
<td><code>[&lt;foo>]</code></td>
<td>An optional parameter called <i>foo</i>.
</tr>
<tr>
<td><code>[&lt;foo>]*</code></td>
<td>Zero or more parameters <i>foo</i>.
</tr>
</table>
<h2>Command-line syntax for Image Processing</h2>
<p>The following command-line invocation can be used to process a series of
frames into an output file:
<pre>ale [&lt;option>]* &lt;original-frame> [&lt;supplemental-frame>]* &lt;output-file></pre>
<h3>Option Arguments</h3>
<p>Certain basic modes of operation, emphasizing image quality, speed, or other
rendering characteristics, are now established in the form of <a
href="defaults/">default settings</a>.
<p>Other options are outlined in the manual pages describing <a
href="file/">file output</a>, <a href="rendering/">rendering</a>, <a
href="alignment/">alignment</a>, <a href="exclusion/">exclusion
regions</a>, <a href="device/">devices</a>, <a href="ui/">user interfaces</a>,
and <a href="3d/">3D scene reconstruction</a>.
<h3>Image Files</h3>
<p>ALE can be configured at compile time to use one of two different file
handlers. Execute 'ale --version' to determine which file handler is being
used. The table below outlines the supported formats for each file handler.</p>
<table class="inline">
<td>
<table border>
<tr><th>Version Message</th><th>File Types Supported</th></tr>
<tr><td valign=top>
<pre>File handler: ImageMagick</pre>
</td>
<td>
Input and output files can be any of the <a
href="http://imagemagick.sourceforge.net/www/formats.html">formats</a> supported by
ImageMagick.
</td></tr>
<tr><td valign=top>
<pre>File handler: PPM</pre>
<td>
Input files must be PPM, and output files are written as PPM.
</td></tr>
</table>
</table>
<p>Note that many external programs, including ImageMagick's <a
href="http://www.imagemagick.org/">command line utilities</a>, can be used to
convert between PPM and other formats.</p>
<p>See the README included in the source distribution of ALE for more information about
compile-time configuration of file handlers.</p>
<h2>Command-line syntax for Version Information</h2>
<p>The following command-line invocation can be used to print version
information and build options:
<pre>ale --version</pre>
The following is sample output from this invocation:
<pre>
ALE Version: 0.8.4
File handler: ImageMagick
Color data: SINGLE
Coordinate data: SINGLE
DFT: FFTW3
Assertions: Enabled
Optimizations: Enabled
</pre>
<p>The first line of output indicates the version of ALE source code being
used; the remaining lines reflect the build options selected at compile
time.
<p>For more information about build options, see the README file included in
the ALE source distribution.
<h2>Command-line syntax for Help Output</h2>
<p>When invoked with no arguments, or an insufficient number of file arguments,
ALE outputs a help message specifying command-line usage and available help
topics. The following is a sample invocation:
<pre>ale</pre>
<h3>Help Topics</h3>
More information about specific help topics can be obtained with an invocation
of the following form:
<pre>ale &lt;help option&gt;</pre>
Available help options, and their corresponding help topics, are outlined
below:
<pre>
--hu Usage.
--hq Default settings.
--hf Image files.
--he Exclusion regions.
--ha Alignment (not exposure-related).
--hr Rendering (not exposure-related).
--hx Exposure.
--ht Transformation data files.
--hc Control points. [0.8.1 and later]
--hl Filtering (PSFs, rendering chains).
--hd Devices.
--hi User Interfaces.
--hv Video stream processing (Experimental).
--h3 3D Modeling.
--hz Undocumented options.
--hA Concatenate all help pages.
</pre>
<h2>Related Manual Pages</h2>
<ul>
<li><a href="defaults/">Default Settings</a>
<li><a href="file/">File Output</a>
<li><a href="rendering/">Rendering</a>
<li><a href="alignment/">Alignment</a>
<li><a href="exclusion/">Exclusion Regions</a>
<li><a href="cp/">Control Points (0.8.1 and later)</a>
<li><a href="device/">Devices</a>
<li><a href="ui/">User Interfaces</a>
<li><a href="3d/">3D Scene Reconstruction</a>
</ul>
<br>
<hr>
<i>Copyright 2003, 2004, 2005, 2006 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p class="footer">Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,102 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: EPPM Files</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>EPPM Files</h1>
<p>EPPM is an extension to the PPM file format that allows specification of
metadata. The header of an EPPM file conforms to the following template:
<pre>
P6#E
# Tag1: Value
# Tag2: Value
# Tag3: Value
# .
# .
# .
Width Height Maxval
Data
</pre>
<p>Tags recognized by ALE are outlined below.
<h2>Black level</h2>
<P>The black level tag specifies a value that should be subtracted from
all pixels in order to achieve linearity. A modified version of dcraw (<a
href="/darcs/dcraw">darcs repository</a>) can be used to generate files
containing this tag.
<pre>
# Black-level: &lt;value&gt;
</pre>
<h2>Exposure tags</h2>
<p>Exposure tags can be used for determining tonal registration through
specification of shutter speed, aperture, and ISO sensitivity (or gain).
<pre>
# Shutter: &lt;value&gt;
# Shutter: 1/&lt;value&gt;
# Aperture: &lt;f-number&gt;
# ISO: &lt;value&gt;
# Gain: &lt;value&gt;
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,177 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Rendering Chains</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Rendering Chains</h1>
<p>The ALE incremental renderer is configured using rendering chains. Rendering chains are
constructed hierarchically from: invariants, SSFEs (scaled sampling filters
with exclusion), SSFs (scaled sampling filters), and sampling filters. Each of
these components is described in a section below. Defaults are outlined in the
final section.
<h2>Chains</h2>
<p>The chain is the top level of the rendering chain hierarchy, and is composed of a
sequence of invariants. Syntactically, a chain is specified as a number of
invariants separated by commas:
<blockquote>
<code>invariant<sub>1</sub>,invariant<sub>2</sub>,invariant<sub>3</sub>,...,invariant<sub>n</sub></code>
</blockquote>
<p>Each rendered pixel is assigned a value at the first invariant whose weight
exceeds the weight threshold, or otherwise at the last invariant in the sequence.
<h3>Chain Options</h3>
<pre>
--wt &lt;w&gt; Set weight threshold for defined pixels [default is 0.8 in v0.8.0; 0.1 in v0.8.1 and later]
--dchain &lt;g&gt; Use chain &lt;g&gt; to render the default output.
--ochain &lt;g&gt; &lt;o&gt; Use chain &lt;g&gt; to render output file &lt;o&gt;.
--achain &lt;g&gt; Use chain &lt;g&gt; to render the alignment reference image.
--3d-chain &lt;g> Use chain <g> by default to render 3d output. [0.8.4 and later]
</pre>
<h3>Chain Examples</h3>
<pre>
triangle:2 ALE 0.6.0 merging (roughly)
fine:box:1 Drizzling (roughly)
fine:sinc*lanc:8 High-frequency preservation
last:nex:sinc*lanc:8 Useful for video stabilization
fine:box:1,triangle:2 Multi-resolution rendering
fine:sinc*lanc:8,sinc*lanc:8 Multi-resolution rendering
</pre>
<h2>Invariants</h2>
<p>Invariants determine whether the rendered pixel value should be taken from a
single frame, or from an average of all frames. If from a single frame, it can
be the first, last, minimal, or maximal pixel value. Averages include mean
and, in versions 0.8.1 and later, the median. By default, the mean is used.
(Note that using the median value may require allocation of a quantity of
memory linear in the number of frames.) The syntax is as follows:
<blockquote>
<table>
<tr><th align=left>Syntax</th><th><pre> </pre></th><th align=left>Description</th></tr>
<tr><td>avg:&lt;SSFE&gt;<td><td>Mean value
<tr><td>median:&lt;SSFE&gt;<td><td>Median value [0.8.1 and later]
<tr><td>max:&lt;SSFE&gt;<td><td>Maximum value
<tr><td>min:&lt;SSFE&gt;<td><td>Minimum value
<tr><td>first:&lt;SSFE&gt;<td><td>First value
<tr><td>last:&lt;SSFE&gt;<td><td>Last value
<tr><td>&lt;SSFE&gt;<td><td>Same as avg:&lt;SSFE&gt;
</table>
</blockquote>
<h2>Scaled Sampling Filter with Exclusion (SSFE)</h2>
<p>SSFEs qualify SSFs, indicating whether exclusion regions should be honored.
<blockquote>
<table>
<tr><th align=left>Syntax</th><th><pre> </pre></th><th align=left>Description</th></tr>
<tr><td>ex:&lt;SSF&gt;<td><td>Honor exclusion regions
<tr><td>nex:&lt;SSF&gt;<td><td>Don't honor exclusion regions
<tr><td>&lt;SSF&gt;<td><td>Same as ex:&lt;SSF&gt;
</table>
</blockquote>
<h2>Scaled Sampling Filter (SSF)</h2>
<p>SSFs indicate whether filtering should occur at the resolution of the output
image, or at the minimum of input and output image resolutions. The former prevents loss
of details; the latter prevents aliasing.
<blockquote>
<table>
<tr><th align=left>Syntax</th><th><pre> </pre></th><th align=left>Description</th></tr>
<tr><td>fine:&lt;SF&gt;<td><td>Filter at full output image resolution
<tr><td>coarse:&lt;SF&gt;<td><td>Filter at minimum resolution
<tr><td>&lt;SF&gt;<td><td>Same as coarse:&lt;SF&gt;
</table>
</blockquote>
<h3>SSF Options</h3>
<pre>
--afilter &lt;s&gt; Use SSF &lt;s&gt; to interpolate points in alignment.
</pre>
<h2>Sampling Filter (SF)</h2>
<p>SFs are used to limit bandwidth. Primitive functions and pointwise multiplication of these
functions (windowing) are available.
<blockquote>
<table>
<tr><th align=left>Syntax</th><th><pre> </pre></th><th align=left>Description</th></tr>
<tr><td>sinc<td><td>Sinc filter: (sin &pi;x) / (&pi;x)</td>
<tr><td>lanc:&lt;x&gt;<td><td>Lanczos, diameter x.
<tr><td>triangle:&lt;x&gt;<td><td>Triangle, diameter x.
<tr><td>box:&lt;x&gt;<td><td>Box, diameter x.
<tr><td>zero<td><td>Zero function
<tr><td>&lt;f&gt;*&lt;f&gt;<td><td>Pointwise multiplication (windowing)
</table>
</blockquote>
<h2>Defaults</h2>
<p>ALE defaults are as follows:</p>
<pre>
dchain Varies by <a href="../../defaults/">default setting</a>
achain Varies by <a href="../../defaults/">default setting</a>
afilter internal (approximates triangle:2)
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,216 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Rendering</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Rendering</h1>
<p>Rendering determines how an output image is constructed from a series of
aligned input frames, and occurs in two stages: incremental rendering and
Irani-Peleg rendering. Additional rendering options include exposure
registration, certainty-weighted rendering, spatial extension, range extension,
scaling, and bayer pattern specification. Experimental options for video
stream processing are also available.
<h2>Incremental Rendering</h2>
<p>The incremental renderer uses configurable <a href="chains/">rendering
chains</a> to determine the output image. It can increase resolution and
reduce aliasing, but it cannot reduce blur.
<h2>Irani-Peleg Rendering</h2>
<p>The Irani-Peleg renderer uses configurable <a href="psf/">point-spread
functions</a> to model blur, which is then reduced by an iterative
backprojection technique. (For iteration defaults, see the <a
href="../defaults/"> default settings</a> page.) In versions 0.8.1 and
later, using the median correction value can be specified. By default,
the mean correction value is used.
<pre>
--ips &lt;i&gt; Run &lt;i&gt; iterations.
--ip-mean Use the mean correction [default] [0.8.1 and later]
--ip-median Use the median correction [0.8.1 and later]
</pre>
<h2>Exposure Registration</h2>
<p>By default, ALE adjusts an exposure model to minimize differences in tone
between frames. The option <code>--exp-noregister</code> indicates that
exposure should be assumed uniform across all frames. In this case, no
adjustment is performed. The option <code>--exp-meta-only</code> indicates
that only exposure information included in the image files should be used for
registration. Currently, <a href="EPPM/">EPPM</a> is the only type of exposure
metadata supported by this option.</p>
<pre>
--exp-register Register exposure between frames. [default]
--exp-noregister Assume uniform exposure across all frames.
--exp-meta-only Use only image metadata for registering exposure.
</pre>
<h2>Color Adjustment [0.8.1 and later]</h2>
<p>To adjust the color of the output image (e.g., for white balance) in
versions 0.8.1 and later, the --exp-mult= option can be used.</p>
<pre>
--exp-mult=c,r,b Adjust all channels by &lt;c&gt;, red by &lt;r&gt;, and blue by &lt;b&gt;. [0.8.1 and later]
</pre>
<h2>Certainty-weighted Rendering</h2>
<p>The exposure model in ALE includes an associated certainty function, which
quantifies the reliability of sensor measurements. By default, this function
is raised to the zeroth power, to obtain uniform certainty for all measurements.
To specify a different certainty exponent, the option <code>--cx</code> can be
used. This option is best used in combination with <code>--exp-extend</code>
(see below) and <code>--ips</code>. For defaults, see the <a href="../defaults/">
default settings</a> page.
<pre>
--cx &lt;x> Render with certainty exponent &lt;x>
--no-cx Render with uniform certainty.
</pre>
<h2>Scale factor</h2>
<p>Rendering with a larger scale factor results in image output of the specified
larger scale. Larger scales can improve alignment precision and output image
quality, but can also increase alignment and rendering times.
<pre>
--scale=x Scale images by the factor x, where x > 0. (1 is default)
</pre>
<h2>Image extents</h2>
<p>The --extend option records pixel data that falls outside of the region of the
first frame in the sequence. This can be useful for providing additional
alignment constraints or creating panoramic image mosaics. (For mosaics, see
also the description of the --follow option in the <a
href="../alignment">alignment</a> section.)
<pre>
--extend Increase image extents to accommodate all pixel data.
--no-extend Don't increase extents; crop to original frame. [default]
</pre>
<h2>Exposure extents</h2>
<p>By default, ALE restricts the output range to that of the original frame.
To adjust the output range to accommodate the ranges of all input frames,
specify <code>--exp-extend</code>. For defaults, see the <a href="../defaults/">
default settings</a> page.
<pre>
--exp-extend Extend range to include all calculated values.
--exp-noextend Restrict to the original frame's range.
</pre>
<h2>Bayer pattern specification</h2>
<p>Many cameras sample only one color channel per output pixel. To ignore the
other channels, a bayer pattern can be specified.
<pre>
--bayer &lt;b&gt; Set the bayer pattern to &lt;b&gt;, one of:
(clockwise from top left pixel)
rgbg Red-green-blue-green
gbgr Green-blue-green-red
grgb Green-red-green-blue
bgrg Blue-green-red-green
none RGB-RGB-RGB-RGB
Default is none or device-specific.
</pre>
<h2>Video stream processing (Experimental)</h2>
<p>If a sequence of frames represents a video stream, then, in addition to
producing a single output image, ALE can also produce one or more sequences of
processed frames, corresponding to one or more occurrences of the
<code>--visp</code> option. This option has its own associated scaling option,
as well as an option to show excluded regions as dimmed wherever possible.</p>
<pre>
--visp &lt;args&gt; Process a video sequence.
&lt;args&gt; are:
&lt;chain&gt; &lt;stabilization-type&gt; &lt;prefix&gt; &lt;suffix&gt;
&lt;chain&gt; is an incremental rendering chain.
&lt;stabilization-type&gt; is one of:
ma:&lt;x&gt; Moving average over 2*&lt;x&gt; + 1 frames
sf:&lt;x&gt; Stabilize to single frame number &lt;x&gt;
identity Same as ma:0
&lt;prefix&gt; is an output file prefix
&lt;suffix&gt; is an output file suffix
--visp-scale=&lt;x&gt; Use scale &lt;x&gt; for VISP output. (default is 1.0)
--exshow For single-invariant chains, show --ex regions dimmed.
</pre>
<h3>Video stream processing example</h3>
<p>To mimic the behavior of repeated applications of the 0.6.0
<code>--replace</code> option over a sequence of frames, the following
<code>--visp</code> option could be used.
<pre>
--visp last:nex:triangle:2 sf:0 frame .jpg
</pre>
<p>For better filtering, the following option could be used instead:
<pre>
--visp last:nex:sinc*lanc:6 sf:0 frame .jpg
</pre>
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,91 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: Point Spread Functions</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head><body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Point Spread Functions</h1>
<p>The ALE Irani-Peleg renderer uses a point-spread function to model the optical
and electronic properties of the capture device used. The PSF can be specified
in terms of one linear and one non-linear component.
<h3>PSF specification</h3>
<p>The PSF can be explicitly specified by using one or both of the psf options.
<pre>
--lpsf &lt;p> Set linear colorspace point-spread function to &lt;p>
--nlpsf &lt;p> Set non-linear colorspace point-spread function to &lt;p>
</pre>
Available explicit point-spread functions are as follows:
<pre>
box=&lt;d> Set the PSF to a box filter with diameter &lt;d>.
circle=&lt;d> Set the PSF to a circular filter with diameter &lt;d>.
stdin Specify a custom filter at runtime.
stdin_vg stdin with vertically-oriented gaps after every 8th pixel.
&lt;p>+&lt;p> Summation of two functions
&lt;p>^&lt;p> Convolution of two functions.
&lt;n>*&lt;p> Multiplication by a scalar &lt;n>.
</pre>
If a device is known to ALE, then its PSF can be implicitly set with the
<code>--device</code> option. (See the <a href="../../device/">device</a> page
for more information.) If a device is not specified, then the default linear
PSF component is <code>box=1</code>. The non-linear PSF component is disabled
by default.
<h3>Determining the PSF</h3>
<p>The PSF can be approximated based on images of known scenes. The ALE source
distribution includes an experimental script that numerically approximates the
PSF in this way (<code>d2/render/psf/ale-psf-calibrate</code>). Other, more
efficient methods for approximating the PSF are likely possible, however.
<br>
<hr>
<i>Copyright 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,69 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual: User Interfaces</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TABLE.inline { padding-right: 300; clear: left}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: none; padding-right: 300; clear: left}
BLOCKQUOTE {padding-right: 400 }
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE User Interfaces</h1>
<p>ALE currently supports two user interface types. The traditional interface
is the stream interface, which produces only printing characters and
whitespace. If ALE is compiled with IOCTL support, additional information can
be provided through the tty interface, which is default.
<pre>
--ui=&lt;type&gt; Set user interface to &lt;type&gt;, one of:
stream
tty [default]
</pre>
<br>
<hr>
<i>Copyright 2005 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p>Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,101 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE Technical Description</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TD {padding-left: 0; padding-right: 0; border-width: 0}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: 640; clear: left}
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
5393119533<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE Technical Description</h1>
<h2>Versions</h2>
<ul>
<li><a href="../download/ale-0.7.x-tech/">ALE 0.7.x/0.8.x Technical Description</a>
<li><a href="../download/ale-0.6.0-tech/">ALE 0.6.0 Technical Description</a>
<li><a href="../download/ale-0.5.1-tech/">ALE 0.5.1 Technical Description</a>
</ul>
<!-- SiteSearch Google -->
<form method="get" action="http://www.google.com/custom" target="_top">
<table border="0" bgcolor="#ffffff">
<tr><td nowrap="nowrap" valign="top" align="left" height="32">
<a href="http://www.google.com/">
<img src="http://www.google.com/logos/Logo_25wht.gif"
border="0" alt="Google"></img></a>
<br/>
<input type="hidden" name="domains" value="auricle.dyndns.org"></input>
<input type="text" name="q" size="10" maxlength="255" value=""></input>
<input type="submit" name="sa" value="Search"></input>
</td></tr>
<tr>
<td nowrap="nowrap">
<table>
<tr>
<td>
<input type="radio" name="sitesearch" value=""></input>
<font size="-1" color="#000000">Web</font>
</td>
<td>
<input type="radio" name="sitesearch" value="auricle.dyndns.org" checked="checked"></input>
<font size="-1" color="#000000">auricle.dyndns.org</font>
</td>
</tr>
</table>
<input type="hidden" name="client" value="pub-7647822213611745"></input>
<input type="hidden" name="forid" value="1"></input>
<input type="hidden" name="channel" value="5989625442"></input>
<input type="hidden" name="ie" value="ISO-8859-1"></input>
<input type="hidden" name="oe" value="ISO-8859-1"></input>
<input type="hidden" name="cof" value="GALT:#008000;GL:1;DIV:#336699;VLC:663399;AH:center;BGC:FFFFFF;LBGC:336699;ALC:0000FF;LC:0000FF;T:000000;GFNT:0000FF;GIMP:0000FF;FORID:1;"></input>
<input type="hidden" name="hl" value="en"></input>
</td></tr></table>
</form>
<!-- SiteSearch Google -->
<br clear=both>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p class="footer">Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>

View File

@@ -0,0 +1,104 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>ALE User Manual</title>
<style type="text/css">
TABLE.ba { max-width: 678; text-align: center; padding-bottom: 15; padding-top: 5}
TD {padding-left: 0; padding-right: 0; border-width: 0}
TD.text_table {padding-left: 2; padding-right: 2; border-width: 1}
H2 {clear: left}
P {max-width: 640; clear: left}
LI {max-width: 640; clear: left}
P.footer {max-width: none; width: auto; padding-left: 0}
P.header {max-width: none; width: auto; padding-left: 0}
HR.main {max-width: 640; clear: left; padding-left: 0; margin-left: 0}
HR.footer {clear: both}
</style>
</head>
<body>
<table align=right valign=top width=160>
<td valign=top height=600 width=160>
<a href="http://auricle.dyndns.org/ALE/">
<big>ALE</big>
<br>
Image Processing Software
<br>
<br>
<small>Deblurring, Anti-aliasing, and Superresolution.</small></a>
<br><br>
<big>
Local Operation
</big>
<hr>
localhost<br>
2684415918<br>
</table>
<p><b>[ <a href="../">Up</a> ]</b></p>
<h1>ALE User Manual</h1>
<h2>Versions</h2>
<ul>
<li><a href="../download/ale-0.8.x-user/">ALE 0.8.x User Manual</a>
<li><a href="../download/ale-0.7.x-user/">ALE 0.7.x User Manual</a>
<li><a href="../download/ale-0.6.0-user/">ALE 0.6.0 User Manual</a>
<li><a href="../download/ale-0.5.1-user/">ALE 0.5.1 User Manual</a>
</ul>
<!-- SiteSearch Google -->
<form method="get" action="http://www.google.com/custom" target="_top">
<table border="0" bgcolor="#ffffff">
<tr><td nowrap="nowrap" valign="top" align="left" height="32">
<a href="http://www.google.com/">
<img src="http://www.google.com/logos/Logo_25wht.gif"
border="0" alt="Google"></img></a>
<br/>
<input type="hidden" name="domains" value="auricle.dyndns.org"></input>
<input type="text" name="q" size="10" maxlength="255" value=""></input>
<input type="submit" name="sa" value="Search"></input>
</td></tr>
<tr>
<td nowrap="nowrap">
<table>
<tr>
<td>
<input type="radio" name="sitesearch" value=""></input>
<font size="-1" color="#000000">Web</font>
</td>
<td>
<input type="radio" name="sitesearch" value="auricle.dyndns.org" checked="checked"></input>
<font size="-1" color="#000000">auricle.dyndns.org</font>
</td>
</tr>
</table>
<input type="hidden" name="client" value="pub-7647822213611745"></input>
<input type="hidden" name="forid" value="1"></input>
<input type="hidden" name="channel" value="2180835395"></input>
<input type="hidden" name="ie" value="ISO-8859-1"></input>
<input type="hidden" name="oe" value="ISO-8859-1"></input>
<input type="hidden" name="cof" value="GALT:#008000;GL:1;DIV:#336699;VLC:663399;AH:center;BGC:FFFFFF;LBGC:336699;ALC:0000FF;LC:0000FF;T:000000;GFNT:0000FF;GIMP:0000FF;FORID:1;"></input>
<input type="hidden" name="hl" value="en"></input>
</td></tr></table>
</form>
<!-- SiteSearch Google -->
<br clear=both>
<hr>
<i>Copyright 2002, 2003, 2004 <a href="mailto:dhilvert@auricle.dyndns.org">David Hilvert</a></i>
<p class="footer">Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
</body>
</html>