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,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>