Patent Application
20070237229
Exemplary embodiments of the invention are illustrated in the drawings and in more detail in the following description. The drawings showing in:
A preferred embodiment of the present invention relates to linear-motion coding for GCC.
The main idea behind this concept is to have a set of codes all based on the same skeleton. This is real important since if the picture is divided in regions depending on the movement in each region, the border between two regions must stay invisible. If there are totally different code words used in each region the border would become visible under the form of false contour borders.
Therefore, a first GCC code is defined using a lot of levels and providing a good and almost noise free grayscale for static areas. Then based on this code, levels are suppressed to go step by step to a coding that is more optimized for fast motion. Then, depending on the motion information obtained for each pixel, the appropriate sub-set of codes is used.
The motion information can be a simple frame difference (the stronger the difference between two frames is, the lower the number of levels being selected) or a more advanced information coming from real motion detection or motion estimation.
In the following, it is assumed that at the beginning of the PDP video chain, motion information is given as motion amplitude. This can be provided by either a motion detector/estimator located in the same chip or can be provided from a front-end chip having such block inside.
In the present example a GCC code having 255 discrete levels is used for a static picture as shown in the upper left picture of
However, one of the main ideas behind this concept is to get the best compromise between dithering noise level and moving quality. Furthermore, a very important aspect is that all GCC modes are made in a hierarchical way otherwise the concept will not work very well. This means that a mode k is automatically a subset of a mode k−1.
The number of modes is flexible and depends on the targeted application. These modes can be either all stored in the chip in various tables or generated for each pixel. In the first case the choice between tables will be done depending on the motion amplitude information. In the second case, the motion amplitude information will be used to compute directly the correct GCC encoding value.
The global concept is illustrated on the following table for the same example as shown in
The table shows per column the selected levels for each mode. An empty cell means that the level has not been selected. For intermediate modes (for example between mode 0 and mode I), the symbol “ . . . ” means that the code can be either selected or not depending on the optimization process.
As it can be seen on the previous table, a mode l contains always less discrete levels than a mode k when k<l. Furthermore, all discrete levels from mode l are always available in mode k.
The next paragraph will propose a possibility to define the various modes. Specifically, a hierarchical mode construction will be shown.
In order to define all required modes in a linear way so that they can be changed linearly to motion, a new concept has been developed based on the distance to the ideal GCC curve. For the illustration of this concept
In order to define a motion dependent coding, a parameter called DTI (Distance To Ideal) is defined for each available discrete level of the static area code. This DTI describes the distance between the gravity centre of a code word to the ideal GCC curve (black curve).
Then, the respective DTI will be associated to each code word. In order to obtain various coding depending on the movement each DTI will be compared to a certain motion amplitude. The higher the motion amplitude is, the lower the DTI must be to have a selected code word. With this concept it is possible to define a large amount of coding modes varying with the motion amplitude.
Now, a concept of hardware implementation will be illustrated along with
In the first case, only the DTI is computed by software and stored for each code word in a LUT on-chip. Then, for each incoming pixel, a motion amplitude information is generated or provided. This information will be compared to the DTI information of each code to determine if the code must be used or not.
In the second case, a number P of tables are stored in the chip. The DTI information could be used to define such tables but it is not absolutely mandatory. Additionally, some experimental fine-tuning of the tables can be adopted to further improve the behavior. In that case, the motion amplitude will determine which table must be used to code the current pixel.
According to
where γ is more or less around 2.2 and MAX represents the highest possible input value. The output should be at least 12 bits to be able to render correctly low levels. The output of this gamma block 1 could be forwarded to a motion amplitude estimation block 2 that is optional (e.g. calculating simple frame difference). However, in theory, it is also possible to perform the motion amplitude estimation before the gamma block 1.
In any case, motion amplitude information is mandatory for each incoming pixel. If there is no motion amplitude estimation inside the PDP IC, external motion information must be available (e.g. output of a motion estimation used in the front-end part for up-conversion purposes).
The motion amplitude information is send to a coding selection block 3, which will select the appropriate GCC coding to be used or which will generate the appropriate coding to be used for the current pixel. Based on this selected or generated mode, the resealing LUT 4 and coding LUT 5 are updated. The rescaling unit 4 performs the GCC, whereas the coding unit 5 performs the usual sub-field coding. Between them, the dithering block 6 will add more than 4 bits dithering to correctly render the video signal. It should be noticed that the output of the resealing block 4 is p×8 bits where p represents the total amount of GCC code words used (from 255 to 38 in our example). The 8 additional bits are used for dithering purposes in order to have only p levels after dithering for the encoding block 5. The encoding block 5 delivers 3×16 bit sub-field data to the plasma display panel 7. All bits and dithering relevant numbers are only given as example (more than 16 sub-fields can be available, more than 4 bits dithering is also possible).
A further improvement of the motion coding can be achieved by regarding texture information. Such texture information relates to a skin tone texture, for example. The skin tone texture is very sensitive to motion rendition. Therefore a more hierarchical decision concept could be used to improve the final picture quality as described with
Accordingly, skin tone areas and normal areas are handled differently (cf. European Patent Application 04 291 674.2). In the case of skin tone, even static areas could be handled with a more optimized motion coding compared to normal areas. As illustrated in
In any case, the information of motion should have more impact on skin tone areas than on normal areas.
A possible implementation is either to use two different sets of multiple codes but this will increase the memory on-chip too much if LUTs are used or to use a transformation for the motion amplitude in case of skin tone.
Such a transformation formula is given as following:
where |V| represent the original motion amplitude. Values a and b are correction coefficients used for skin areas. When both textures should have the same coding in static areas, b is chosen to be equal to 0.
| Number | Date | Country | Kind |
|---|---|---|---|
| 06290589.8 | Apr 2006 | EP | regional |
