The specifics of EOIR sensor design is often a black box to many beyond seasoned remote sensing engineers. STK's
EOIR capability has a lot of radiometric settings that affect noise and the raw sensor output, so let's break down what it all means and perform a validation experiment.
Scenario setup
You can jump right into STK and create a dark sensor image to understand how noise affects the raw sensor output. Use the following steps to set up your scenario:
- Create a satellite using the Define Properties; you can then click OK to save the properties with the default settings.
- Place (insert) a sensor on the satellite using the Define Properties.
- Under Basic > Definition, set the Sensor Type to EOIR.
- Go to the Pointing page and orient the sensor to zenith (Az = 0 deg, El = -90 deg).
- Back on the Definition page, in the Spatial tab, set the sensor horizontal and vertical half angles to something small, like 0.5 deg.
- Select the Radiometric tab and set Input to Low Level. For simplicity of calculations, set the read noise to 10 electrons/pixel, the dark current rate to 1000 electrons/s/pixel, and the integration time to 1000 msec.
Quantum efficiency and detector fill factor
What does this mean? When light enters a sensor, the incoming photons strike a photosensitive pixel. The pixel may convert that photon into an electron that is stored in a well. The rate at which this occurs is not 100% (1.0 efficiency). The probability that a photon will be converted into an electron by the pixel is known as Quantum Efficiency (QE). In STK, the default QE value is 1.0, but for a real sensor, this value is somewhat less than 1. Additionally, not all of the pixel is photosensitive because of supporting hardware involved In STK; this is known as the detector fill factor. So, the overall probability that an incoming photon will convert into an electron is given by:
P(electron) = QE * Detector Fill Factor
Read noise and dark current rate
In this case, you are simulating a sensor that perfectly converts all incoming photons into a corresponding electron. Now you need to consider noise. The sensor will accumulate electrons over the specified integration time. You can compare this to your shutter speed on a personal camera. The longer the integration time (or shutter speed), the more light you can collect. More light allows you to better resolve dark images, but it also introduces much more noise. In the absence of external input, where does this noise come from? The hardware creates electrical and thermal noise that is converted into electrons. As you integrate, the dark current rate accumulates electrons as random noise. This is why highly precise instruments cool their hardware to nearly absolute zero! This way, you can eliminate as much thermal noise as possible. Careful engineering design can also minimize electrical noise. Finally, as your hardware reads out each pixel to count the electron signal, some noise is unavoidably introduced as well. This is the read noise, and it is a constant hit to your noise input independent of integration time. STK models the noise as a Poisson distribution with parameter:
lambda = Read Noise + (Dark Current Rate * Integration Time)
In this case, the Poisson parameter is 10 electrons + (1000 electrons/sec * 1 sec) = 1010 electrons. You can approximate large Poisson parameters as a Gaussian distribution with mean lambda and variance lambda, so you can approximate the noise distribution as N(1010, 1010), which gives the standard deviation sqrt(1010) = 31.7805. You can verify this in STK.
Dark image validation
Here's how you can validate this dark noise Poisson distribution in EOIR. Point the sensor at a dark portion of the sky that has no stars, in order to get zero external radiometric input, so that noise is the only factor. Generate the EOIR scene and step forward or backward in your animation until the scene has no stars in it. You can doubly verify that there is no input by switching the Processing Level parameter in your sensor properties (Radiometric tab) to Radiometric Input and seeing that the EOIR scene is totally dark, meaning there is zero external input. When switching the Processing Level back to Sensor Output, the scene should simply look like static:
Save the raw sensor data. This data records the output electron counts for each pixel in a space-delimited text file. Plot the data in the software of your choice and compare it to a normal distribution. Your data will look similar to this:
Notice immediately that the standard deviation is very similar to what you had calculated earlier with the Poisson distribution, but the mean noise is now centered at zero. Even more, there are negative electron counts from the noise! What is happening?
Bias
EOIR sensors can only store a limited number of electrons in their wells. In order to maximize their capacity (and therefore dynamic range, more on that later), sensor hardware will subtract out the nominal noise electrons as a bias before it is written to memory. STK takes the Poisson parameter as the nominal noise electrons and subtracts that from the signal. So, to get it back to what it truly was, you would need to shift the distribution up by the Poisson parameter. So, since adding a scalar to all data points does not change the standard deviation, the bias-added distribution very closely matches the original predicted N(1010, 1010) distribution, and there are no more negative numbers.
Quantization and saturation
It's time to add another layer of realism. You may have noticed that the raw data output above has electron counts that are floating point numbers. This, along with negative electron counts, are not physically realistic. As discussed in the last section, negative numbers arise from bias subtraction. Additionally, the floating point numbers arise as part of the simulation process when simulating stochastic models for photons. Quantization helps add another layer of realism by simulating the conversion of an analog electron signal into a digital output.
When electrons are read out by sensor hardware, the exact number of electrons is generally too large to be written to hardware. So quantization happens. STK's Analog to Digital Conversion section simulates this. Full-Well capacity defines the total number of electrons that a single pixel can hold. You can couple this with a Quantization Step Size (QSS) or simply set the step size to noise. The QSS gives how many electrons are read before the count is incremented by 1. So, for a QSS of 100, every 1000 electrons read will translate to an output count of 10. If you select noise, then the noise step serves as the QSS (in our validation example, 1010 electrons).
Instead of Full-Well Capacity, you can use bit depth instead. This is more common for digital converters, since the output count is often constrained to a number of bits. A digital bit-depth of 8 means that STK can store 2^8, or 256, discrete values. Once again, the QSS or noise step size will determine how many electrons can be read out. For example, if the QSS is 100 electrons, then the maximum number of electrons that EOIR can account for is 25,600, or
bit depth * QSS.
What happens if the electron count is negative, or if the number of electrons exceeds the digital output bit depth available? If the electron count is negative, then the value recorded is simply 0 electrons. If the number electrons exceeds the bit depth, then EOIR considers the detector saturated. EOIR will only simulate saturation if you select the Simulate Saturation check box at the top of the Radiometric tab. Otherwise, the EOIR will allow the output to exceed the specified bit depth. If you are simulating saturation, then the maximum output count will be equal to 2^(bit depth), because STK cannot store larger values.
Now return to STK. Again under the Radiometric tab, set the Analog to Digital Conversion shortcut menu to Bit-Depth And QSS, set the Digital Bit-Depth to 8 bits, and set the Quantization Step Size to 1 electron per count. For now, this ensures that EOIR still reports out electrons counts as 'true' without any step sizes.
Save the new raw data report and graph a new histogram. This example demonstrates that there are no more negative values; they have been set to 0, and the positive side of the electron count looks the same:
Light image validation
Now validate an EOIR image taken with a uniform nonzero radiometric input. In the sensor properties Basic > Pointing page, point the sensor to nadir (Az = 0 deg, El = 90 deg). Animate your scenario to a point where the sensor is being backlit by the sun. Placing the satellite over the ocean tends to generate a more uniform image as well.
Once again, save the synthetic scene and plot a histogram:
The incoming radiometric input coming off the ocean surface is also modeled as a Poisson distribution. Looking at the Gaussian fit distribution, you can deduce that the Poisson parameter is approximately 95056754.16 in this example. Once again, this verifies that the calculated standard deviation is very close to what to expect from the Gaussian approximation, where std = sqrt(95056754.16) = 9749.71.
Also notice that the counts are much larger than 256, the maximum value allowed by your setting of digital bit-depth of 8. This is because you are not simulating saturation. Return to the Radiometric tab in Basic > Definition and now select the Simulate Saturation check box. Instantly, the synthetic scene becomes completely uniform.
For the last time, save the sensor scene image and plot the histogram.
Immediately it is clear that the entire scene is saturated. There are well over 256 electrons in each pixel, but the digital output is limited to 256, and every pixel reports the maximum count. Because of this saturation, EOIR cannot store additional information. For a fixed-sensor architecture, you can fix this by shortening the integration time so that fewer photons strike the sensor.
NEI, SEI, and dynamic range
While making all these changes in the Radiometric tab, you may have noticed that the numbers for Dynamic Range, NEI, and SEI are constantly changing at the bottom of the Radiometric tab when you apply your changes. What do those mean? NEI and SEI represent the sensor detection floor and ceiling, respectively. The detector will not detect an incoming irradiance below the NEI because noise overpowers the input. This is particularly important for missions requiring high sensitivity, like tracking dim stars. You will need to drop the noise low enough that you can detect dim inputs. On the other hand, incoming irradiance above the SEI will saturate the sensor. This comes into play when tracking particularly bright objects like the sun. Above the SEI, you will blow out your sensor scene and may even cause physical damage to the detector if the irradiance is high enough. Finally, dynamic range is a measure of the ratio between SEI and NEI. This refers to how far the brightest parts of your image differ from the darkest parts of your image. If you have heard of High Dynamic Range (HDR) monitors, TVs, or cameras, these items can offer greater perception to the final image. The farther apart your NEI and SEI, the higher dynamic range, so you can capture a greater range of irradiance.
Often, the minutia of sensor hardware, like their noise parameters, QE, detector fill factor, and analog to digital conversion, can be closely guarded trade secrets. Since the NEI and SEI are functions of all these inputs, sensor manufacturers will often release just NEI and SEI as public datasheet values. You can still make use of these values in STK for sensor simulation by switching the Input back to High Level. These NEI and SEI values become functions of integration time, and STK will simulate with the same level of fidelity as if you had all of the low-level parameters available.
Final notes
So, what does this all mean? These techniques are commonly used to calibrate real sensors and match designs between an operational system and EOIR. Comparing a sensor output to a known point source or flat field image will assist greatly with sensor calibration both in simulation and in operation. STK can help you accomplish this through the use of texture maps. You can create a flat field or point source in STK to validate your designs, or you can use this functionality to design and evaluate your own sensor. Hopefully this has demystified the world of EOIR just a little bit more. Happy simulating!
Do you want to know how to use texture maps? Check out this FAQ:
Loading EOIR Texture Maps From NASA's Earthdata.
