Modifying motion control signals based on input video characteristics

BACKGROUND OF THE INVENTION

This invention relates to detection of motion of images represented by video pixels and other digital data.

One application of this invention is useful in connection withy digitally removing noise from video sequences that have been digitized from the analog domain in order to increase the efficiency of a digital video compression system. The invention also is useful for any other motion detection application that generates a motion control signal.

Some known temporal filters derive motion information from both luminance and chrominance separately, not taking advantage of the correlation between the two signals.

Prior art systems have failed to recognize the utility of a median filter operation in the motion detection path which is used to eliminate impulses not in the image domain but in the motion/temporal domain. This operation makes a recursive filter perform better by controlling the value of the coefficient that controls the recursive time constant of the filter itself.

There are known temporal noise reduction systems that use motion estimation techniques instead of motion detection techniques. However, the motion estimation process is complex and does not fully guarantee the elimination of noise, just reduction.

Further limitations and disadvantages of conventional and traditional approaches will become apparent to one of skill in the art, through comparison of such systems with the present invention as set forth in the remainder of the present application with reference to the drawings.

BRIEF SUMMARY OF THE INVENTION

One apparatus embodiment of the invention is useful for detecting motion of images represented by video pixels having digital pixel values and corresponding to an area defining a horizontal direction and a vertical direction. In such an environment, the apparatus embodiment comprises a first motion detector arranged to generate first motion signals representing detected motion of images represented by the pixel values, and a second motion detector arranged to modify the first motion signals to generate corrected motion signals in response to the relationship of a pixel being processed to a change of motion of one or more of the images in the vertical direction.

A second apparatus embodiment of the invention is useful for detecting motion of images represented by video pixels having digital pixel values. In such an environment, the apparatus comprises a first motion detector arranged to generate first motion signals representing detected motion of images represented by the pixel values, and a second motion detector arranged to modify the first motion signals to generate corrected motion signals in response to the value of the pixel being processed.

A first method embodiment of the invention is useful for detecting motion of images represented by video pixels having digital pixel values and corresponding to an area defining a horizontal direction and a vertical direction. In such an environment, the method comprises    generating first motion signals representing detected motion of images represented by the pixel values, and modifying the first motion signals to generate corrected motion signals in response to the relationship of a pixel being processed to a change of motion of one or more of the images in the vertical direction.

A second method embodiment of the invention is useful for detecting motion of images represented by video pixels having digital pixel values. In such an environment, the method comprises generating first motion signals representing detected motion of images represented by the pixel values, and modifying the first motion signals to generate corrected motion signals in response to the value of the pixel being processed.

By using the foregoing techniques, motion detection can be accomplished with a degree of ease and accuracy previously unavailable.

These and other advantages and novel features of the present invention, as well as details of an illustrated embodiment thereof, will be more fully understood from the following description and drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

<ul id="ul0001" list-style="none"><li>Figure 1 is a schematic bock diagram of a motion detection and noise reduction system made in accordance with one embodiment of the invention.</li><li>Figures 2 and 3 are schematic block diagrams of the motion detector shown in Figure 1.</li><li>Figure 4A is a graph illustrating embodiments of the programmable LUT shown in Figure 2.</li><li>Figure 4B is a graph illustrating additional embodiments of the programmable LUT shown in Figure 2.</li><li>Figure 5 is a schematic block diagram of the image characterization module shown in Figure 1.</li></ul>

DETAILED DESCRIPTION OF THE INVENTION

In general, the motion detection module shown in the Figures converts frame-based temporal differences into a facsimile of motion between like-fields of video across video frames. The motion detected from the frame differences is also used to derive temporal characteristics of the video sequence in order to direct the behavior of other functions in the system. Chrominance motion information is derived from luminance motion information and is qualified by a series of dynamic parameters that take advantage of correlation between chrominance and luminance data.

Additional details about the motion detection module and other aspects of the various embodiments are described in the application entitled "Digital Noise Reduction Techniques," filed on the same day as this application in the name of Jose Alvarez under docket no. 13392US01 and incorporated by reference in its entirety into this application.

The motion detection module detects edge transitions in the motion signal in order to temporarily change the time constant of the recursive filter in order to further prevent temporal blurring, also known as ghosting (a common artifact byproduct of improperly implemented recursive filters). Furthermore, the embodiments make use of a median operator acting directly on the motion signal in order to detect impulses in the motion signal that may be caused by spurious noise in the input video signal.

The input video sequence is analyzed specifically to detect impulsive noise in order to control the impulsive noise reduction filters. Furthermore, the input video sequence is also analyzed to detect moving edges in order to control the time constant of the recursive temporal filter structure.

A dynamic process is one which is controlled by firmware according to information gathered over time. The firmware may control the process at various places, such as a video field boundary or a horizontal video line time. An example is the change in the general form of the motion look-up table shown in Figure 2 according to the amount of total motion detected over a period of time. This period can span several fields. In this particular example and according to one definition, the hardware continues to make motion-adaptive decisions regarding the recursive time constant for each pixel, but the overall shape of the motion transform function is controlled (loaded) dynamically (as needed) by the firmware.

The blocks shown in the drawings may be implemented by a combination of hardware capabilities and firmware intervention based on hardware assistance.

Figure 1 describes a preprocessor system 10 that processes input digital video pixels having digital pixel values received on an input 12. This process involves changing picture size, converting to MPEG color space, and noise reduction. The entire process is under the control of a central processing unit 15 that stores data in a memory 19. The CPU 15 is coupled to each of the blocks shown in Figure 1 through one or more busses 13. To avoid cluttering Figure 1, the connection of the busses to the various blocks has been omitted from the drawing. This specification describes ways of reducing random noise generated by low quality video signal sources, typically converted from the analog domain.

One way of reducing noise is to perform spatial filtering, such as the spatial filtering performed by a 2D scaler/filter 14. This type of noise reduction can be effective but leads to loss of picture detail since it relies on attenuating high frequencies in which random noise is prevalent. A better way of reducing random noise is to use temporal information in the input sequence and filtering the noise in both spatial and temporal domains using linear and non-linear filter structures.

The top-level architecture of a complete motion detection module is depicted in Figure 1.

The input to preprocessor system 10 is digital video which has been converted from the analog domain by an analog video decoder (not shown in Figure 1). To indicate vertical processing, the line buffer blocks 16-18 represent storage elements that may contain adjacent horizontal video lines necessary to perform vertical filtering. There is always a compromise in using internal buffers regarding silicon area and system bus access. It is convenient to store adjacent video lines in local buffers without having to utilize external memory bandwidth in accessing pixels across horizontal lines. For the purpose of this specification, line buffers are used to indicate storage necessary to perform operations along the vertical picture direction.

In many cases, input video must be scaled down depending on the bit rate required for a final display device. A 2D Scaler/Filter module 20 performs both downscaling and spatial filtering, as well as cropping the input video to specific resolutions and bandwidth requirements. The MPEG Encoder will set the size and spatial filtering required for the appropriate video sequence, instantaneous compression factor, and bit stream produced.

Most digital video sources are presented in the YCbCr 4:2:2 color space domain. Since MPEG-2 requires the video to be presented in the YCbCr 4:2:0 domain, it is advantageous to convert to this color space as early as possible in the processing chain in order to decrease memory storage requirements and speed up computations. Since 4:2:2 to 4:2:0 conversion is a vertical downscale operation with very specific phase requirements, it is presented as a separate processing block 20 in Figure 1.

A previous frame block or buffer 22 holds picture information derived from a processing stage one frame-time in the past. The data written to block 22 is taken out of a motion adaptive recursive noise reduction filter 100. If desired, more than one previous frame block may be stored.

A processed frame buffer 24 contains the completely processed frame and may be input to an MPEG Encoder module (not shown). Thus, buffer 22 stores a frame of pixels processed by preprocessor 10 at a time period earlier than the time period during which preprocessor 10 processes the current frame of pixels transmitted along a path 21. Line buffers 16-18 and frame buffers 22 and 24 form part of memory 19.

Digital video signals are processed in the way they are captured by the analog digitizer, i.e., in the form of interlaced frames of video. Each frame consists of two fields of 1/60^th of a second duration. Horizontal and vertical synchronization signals derived from the input video are used to coordinate most of the processing operations described in the present architecture. The embodiments shown in the drawings also are effective for progressive sequences (non-interlaced).

The digital signal processing structures described in this specification make the implicit assumption that chrominance (C) is processed in the same manner as luminance (Y), unless otherwise specified. Each chrominance component (Cb, Cr) is processed individually; therefore, filters keep intermediate results for each component.

Chrominance components (Cb Cr) are assumed to be cosited (sampled at the same time) as the Luminance (Y) component on even sampling locations 0, 2, 4, etc. This assumption does not always hold true because of the wide variance in analog video decoder implementations. Therefore, it is advisable that video interface module at the input of the Scaler/Filter 14 has the capability of swapping color components, offsetting chroma samples and reversing the Y and CbCr sampling order.

Implicit in the Figures is the insertion of matching processing delay elements. One example is the initial motion detection signal mDetect described in following sections. This signal is used to control the processing at various stages, but must be properly delayed to match the corresponding pixel being processed as the video signal travels through the processing elements.

In some sections of this specification, the term "current frame" indicates the luminance and chrominance signals as they are obtained directly from the digital video input port 12.

It is assumed that all signal gain changes are properly saturated and clipped to values 0 to 255, including cases where there could be arithmetic shifts in the left or right directions. All FIR low-pass filters used in described embodiments have positive coefficients that add up to 1.0 (256) and therefore have unity gain at DC. The high-pass filters used are first order with also no gain at DC. Filter coefficients are assumed to be 8-bit quantities. All intermediate computations should be kept at full accuracy and only rounded at interface outputs.

Preprocessor 10 includes a temporal filter 26 comprising frame-recursive IIR type filter 100. Filter 100 is adaptively controlled by the amount of motion detected between images represented by pixels of consecutive frames by a motion detector 300. An image characterization module 400 is also included as shown in Figure 1. The main purpose of temporal filter 26 is to provide noise reduction for random non-correlated white gaussian type noise.

The random noise in this case is the kind that can be generated from tape recordings, low quality broadcast transmissions, and system electronic noise that corrupts picture quality. This noise also can include what is widely known as snow in images sequences.

Still referring to Figure 1, the signal flow starts with the YCbCr 4:2:0 input data from the color space converter 20. The input data on path 21 is referred to as the current frame in later sections of this specification. The recursive filter 100 takes both the current and previous frame data and applies filter 100 with a coefficient (time constant) that is proportional to a corrected amount of motion detected between frames represented by a signal S'. The S' corrected motion signal is supplied over a path 302 to filter 100.

The image characterization module 400 keeps a record of the amount of motion of images in the current frame represented by pixels of the current frame, as well as a record of the data currently being processed. The main purpose of module 400 is to help the firmware decide on the optimal system parameters on a field-by-field basis. However, in other applications, the firmware may exercise control on a horizontal (i.e., line-by-line) basis.

The recursive filter 100 depicted in Figure 1 works on the principle that random, uncorrelated noise can the filtered in the temporal domain for those regions of the picture where a neighborhood of pixels has remained essentially static for at least one frame-time. Since only one previous frame is stored, the motion detection of detector 300 is limited to a short period of time, but the effects of filter 100 can last much longer due to the recursive nature of filter 100.

Motion detection by motion detector 300 is based on temporal frame differences, which are calculated by an arithmetic operator 30 that subtracts pixels residing in the same spatial locations, but one frame-time apart. Motion detector 300 takes the temporal frame differences and converts them into a corrected motion signal S' that represents detected motion. More specifically, motion detector 300 generates corrected motion signals S' representing detected motion of images represented by pixels of the previous frame relative to the motion of images represented by pixels of the current frame.

Motion detector 300 does not estimate motion, it only detects it. For the purposes of the recursive filter 100, it is only necessary to know regions where there is essentially no motion, medium amount of motion and large amount of motion. The precise value of the motion at every pixel is not as important as the neighborhood amount of motion detected.

As indicated in Figure 2, the motion detection is based on the luminance signal. For the great majority of cases, large area luminance motion will be correlated with the chrominance signal. A UV Adjust module 306 modifies the corrected motion signal S' when the correlation between luminance and chrominance is low.

The arrangement of recursive filter 100 is such that S' indicates a stillness measure, i.e., when the motion detected is low, the value of S' approaches one. A very high value of S' will increase the recursive effect of filter 100; therefore S' is sometimes referred to as the time constant of filter 100 at the particular pixel being processed. When S' is zero, the value of A (the current frame) will be passed through filter 100 without modification. A value of zero for S' is also used to reset the recursive effect of filter 100 in cases where there has been a large amount of global frame motion.

The adaptive characteristics of recursive filter 100 are controlled by a motion look-up table 362 (Figure 2) that maps the motion detection signal into the S' signal space. Due to the nature of the recursive noise reduction filter 100, the range of relevant values for the motion detection signal S' is limited. Typically, absolute values greater than 32 are considered very high motion within the small two-dimensional region processed and therefore the look-up table 362 usually consists of at most 32 entries.

Firmware plays a role in the effective use of motion detector 300 and recursive filter 100. With the help of information gathered by the image characterization module 400, the firmware can change the values of the motion look-up table 362 to better suit the temporal and signal quality nature of the input video pixels. Furthermore, firmware can change the register values that control the gain of S' for both the luminance and chrominance components.

The effectiveness of recursive filter 100 is directly related to the value of S' at each pixel. Modifications to the value of S' can be done in most cases by power-of-two gains. As indicated in the control register section, most gain or attenuation factors are expressed by a few bits.

As discussed in a previous section, the corrected motion detection signal S' is based on the temporal difference between frames. Figures 2 and 3 depict a block diagram of the motion detector. In Figures 2 and 3, the bit widths indicate the relevant signal information used at each stage. For example, although the 3-tap vertical filter 332 (Figure 2) operates on 8-bit quantities, since the nature of the frame delta signal is such that its frequency distribution is concentrated largely around low values for most image sequences and because the motion detector detects only small, medium and large motion changes, the relevant information is limited to 5-bits and the programmable LUT is accessed by only 32 values in the illustrated embodiment.

Referring to Figure 2, motion detector 300 includes a two dimensional (2D) smoothing filter 320 and a programmable transfer function module 360. The 2D smoothing filter 320 generates initial motion signals mDetect on a path 334. As shown in Figure 2, filter 320 includes an absolute value operator 322, a 3-tap horizontal median filter 324, a 5-tap horizontal finite impulse response (FIR) filter 326, a rounding and clipping operator 328, a line buffer 330 and a 3-tap vertical FIR filter 332 interconnected as shown.

Absolute value operator 322 calculates the absolute value of the difference between the amplitudes of pairs of corresponding pixels from the current frame on path 21 and the previous frame 22.

The 3-tap median filter 324 is used to eliminate spurious pixel-wide motion between frames. The median filter 324 is a simple ranking operator that always selects the value that is numerically in the center of three consecutive motion samples.

The absolute value of the temporal delta signal is low-pass filtered horizontally by filter 326 to further reduce high frequency components due to noise and to generate horizontal filtered signals. Filter 326 uses fixed coefficients that can be realized without multipliers: <ul id="ul0002" list-style="none" compact="compact"><li>Motion Horizontal Low Pass Filter 326: [1, 3, 8, 3, 1] / 16</li></ul>

Still referring to Figure 2, transfer function module 360 includes an edge detector 364, which provides an indication of a horizontal sudden change in the horizontal filtered signals in order to reduce artifacts produced by horizontal motion of high contrast edges in the images represented by the pixels in the current frame. The resulting effect is the improvement of artifacts caused by the application of a high time constant motion look-up table to video that has only localized motion components when high contrast object or image boundaries move across the current frame. Register medgeThr is used by detector 364 to determine what constitutes a motion edge of an image. For practical purposes, and based on simulation results, the value of medgeDetectGain is either 1.0, 1/2 or 0.0. The effect of medgeDetectGain is to quickly select the strength of the edge with a one-bit value and is limited to the edge boundaries of images, therefore being very short in duration. The edge signals generated by the output of the edge detector 364 are based on the absolute value of a simple horizontal high pass filter: <ul id="ul0003" list-style="none" compact="compact"><li>Motion Edge Detector 364: abs( [1, -1] / 2)</li></ul>

Using vertical filter 332 for the frame delta signal further helps the conversion to a neighborhood motion detection signal. The output of filter 332 is saturated to 5-bits when used as msense, the input to the motion look-up table 362. The 8-bit initial motion detect signal, mDetect, is used by other modules as a true motion detection signal. The vertical motion filter 332 is implemented as a simple filter with coefficients: <ul id="ul0004" list-style="none" compact="compact"><li>Motion Vertical Low Pass Filter: [1, 2, 1] / 4</li></ul>

In order to reduce area requirements and noting that motion look-up table 362 is limited to 32 values, the compromise of storing the saturated 5-bit motion values can be made. It is clear that this operation will lead to inaccuracies, but many experiments with real video sequences have shown that the final effect in the noise reduction is still much better than simply using the horizontal motion filter 320. This can be explained by the goal, which is to detect motion in a two-dimensional neighborhood of pixels across time; it is not the intention to accurately measure motion since this process is not necessary for successful operation of the simple recursive structure.

The programmable look-up table 362 also is referred to as motion LUT or MLUT in other parts of this specification. The general form of table 362 is a monotonically decreasing function. The function can be either sinusoidal or exponential. Image sequences with large amounts of global motion should use MLUT functions that decay rapidly from the origin. Firmware has the option of changing the complete table at field boundaries or the option of only changing the attenuation factors depending on the nature of the input sequence (derived from information provided by image characterization module 400 and the encoding engine itself).

Figure 4A shows a family of functions that have been successfully used for various types of input sequences. Notice that a curve with a base shape can be reduced in amplitude by means of the various adaptive gains (attenuators) in the system. The output of MLUT 362 must be in the range [0..255].

The motion look-up tables depicted in Figure 4B also include sinusoidal versions, as well as the actual data used to generate them. The wider the curve, the more 'aggressive' it is in eliminating random noise. It is important for the curves to 'taper off' gradually as the input values increase to the maximum 32; otherwise motion artifacts can be generated in areas of similar -but not equal- amounts of motion.

Still referring to Figure 4A, curve C1 is the most aggressive and curve C5 is the least aggressive. Curves C1-C5 represent various types of motion of images represented by pixels of the previous frame relative to motion of images represented by pixels of the current frame. More specifically, curves C1-C3 represent types of increasing medium motion, curve C4 represents large motion, and curve C5 represents very large motion.

LUT 362 generates first modified motion signals based on the curves representing the transfer functions. The edge signals from edge detector 364 are multiplied by first modified motion signals generated by LUT 362 in an arithmetic operator 366 to generate second modified motion signals S.

Additional correction of signals S is carried out by components of transfer function module 360 shown in Figure 3, including a multiple arithmetic operator 368, an Hline motion control module 370 and a content adaptive motion control module 372. The MotionGain input to operator 368 is a fixed factor ranging typically from 2.0 to 1/64, and used to directly modify the general form of the MLUT 362 output.

Second modified motion signal S is further modified by module 370 on a line-by-line basis to generate third modified motion signals by reducing the value of S using a fixed attenuation factor indicated by MotionReduceShift, depending on the total amount of motion detected for the previous line. This motion corresponds to the horizontal line above the current horizontal line in the current frame being processed as indicated by the signal TotalHLineMotion from the image characterization module. The purpose of this signal is to control -based on a threshold MaxHlineMot- the effect of a sudden vertical change in motion, since there is no mechanism to account for these types of changes like in the case of the motion median filter 322 (Figure 3). The MaxHlineMot input helps in isolated cases where the overall filter 26 (Figure 1) is programmed with time constants that would cause temporal blur on a line basis. Only very large values of TotalHLineMotion will cause a reduction in S'; therefore, only a few bits are needed to denote the actual threshold value, MaxHlineMot, even though the maximum real detected motion can be as high as an 18-bit binary value for ITU-656 horizontal lines. Five bits are used to define MaxHlineMot, which will be internally shifted right 12 bits to match the horizontal line motion count.

Furthermore, as shown in Figure 3, module 372 modifies the processed motion detection signal S by the actual value of the pixel being filtered as follows. If the value of the current pixel YCurrFrm (also indicated as A for the luminance path in Figure 2) is between lowLevelNR and highLevelNR, then the value of S is passed through unmodified. However, if YCurrFrm is outside this range, then the value of S is modified (shifted) as indicated by LevelNRShift. This shift value is a four-bit quantity where [3:0] indicates up to a factor of 8 shift, and bit-4 indicates whether the shift is left or right.<img file="EP1383085A2_D0001.tif" />

Motion control module 372 generates the corrected motion signal S', which is applied to the IIR structure of UV adjust module 306 shown in the Figure 4. In the expression for S', » denotes an arithmetic shift right and « denotes an arithmetic shift left (as in C-language syntax).

Referring to Figure 3, UV adjust module 306 comprises an arithmetic operator 308 that subtracts a processed pixel value from the previous chrominance buffer that corresponds in location with a chrominance pixel value from the current frame. An absolute value operator 310 generates a signal mDetectUV representing the absolute value of the difference between the inputs to operator 308. Corrected motion signal S', is correlated with a simpler version of motion derived from msense (Figure 3) and the absolute temporal frame difference between chroma samples, mDetectUV by a chroma motion adjust module 312. If the value of msense is much greater than mDetectUV, the value of S' for chrominance is increased by UVMotionShift. On the other hand, if msense is much smaller than mDetectUV, then the value of S' is reduced by the same amount as before. This processes performed by module 312 is summarized below. The hardware implementation should be careful to keep the results of the subtraction below in the range [0..255].<img file="EP1383085A2_D0002.tif" />

In addition to the chrominance signal modification described above, an arithmetic multiply operator 314 multiples a fixed factor uvMotGain, that typically ranges from 4.0 (shift left by two) to 1/4 (shift right by two), by the output of the chroma motion adjust module 312 to generate adjusted chrominance motion signals SUV'.

Throughout this specification, the term image sequence characterization is used to indicate the process of gathering information and making decisions based on video sequence information. The hardware involved for this task is essentially a set of accumulators and counters that keep track of various spatial and temporal data. Figure 5 shows the signal widths needed for image resolution according to ITU-R656. Horizontal and vertical synchronization signals are used to reset and start accumulating/counting operations, but the values of the previously computed field or line remain stable for the duration of the current field or line until the next synchronization event.

TotalLumaFrmSum is calculated by a counter 402 that keeps track of the sum of all luma pixels in the current frame. This value is an early indication of the average DC value when scaled down by the total image size.

TotalFrmMotion is calculated by a counter 404 that adds the motion detection signal mDetect for the entire current frame. TotalHLineMotion is a horizontal line motion signal calculated by a counter 406 that adds the mDetect signals for the horizontal line above the current horizontal line that includes a pixel being processed. Figure 5 indicates that counter 406 is reset at every vsync or every hsync of a frame. Firmware is responsible for reading the values at the appropriate interrupt before the counters are reset automatically by the hardware.

The area indicators TotalAreaNOmotion and TotalAreaHIGHmotion are calculated by counters 408 and 410, respectively. TotalAreaNOmotion is a low motion signal corresponding to motion of one or more images and TotalAreaHIGHmotion is a high motion signal corresponding to motion of one or more images. Counters 408 and 410 always count up by one as they are indicators of how many pixels fall within the threshold values indicated by the registers. At the end of each field, these registers contain an indication of how many pixels are at the extreme motion detection ranges indicated by the various thresholds. This information is used to globally change motion parameters, including the values of MLUT 362.

The overall operation of preprocessor system 10 will be described in the context of the interaction between hardware and firmware to provide motion detection.

The operation of preprocessor system 10 depends on the interaction between hardware and firmware. The hardware is set up by the firmware via control registers and under the assumption of an input video sequence of pixels on path 12 has mild noise reduction requirements. As the sequence progresses, the image characterization module 400 collects temporal and spatial features of the input sequence for the firmware to analyze. The firmware can determine after several frames have passed, more effective parameters for the noise reduction hardware.

As an example, for the recursive noise reduction process, the firmware may determine that the input video has very little global motion. This is indicated by low values for TotalFrmMotion (typically less than 10% of total frame motion), and at the same time a high value for TotalAreaNoMotion (better than 80% of total frame locations).

When there is a change of scene in the input sequence (e.g., a change in an image), it is possible that the change of scene is accompanied by very large change in overall picture brightness (high value of TotalLumaFrmSum), which would cause a detrimental blur effect if the recursive filter is operating with an "aggressive" MLUT 362. By reading this sudden change, the firmware can temporarily set the global MotionGain and uvMotGain registers to reduce, eliminate or partially disable the effect of the recursive filter 100 (Figure 1) while the transition lasts.

Sudden large transitions in TotalFrmMotion towards zero (below 5% of total possible frame motion) and correlating spikes in the values of both TotalAreaNoMotion and TotalAreaHighMotion at specific intervals may indicate the existence of a 3:2 pull-down sequence. If sampled values of TotalHLineMotion confirm that there has been no significant line-to-line motion for the same frames, then this would be a further indication of repeated fields at the 3:2 cadence.

A rapid but progressive decrease in the value of TotalLumaFrmSum may indicate a fade-to-black video transition, especially if TotalAreaNoMotion remains fairly constant within the thresholds set for low/high motion.

The above-described embodiments enable a preprocessing system that is both effective and economical to determine motion of images represented by pixels or other digital data.

Each of the registers identified in Figures 2-3 and 5 is described in more detail in the following section.

Adaptive Motion Detection and Control

Motion Detection Setup Register

<tables id="tabl0001" num="0001"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="center"><b>it Field</b></entry><entry namest="col2" nameend="col2" align="center"><b>   Name</b></entry><entry namest="col3" nameend="col3" align="left"><b>Description</b></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="center">:7</entry><entry namest="col2" nameend="col2" align="center">   MLPscale</entry><entry namest="col3" nameend="col3" align="left">   Motion Horizontal Low Pass filter scale down factor. Implemented as a Shift Right operator of 3 bits. The filter coefficients are fixed. This gain helps extend the range of MLUT 362</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="center">   MedgeEn able</entry><entry namest="col3" nameend="col3" align="left">   Enable horizontal motion edge detection Enable horizontal motion edge detection</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="center">   medgeThr</entry><entry namest="col3" nameend="col3" align="left">   Motion edge detection threshold sensitivity.</entry></row><row><entry namest="col1" nameend="col1" align="center">:3</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">Range [0..28]    Actual value used is:       {medgeThr[2:0], 2'b00}</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="center">   Width select</entry><entry namest="col3" nameend="col3" align="left">   0: most significant 5-bits (saturated) are stored    1: all the bits are stored in line buffer</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="center">   Bypass MVF</entry><entry namest="col3" nameend="col3" align="left">   Bypass vertical motion low pass filter</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="center">   Bypass MHF</entry><entry namest="col3" nameend="col3" align="left">   Bypass horizontal motion median filter</entry></row></tbody></tgroup></table></tables>

Motion Look-Up Table Coefficients Register

Each write to this register writes 4-bytes of motion coefficients to the MLUT 362. The address is cleared to zero at each field synch. To write the entire table, 8 consecutive writes are required (4x8 = 32). After vsync reset, each read gets 4 coefficients at a time starting at location zero. <tables id="tabl0002" num="0002"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="center"><b>it Field</b></entry><entry namest="col2" nameend="col2" align="center"><b>   Name</b></entry><entry namest="col3" nameend="col3" align="center"><b>Description</b></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="center">1:20 1:20</entry><entry namest="col2" nameend="col2" align="center">MLUT3</entry><entry namest="col3" nameend="col3" align="left">Coefficient 3</entry></row><row><entry namest="col1" nameend="col1" align="center">3:16</entry><entry namest="col2" nameend="col2" align="center">MLUT2</entry><entry namest="col3" nameend="col3" align="left">Coefficient 2</entry></row><row><entry namest="col1" nameend="col1" align="center">5:8</entry><entry namest="col2" nameend="col2" align="center">MLUT1</entry><entry namest="col3" nameend="col3" align="left">Coefficient 1</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" align="center">MLUT0</entry><entry namest="col3" nameend="col3" align="left">Coefficient 0</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="center">:0</entry><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" /></row></tbody></tgroup></table></tables>

Motion Adaptive Recursive Structure

Motion Gain Register

<tables id="tabl0003" num="0003"><table frame="all"><tgroup cols="3" colsep="1" rowsep="0"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="left"><b>it Field</b></entry><entry namest="col2" nameend="col2" align="left"><b>   Name</b></entry><entry namest="col3" nameend="col3" align="left"><b>Description</b></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" morerows="2" rowsep="1" align="left">1:24</entry><entry namest="col2" nameend="col2" morerows="2" rowsep="1" align="left">MaxHlineMot</entry><entry namest="col3" nameend="col3" align="left">   Threshold value for the maximum amount of motion to be considered for attenuating the gain of the motion signal. Only relatively large values of total motion will affect the motion detection control signal.</entry></row><row><entry namest="col3" nameend="col3" align="left">   The actual value used is as follows:</entry></row><row rowsep="1"><entry namest="col3" nameend="col3" align="left">   MaxThreshold = (MaxHlineMot) &lt;&lt;9</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">3</entry><entry namest="col2" nameend="col2" align="left">HLineMotEnable</entry><entry namest="col3" nameend="col3" align="left">   Enables adaptive control of motion detection based on the total amount of motion detected on the previous line (above)</entry></row><row><entry namest="col1" nameend="col1" morerows="3" rowsep="1" align="left">2:12</entry><entry namest="col2" nameend="col2" morerows="3" rowsep="1" align="left">medgeDetectGain</entry><entry namest="col3" nameend="col3" align="left">   Attenuation applied to the motion detection signal for a short period of time at the detection of a motion-edge.</entry></row><row><entry namest="col3" nameend="col3" align="left">   00: Full attenuation, S is forced to zero</entry></row><row><entry namest="col3" nameend="col3" align="left">   01: Attenuation ½</entry></row><row rowsep="1"><entry namest="col3" nameend="col3" align="left">   11: No attenuation</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">0:16</entry><entry namest="col2" nameend="col2" align="left">motionReduc eShift</entry><entry namest="col3" nameend="col3" align="left">   Motion reduction based on amount of horizontal motion for previous line.</entry></row><row><entry namest="col1" nameend="col1" morerows="2" rowsep="1" align="left">5:0</entry><entry namest="col2" nameend="col2" align="left">   uvMotionGai n</entry><entry namest="col3" nameend="col3" align="left">   Chrominance motion adaptive control gain factor</entry></row><row><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">   uvMotionGain[7]: 1 means shift right, 0 means shift left</entry></row><row rowsep="1"><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">   uvMotionGain[6:0]: binary shift right or left according to bit 7</entry></row><row><entry namest="col1" nameend="col1" morerows="2" rowsep="1" align="left">:0</entry><entry namest="col2" nameend="col2" morerows="2" rowsep="1" align="left">   motionGain</entry><entry namest="col3" nameend="col3" align="left">   Luminance motion adaptive control gain factor</entry></row><row><entry namest="col3" nameend="col3" align="left">   motionGain[7]: 1 means shift right, 0 means shift left</entry></row><row rowsep="1"><entry namest="col3" nameend="col3" align="left">   motionGain[6:0]: binary shift right or left according to bit 7</entry></row></tbody></tgroup></table></tables>

Content Adaptive Motion Control Register

<tables id="tabl0004" num="0004"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left"><b>it Field</b></entry><entry namest="col2" nameend="col2" align="left"><b>   Name</b></entry><entry namest="col3" nameend="col3" align="left"><b>Description</b></entry></row></thead><tbody valign="top"><row rowsep="0"><entry namest="col1" nameend="col1" morerows="2" rowsep="1" align="left">0:16</entry><entry namest="col2" nameend="col2" morerows="2" rowsep="1" align="left">LevelNRShift</entry><entry namest="col3" nameend="col3" align="left">   Shift factor applied when current pixel value falls outside the range bounded by highLevelNR and lowLevelNR</entry></row><row rowsep="0"><entry namest="col3" nameend="col3" align="left">   LevelNRShift[4]: 1 means shift right, 0 means shift left</entry></row><row><entry namest="col3" nameend="col3" align="left">   LevelNRShift[3:0] binary shift right or left depending on bit-4</entry></row><row><entry namest="col1" nameend="col1" align="left">5:0</entry><entry namest="col2" nameend="col2" align="left">highLevelNR</entry><entry namest="col3" nameend="col3" align="left">   Upper threshold for application of Noise Reduction</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">:0</entry><entry namest="col2" nameend="col2" align="left">lowLevelNR</entry><entry namest="col3" nameend="col3" align="left">   Lower threshold for application of Noise Reduction</entry></row></tbody></tgroup></table></tables>

Chroma Motion Adjustments Register

<tables id="tabl0005" num="0005"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left"><b>itField</b></entry><entry namest="col2" nameend="col2" align="left"><b>   Name</b></entry><entry namest="col3" nameend="col3" align="left"><b>Description</b></entry></row></thead><tbody valign="top"><row rowsep="0"><entry namest="col1" nameend="col1" morerows="1" rowsep="1" align="left">0:16</entry><entry namest="col2" nameend="col2" morerows="1" rowsep="1" align="left">uvMotionShift</entry><entry namest="col3" nameend="col3" align="left">   Shift factor applied as adjustment to the luminance motion detection signal.</entry></row><row><entry namest="col3" nameend="col3" align="left">   LevelNRShift[4:0 binary shift right or left depending on whether the luminance</entry></row><row><entry namest="col1" nameend="col1" /><entry namest="col2" nameend="col2" /><entry namest="col3" nameend="col3" align="left">motion signal is much different from the chrominance temporal absolute difference signal.</entry></row><row><entry namest="col1" nameend="col1" align="left">5:0</entry><entry namest="col2" nameend="col2" align="left">   uvHighCorrRange</entry><entry namest="col3" nameend="col3" align="left">   Upper range for determining what constitutes high correlation between chroma and luma motion detection.</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">:0</entry><entry namest="col2" nameend="col2" align="left">   uvLowCorrRange</entry><entry namest="col3" nameend="col3" align="left">   Lower range for determining what constitutes low correlation between chroma and luma motion detection.</entry></row></tbody></tgroup></table></tables>

Image Characterization

The values in these registers remain valid for the duration of the current field and are changed only at vertical or horizontal sync, as the case may be. This way, the firmware can always read the value of the previous field at ay time. The status count registers should not overflow.

Sum of Luminance Register

<tables id="tabl0006" num="0006"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left"><b>it Field</b></entry><entry namest="col2" nameend="col2" align="left"><b>   Name</b></entry><entry namest="col3" nameend="col3" align="left"><b>Description</b></entry></row></thead><tbody valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="left">6:0</entry><entry namest="col2" nameend="col2" align="left">   TotalLumaFrmSum</entry><entry namest="col3" nameend="col3" align="left">   Adds all pixels in luma for the current frame</entry></row></tbody></tgroup></table></tables>

Total Temporal Frame Register

<tables id="tabl0007" num="0007"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="center"><b>it Field</b></entry><entry namest="col2" nameend="col2" align="center"><b>   Name</b></entry><entry namest="col3" nameend="col3" align="center"><b>Description</b></entry></row></thead><tbody valign="top"><row rowsep="1"><entry namest="col1" nameend="col1" align="left">6:0</entry><entry namest="col2" nameend="col2" align="left">   TotalFrmMotion</entry><entry namest="col3" nameend="col3" align="left">   Adds all the motion detected between the current and previous frames</entry></row></tbody></tgroup></table></tables>

Total Horizontal Line Motion Register

This register is double-buffered and guaranteed to always be ready by the firmware with stable values. <tables id="tabl0008" num="0008"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left"><b>itField</b></entry><entry namest="col2" nameend="col2" align="left"><b>   Name</b></entry><entry namest="col3" nameend="col3" align="left"><b>Description</b></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">6:18</entry><entry namest="col2" nameend="col2" align="left">   HmotionLineCount</entry><entry namest="col3" nameend="col3" align="left">   Indicates the horizontal line to which TotalHLineMotion belongs</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">7:0</entry><entry namest="col2" nameend="col2" align="left">   TotalHLineMotion</entry><entry namest="col3" nameend="col3" align="left">   Adds all the motion detected between line above in the current    frame and the line above in the previous frame</entry></row></tbody></tgroup></table></tables>

Total Area Containing No Motion Register

<tables id="tabl0009" num="0009"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left"><b>itField</b></entry><entry namest="col2" nameend="col2" align="left"><b>   Name</b></entry><entry namest="col3" nameend="col3" align="left"><b>Description</b></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">6:19</entry><entry namest="col2" nameend="col2" align="left">   NO Motion Threshold</entry><entry namest="col3" nameend="col3" align="left">   All pixels with motion values detected below this threshold are considered static.</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">8:0</entry><entry namest="col2" nameend="col2" align="left">   TotalAreaNoMotion</entry><entry namest="col3" nameend="col3" align="left">   Counts all the pixel locations where there was no motion as indicated by the threshold value</entry></row></tbody></tgroup></table></tables>

Total Area Containing High Motion Register

<tables id="tabl0010" num="0010"><table frame="all"><tgroup cols="3" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="52.50mm" /><colspec colnum="2" colname="col2" colwidth="52.50mm" /><colspec colnum="3" colname="col3" colwidth="52.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col1" align="left"><b>it Field</b></entry><entry namest="col2" nameend="col2" align="left"><b>   Name</b></entry><entry namest="col3" nameend="col3" align="left"><b>Description</b></entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">6:19</entry><entry namest="col2" nameend="col2" align="left">   HIGH Motion Threshold</entry><entry namest="col3" nameend="col3" align="left">   All pixels with motion values detected above this threshold are considered largely moving.</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">8:0</entry><entry namest="col2" nameend="col2" align="left">   TotalAreaHigh Motion</entry><entry namest="col3" nameend="col3" align="left">   Counts all the pixel locations where there was a lot of motion as indicated by the threshold value</entry></row></tbody></tgroup></table></tables>

The foregoing embodiments offer the following advantages: <ul id="ul0005" list-style="none"><li>A motion signal is processed with a median operator to eliminate spurious temporal impulses in order to improve the effect of the temporal recursive filter;</li><li>A motion signal is examined for edges that represent moving boundaries of objects in order to properly control the time constant of the recursive filter and therefore prevent ghosting;</li><li>Dynamic control on a pixel-by-pixel basis allows fine grain control of filtering process;</li><li>Frame-based, field-correlated motion detection is simpler to implement than motion estimation;</li><li>Adaptivity based on motion detection is simpler and as effective as implementation using block motion estimation; and</li><li>Motion detection is only performed on luminance and derived by correlation for chrominance.</li></ul>

While the invention has been described with reference to one or more preferred embodiments, those skilled in the art will understand that changes may be made and equivalents may be substituted without departing from the scope of the invention. In addition, many modifications may be made to adapt a particular step, structure, or material to the teachings of the invention without departing from its scope. Therefore, it is intended that the invention not be limited to the particular embodiment disclosed, but that the invention will include all embodiments falling within the scope of the appended claims.