Table Of ContentImplementation of intensity ratio change and line-of-sight rate change
algorithms for imaging infrared trackers
C.R. Viau,
Tactical Technologies Inc., Ottawa, Canada
ABSTRACT
The use of the intensity change and line-of-sight (LOS) change concepts have previously been documented in the open-
literature as techniques used by non-imaging infrared (IR) seekers to reject expendable IR countermeasures (IRCM).
The purpose of this project was to implement IR counter-countermeasure (IRCCM) algorithms based on target intensity
and kinematic behavior for a generic imaging IR (IIR) seeker model with the underlying goal of obtaining a better
understanding of how expendable IRCM can be used to defeat the latest generation of seekers.
The report describes the Intensity Ratio Change (IRC) and LOS Rate Change (LRC) discrimination techniques. The
algorithms and the seeker model are implemented in a physics-based simulation product called Tactical Engagement
Simulation Software (TESS™). TESS is developed in the MATLAB®/Simulink® environment and is a suite of RF/IR
missile software simulators used to evaluate and analyze the effectiveness of countermeasures against various classes of
guided threats.
The investigation evaluates the algorithm and tests their robustness by presenting the results of batch simulation runs of
surface-to-air (SAM) and air-to-air (AAM) IIR missiles engaging a non-maneuvering target platform equipped with
expendable IRCM as self-protection. The report discusses how varying critical parameters such track memory time,
ratio thresholds and hold time can influence the outcome of an engagement.
Keywords: Countermeasures, IRCM, flares, imaging IR seeker, IRCCM, modeling, simulation, intensity ratio, LOS
rate change
1. BACKGROUND
Military and civilian aircraft operating in conflict areas continuously face the threat of IR-guided missiles. The latest
generation of IR seekers uses imaging technologies to produce a complete picture of the IR scene and provides
significant capability enhancements over previous generations. Although IIR systems are more commonly found in air-
to-air and anti-ship missile systems, they could potentially find their way into Man Portable Air Defense Systems
(MANPADS) and result in an even greater threat to low flying aircraft.
There are typically two approaches to airborne platform protection from IR-guided missiles. The first approach is to use
expendable IRCM such as flares and towed decoys to prevent the missile seeker from locking on and lure the missile
away from the target platform. The second approach is to use on-board jamming such as Directed Infrared
Countermeasure (DIRCM) systems to introduce error signals into the missile seeker’s guidance system or physically
damage the seeker head. While each has its advantages and disadvantages, the majority of research and development
efforts in this area in the last decade have focused on laser-based DIRCM technologies. There are several major ongoing
defense programs1 aimed at developing and fielding more affordable equipment to better protect the various types
(fighter, helicopters and large transport) of aircraft. DIRCM systems have demonstrated their effectiveness with
helicopter and transport aircraft, however flares continue to be the only IRCM available for fighter aircraft2. According
to the same source, even the latest fighter generation will only depend on flares to protect them from the various
generations of IR-guided threat.
Flares have long been the primary IRCM to protect aircraft and have kept pace with the evolving threat. Several open-
literature sources3,4,5,6 have discussed the development and advancements in pyrotechnic and optical countermeasures.
However, it remains unclear how the expendable IRCM, in its current form, can effectively protect airborne platforms
from the latest generation of IR-guided missiles. Open-literature sources2,3 suggest that IIR technologies may have
rendered all type of point target flares unsuitable for airborne platform protection. One study7 proposed the use of
Infrared Imaging Systems: Design, Analysis, Modeling, and Testing XXIII, edited by Gerald C. Holst, Keith A. Krapels,
Proc. of SPIE Vol. 8355, 83550P · © 2012 SPIE · CCC code: 0277-786X/12/$18 · doi: 10.1117/12.918482
Proc. of SPIE Vol. 8355 83550P-1
Downloaded from SPIE Digital Library on 24 May 2012 to 99.246.151.108. Terms of Use: http://spiedl.org/terms
distributed flares as mean to protect fast jets and demonstrated using software simulations that distributed flares could be
effective as a last line of defense against IIR missiles. The Electronic Warfare (EW) and specifically IRCM community
must continuously evolve their understanding of the threat in order to exploit its weaknesses. One effective way to gain
this knowledge and insight is to use high-fidelity, physics-based simulation tools and hardware-in-the-loop simulators to
analyze the non-linear and stochastic interactions between various systems and their environment.
The typical challenge for any form of tracker is to identify and extract targets with specific temporal, spectral and/or
physical characteristics from a cluttered background and maintain track until end game. When a target anticipates or
suspects it is being tracked, it may attempt to break-lock from the tracker by possibly performing evasive maneuvers
and/or introducing false targets in its surrounding space to confuse and hopefully seduce the tracker. The tracker’s
ability to resist and reject the target’s attempt to break-lock is referred to as counter-countermeasures (CCM) response.
Several CCM algorithms used by non-imaging and pseudo-imaging seekers have been described in the open-literature.
Montgomery et al8 documented a multicolor IR signature measurement experiment of SAMs and AAMs. Oh et al9,10
proposed two IRCM rejection methods based on (i) two-color signature cancelation algorithm for a rosette tracker and
(ii) a two-color signature ratio comparison for a crossed-array tracker. Jahng et al11,12 proposed a CCM concept based on
the K-means algorithms and an iterative self-organizing data analysis algorithm for rosette trackers. Forrai et al13
described a simulation environment used to assess IRCM effectiveness. They discussed three methods used to reject
IRCM in non-imaging seekers: (i) two-color discrimination, (ii) intensity rise time discrimination and (iii) LOS rate
discrimination.
With the advancements of microprocessors, more sophisticated and complex algorithms based on pattern recognition,
neural networks and artificial intelligence were developed and implemented in IIR seekers to extract target and
background features. A wealth of information on proposed image processing14, target tracking15, filtering16 and data
fusion17 algorithms with potential applications to IIR systems is available in the published literature. One can only
assume that some forms of these algorithms are actually used in fielded systems.
The purpose of this project was to implement IRCCM algorithms based on target intensity and kinematic behavior for a
generic IIR seeker model. The seeker model and the algorithms had to be developed in the MATLAB environment and
had to be customizable using tunable parameters. The algorithms had to be open, easily verifiable and based on
published literature. The design was implemented in TESS to support Electronic Warfare Operational Support (EWOS),
development of autonomous national countermeasures expertise, development of effective self-protection tactics and
countermeasure programs for improved platform survivability, test and evaluation of countermeasures in hardware-in-
the-loop systems and training of operators in countermeasures (electronic attack) and counter-countermeasures
(electronic protection) tactics.
The report discusses the Intensity Ratio Change (IRC) and Line-of-sight Rate Change (LRC) algorithms and evaluates
their robustness through batch run simulations. The IRC and LRC algorithms can work together or individually and both
use a common track database which holds historical data on each object in the sensor’s field of view. The IRC algorithm
compares the intensity of individual objects to the historical average of a reference object to identify false targets. The
LRC algorithm compares the motion of individual objects with respect to the reference object in order to identify false
targets.
2. DESCRIPTION OF THE ALGORITHMS
Forrai et al13 presented a generic IRCM assessment model and divided their generic non-imaging seeker into three
distinct modules: flare detection, CCM tracking and normal tracking. The first two modules are described in detail in
their report and summarized here. The flare detection module employs one or all three of the following discrimination
techniques: (i) two-color target signature, (ii) intensity rise time and (iii) LOS rate change. When the CCM tracking
module is enabled, the seeker uses one of four ways to respond to the flare detection: (i) rate hold, (ii) angle hold, (iii)
rate bias or (iv) angle bias.
The algorithms implemented in the generic IIR seeker and discussed in this report are variants of the intensity rise time
and LOS rate change algorithms presented by Forrai et al.
The IRC and LRC are embedded in a MATLAB function block inside a Simulink subsystem. The output of the IR scene
generator is converted to a binary pixel map using a threshold function. A Simulink Blob Analysis block operates on
this binary pixel array to regroup adjacent pixels into “blobs” or objects. The Blob Analysis block computes the area,
Proc. of SPIE Vol. 8355 83550P-2
Downloaded from SPIE Digital Library on 24 May 2012 to 99.246.151.108. Terms of Use: http://spiedl.org/terms
centroid and bounding box of each detected object. It also provides a label array correlating each pixel to an object.
These parameters are used by the Target Discrimination and IRCCM Logic function to perform the target tracking and
counter-countermeasure functionality of the generic seeker model. Other CCM input/output parameters of interest are
listed in Table 1.
Table 1- IRCCM Logic Input/Output List
Inputs Outputs
Simulation time Centroid (units of pixels) of the tracked object
Simulation time-step Total power of the tracked object
IRCCM memory time Peak power of the tracked object
Intensity ratio change threshold Intensity ratio of all detected object
LOS rate change threshold LOS rate change value of all detected object
Flare hold time Flare detected flag for each of the detected object
The top level diagram of the Target Discrimination and IRCCM Logic function is illustrated in Figure 1.
12 1JGLG 12 G!LC Oh bGtGLGU( vqqeqiseiqec
bOMGL L
qeteqec GU9PIG
LGUJ S U
Figure 1- Top Level CCM Logic Diagram
The simulation run starts with the seeker in track mode and assumes that either an operator or target identification
algorithm successfully identified the desired target. During the initialization portion of the simulation, the target
tracking module sets the initial target as the reference object. At every time-step, the target tracking logic attempts to re-
identify the reference object in the sensor's field of view. Once a reference object is identified, the algorithm adds all the
other detected objects in the sensor's field of view to the track database. The track database stores the following
information for each of the detected objects:
Table 2- Track database
Timestamp Object Horizontal Vertical Horizontal Vertical Predicted Predicted Total Peak
Size Position Position Velocity Velocity Horizontal Vertical Power Power
Position Position
The Simulink Blob Analysis block outputs all the necessary information to build the track database. An issue that was
encountered during the development was object identification numbers (IDs) did not always match from one time-step to
the next. The Blob Analysis block determines IDs based on the position of the object in the pixel array. As objects
moved around in the field of view (i.e. flare following a ballistic trajectory behind the aircraft), IDs were sometimes
reset in the middle of a simulation run resulting in the loss of historical data for that object. It was therefore necessary to
implement a track database and additional logic to match objects to existing tracks in order to preserve the historical
data.
During this step, detected objects are either matched to existing tracks or added as new tracks. Once this process is
complete, any track that was not updated is removed from the database. If one of the CCM methods is enabled, the
CCM algorithm looks at the track database to analyze the historical behavior of each track as compared to the reference
track. Objects that present flare-like characteristics are identified and removed from the “trackable” list of objects.
Proc. of SPIE Vol. 8355 83550P-3
Downloaded from SPIE Digital Library on 24 May 2012 to 99.246.151.108. Terms of Use: http://spiedl.org/terms
From the remaining list, the objects with the characteristics that best match the user-defined tracking method become the
primary target. The following sections describe some of the processes in more detail.
2.1 Identifying the Reference Object
A summary of the process to identify the reference object in the sensor’s field of view is illustrated in Figure 2.
Joe o
bo
q 29UC6
eA9In9eq
Figure 2 – Reference object logic diagram
At every time-step, the target tracking algorithm must first identify a reference object with which to compare all other
objects in the field of view. The algorithm looks at each object’s centroid (in units of pixels) and compares it to the
reference object’s predicted position from the previous time-step. If the difference between the predicted and actual
position is within five (5) times its size, the object is identified as a possible match. Once all objects have been
evaluated, the object with smallest separation distance (closest neighbor) is formally identified as the reference object.
2.2 Updating the Track Database
A summary of the process used to update the track database is illustrated in Figure 3.
Figure 3- Track database update logic diagram
The process update the track database is very similar to finding the reference object. The centroid of the reference object
is used as a reference point to compare the predicted and actual positions of each object in the field of view. If the
difference between the predicted and actual position is less than one (1) times the object size, the track is identified as a
potential match. After comparing the object to all the existing tracks, the algorithm assigns the object to the best match.
If no match is found, a new track is added to the database. The process is repeated until all objects in the field of view
have been evaluated.
After all the objects have been compared to the existing track database, the algorithm removes tracks that were not
updated in the last five (5) time-steps. The lifespan of idle tracks in the database was varied during the development and
Proc. of SPIE Vol. 8355 83550P-4
Downloaded from SPIE Digital Library on 24 May 2012 to 99.246.151.108. Terms of Use: http://spiedl.org/terms
five (5) time-steps seemed to provide the best results. The track database is currently limited to fifty (50) tracks and a
longer lifespan means that idle tracks could potentially use valuable memory space. It was also noted that a longer
lifespan resulted in matching of unrelated tracks. One observed scenario resulting in unrelated track matching occurred
when a series of flares were deployed at an interval in the same orientation. Since the seeker attempts to keep the target
platform in the center of the field of view, every deployed flare travelled the same trajectory. As new flares appeared in
the field of view, the algorithm matched them to idle tracks (i.e. flares no longer in the field of view) instead of adding
them as new tracks.
2.3 Track Rejection Based on the Selected CCM
A summary of the process used to reject tracks based on the selected CCM method is illustrated in Figure 4.
Cobr
bomeL 0 Cob
C0UJbSLS
vJo, o
W649tL
E HOIq
Figure 4- Track rejection logic diagram
During the initialization subroutine, the algorithm initializes three arrays: (1) IRC which is a binary array indicating
which object(s) have been identified as flares by the IRC algorithm; (2) LRC which is binary array indicating which
object(s) have been identified as flares by the LRC algorithm; and (3) flaredb which is binary array indicating which
object(s) have been identified as flares by either the IRC or LRC algorithms. At every time-step the algorithm evaluates
every track to identify which ones demonstrate flare-like behavior. It first determines which CCM method is selected
and whether or not the user-defined activation delay time is exceeded. If the IRC method is enabled, then once the IRC
activation delay has expired the module computes the intensity ratio of the ith track for the current time-step (N) by
( )
dividing its detected power (PN(i)) by the reference object’s average power Po .
N
P (i)
IRCN(i)= PN o (1)
N
and
N
∑Po
K (2)
Po = K=N−J
N J
The average power of the reference object is a discrete running average over a user-defined number of time-step (J).
Depending on the selected target tracking technique, the algorithm uses either the Peak or Total Power values from the
track database to compute the average power.
Proc. of SPIE Vol. 8355 83550P-5
Downloaded from SPIE Digital Library on 24 May 2012 to 99.246.151.108. Terms of Use: http://spiedl.org/terms
Similarly if the LRC method is enabled, then once the LRC activation delay has expired the module computes the
average azimuth (θ&) and elevation (φ&) LOS rate change of the ith track for the current time-step (N) using the following
equations:
N
∑θ (i)−θ (i)
K K−1 (3)
θ&(i) = K=N−J
J ⋅τ
and
N
∑φ& (i)−φ& (i)
K K−1 (4)
φ&(i) = K=N−J
J ⋅τ
θ& and φ& are discrete running averages over a user-defined number of time-steps (J). τ represents the simulation time-
step duration.
Once the IRC and LRC values are determined for each track, the algorithm compares these values to the user-defined
thresholds. If the values exceed the thresholds, the tracks are identified as potential flares. A track retains its “flare”
status for the user-defined Flare Hold Time. The purpose of the Flare Hold Time is to prevent the track status from
oscillating.
Finally, the Target Selection module applies the selected target tracking technique to all the objects not labeled as
potential flares.
3. EXPERIMENTAL SETUP
3.1 Purpose
The purpose of this study was to implement and evaluate the robustness of the IRC and LRC countermeasure rejection
algorithms in a generic IIR seeker and determine the impact of the various tunable parameters on the overall
performance. The tunable parameters were:
i. Intensity ratio change (IRC) threshold
ii. IRCCM memory time
iii. Flare hold time
iv. LOS rate change (LRC) thresholds (azimuth, elevation)
3.2 Simulation Tool
The study was conducted using SAAM(IIR), a member of TTI’s Tactical Engagement Simulation Software (TESS™).
TESS is an open physics-based suite of tools that enables its users to analyze, evaluate, understand and optimize IR/RF
countermeasure effectiveness against various classes of surface-to-air, air-to-air, anti-ship and anti-tank guided threats.
The IRC and LRC algorithms, as well as the simulation tools are implemented in MATLAB, Simulink and various other
Mathworks® toolboxes. Target, countermeasure, threat systems and engagement libraries are stored in a front-end
database with a programmable Monte Carlo batch running capability.
For the purpose of this study, the background clutter and sensor noise were intentionally suppressed from the IR scene in
order to isolate the algorithms from external factors.
Proc. of SPIE Vol. 8355 83550P-6
Downloaded from SPIE Digital Library on 24 May 2012 to 99.246.151.108. Terms of Use: http://spiedl.org/terms
3.3 Engagement Geometry
The algorithms were evaluated against a generic fighter deploying expendable IRCM as self-protection. The SAM
engagements were in a “look up” geometry while the AAM engagements were in a “look down” geometry. As there is
no background clutter included for the purpose of this investigation, the main reason for evaluating the “look up” and
“look down” geometry was to understand the impact of the flare’s ballistic trajectory on the algorithms.
As discussed in the Background section, IIR seekers probably use some form of pattern recognition algorithms where
features such as size and aspect ratio are used to discriminate true targets from background clutter and decoys. In the
initial stages of engagements where target and flares may appear as just a few pixels and features may not be easily
extracted, alternative algorithms may be required. The following simulation runs are intended to simulation this specific
scenario. The initial threat range was set to three thousand meters. The azimuth angle of arrival was varied between 0°
and 360° (with 10° increments) while the elevation was varied between -50° and 50° with respect to the target platform
longitudinal axis. The other relevant parameters are tabulated in the following sections.
3.4 Subsystem Parameters
There are over one hundred and twenty (120) parameters and lookup tables characterizing the size, shape, position,
motion and IR signature of the IIR seeker, airframe, launch platform, target platform, flares and the environment. Table
3 summarizes the relevant parameters for the study.
Table 3 - Subsystem Parameters
Threat System Target Platform Flares
Parameter Value Parameter Value Parameter Value
Servo 5 Hz Platform Type Fast Jet Approx. diameter 0.3 m
Bandwidths
Gimbal Limits 60 deg Length 14 m Growth time constant 0.1 sec
Field of View 4 deg Wing span 9 m Sustain time 4 sec
Detector Array 128x128 Velocity 250 m/s Decay time constant 3.5 sec
Detector 200 Hz Maneuver Time N/A Number of deployed 8
Sampling Rate flares
IRCCMs IRC / Orientation 4 x [135 -30]
LRC [az el] 4 x [-135 -30]
Length 1.45 m Timing [0.1 0.2 0.3 0.4] sec
Diameter 0.1 m
Wing Span 0.17 m
Mass 9.2 kg
Prop. Nav. Coef. 3
Max. 30 g
Acceleration
3.5 Measures of Effectiveness
The simulation computes a point of closest approach (miss distance) for every engagement. Based on user-defined
parameters, a probability of kill and survival are also generated. In this study, the primary measure of effectiveness was
the miss distance. It was assumed that if the miss distance was less than forty (40) meters at end game, the algorithm
had successfully rejected the flares and tracked the target platform.
3.6 Batch Run Simulations
3.6.1 IRC Algorithm Assessment
The IRC batch run (396 runs) was conducted to assess the performance of the IRC algorithm in SAM and AAM
engagements using the following set of parameters:
Proc. of SPIE Vol. 8355 83550P-7
Downloaded from SPIE Digital Library on 24 May 2012 to 99.246.151.108. Terms of Use: http://spiedl.org/terms
Table 4 - IRC Parameter Set
IRC Threshold 1.5
IRCCM Memory Time 1 sec
Flare Hold Time 0.3 sec
The results of the IRC tests are presented in Section 4.1. From these results, a focus region where the algorithm
produced mixed results was selected to evaluate the impact of the tunable parameters listed in Section 3.1. The focus
region is between 90° and 180° in azimuth and -30° and -10° in elevation.
3.6.2 LRC Algorithm Assessment
The LRC baseline batch run (396 runs) was conducted to assess the performance of the LRC algorithm in SAM and
AAM engagements using the following set of parameters:
Table 5 - LRC Parameter Set
LRC Threshold [Az El] [0.1 0.1] deg/s
IRCCM Memory Time 1 sec
Flare Hold Time 0.3 sec
The results of the LRC tests are presented in Section 4.2.
3.7 Combined IRC and LRC Algorithm Assessment
A combined IRC and LRC batch run (396 runs) was conducted to evaluate the combined performance of the two CCM
techniques against SAM and AAM threats. The parameter set for this batch run is listed in Table 6.
Table 6 – Combined IRC and LRC Parameter Set
IRC Threshold 1.1
LRC Threshold [Az El] [0.1 0.1] deg/s
IRCCM Memory Time 1 sec
Flare Hold Time 0.3 sec
The results of the IRC/LRC tests are presented in Section 4.3.
3.8 Tunable Parameters Assessment
Four (4) additional batch runs (400 runs each) were conducted in the focus region where at each of the forty (40)
different angles of arrival, ten (10) different IRC Threshold, LRC Threshold, IRCCM Memory Time and Flare Hold
Time values were used to assess the performance of the algorithm. The parameter set for these batch runs are list
Table 7 - Tunable Parameter List
Batch Run #1 Batch Run #2 Batch Run #3 Batch Run #4
Parameter IRC Threshold LRC Threshold IRCCM Memory Time Flare Hold Time
Parameter Sweep 0.1 < IRC < 2.1 0.05< LRC < 0.45 0.1 < MT < 2.1 0.1 < FHT < 2.1
The results of Tunable Parameter tests are presented in Section 4.4.
Proc. of SPIE Vol. 8355 83550P-8
Downloaded from SPIE Digital Library on 24 May 2012 to 99.246.151.108. Terms of Use: http://spiedl.org/terms
4. RESULTS AND DISCUSSION
4.1 IRC Algorithm Results
The results of the IRC batch runs are presented in Figure 5. The diamonds represent the threat initial launch position
with respect to the target platform. The blue diamonds indicate that the IRC algorithm successfully rejected the flares
while the red hollow diamonds indicate the algorithm was unable to reject the flares. A total of 396 runs were conducted
of which 377 (95%) were successful and 19 (5%) were not. Section 4.5 discusses further some of individual engagement
scenarios describes why the algorithms was unsuccessful on those areas.
Figure 5 - IRC results for SAM/AAM engagements
4.2 LRC Algorithm Results
The results of the LRC batch runs are presented in Figure 6. A total of 396 runs were conducted of which 329 (83%)
were successful and 67 (17%) were not.
Figure 6 - LRC results for SAM/AAM engagements
The results in Figure 6 demonstrate that the LRC algorithm appears to be effective at nearly all angles of arrival for the
exception of head-on SAM engagements (-20° to 20°) and tail-chase AAM engagements (150° to 200°). In those two
regions, the engagement geometry resulted in the initial flare deployment appearing to separate from the target platform
at a slower rate than the specified threshold. As a result, the algorithm did not reject the flares but instead used them as
true targets. This is shown by the oscillations of the track point (red trace) in Figure 7 (a) and (b). The yellow trace
represents the relative azimuth and elevation angles to the target while the blue traces are those of the flares. The
wandering track point between the various flares caused changes in commanded normal and lateral accelerations to the
Proc. of SPIE Vol. 8355 83550P-9
Downloaded from SPIE Digital Library on 24 May 2012 to 99.246.151.108. Terms of Use: http://spiedl.org/terms
missile body (Figure 7 c). It should also be noted that the seeker reacquired and settle briefly on the target platform
between 2 and 2.3 seconds but lost it again shortly after.
Figure 7 - Seeker Scopes: (a) Azimuth Track Point, (b) Elevation Track Point, and (c) Missile Body Acceleration
4.3 Combined IRC/LRC Results
The results of the combined IRC/LRC batch runs are presented in Figure 8. A total of 396 runs were conducted of which
388 (98%) were successful and 8 (2%) were not.
Figure 8- Combined IRC/LRC results for SAM/AAM engagements
4.4 Tunable Parameters
The results presented in Figure 9a suggest that as the IRC threshold increases, the number of “misses” increases and the
effectiveness of the algorithm decreases. This result was expected since the intensity of a flare typically rises quickly and
is much larger than that of an aircraft. Varying the threshold may also have an impact on how quickly a flare can be
identified. A larger threshold means that the flare has to get closer to its peak intensity before it exceeds the specified
IRC threshold. A threshold too close to unity may trigger a flare detection flag in certain engagement geometry because
of the high close-in velocity between the target and the threat.
Figure 9b illustrates that as the LRC threshold increases, the number of “misses” increases and the effectiveness of the
algorithm decreases. Again this is expected since, the higher the threshold, the “faster” a flare must separate from the
aircraft in order to trigger the flare detection flag. The simulation allows the azimuth and elevation LRC thresholds to be
set separately in order to be evaluated independently. The algorithm is dependent on the engagement range and
Proc. of SPIE Vol. 8355 83550P-10
Downloaded from SPIE Digital Library on 24 May 2012 to 99.246.151.108. Terms of Use: http://spiedl.org/terms
