Low-complexity intra prediction for video coding

Technical Field The present invention relates to video coding, and in particular to intra-frame prediction, in which a sample block is predicted using previously coded and reproduced pixels from the same video frame.

2. General information [0002] Digital video requires a large amount of data to represent each frame of a digital video sequence (e.g. a series of frames) in an uncompressed manner. In most applications, it is not feasible to send uncompressed digital video over a computer network due to bandwidth constraints. In addition, uncompressed digital video requires large storage space. Digital video is usually coded in some way to reduce storage space requirements and reduce bandwidth requirements.

[0003] One of the techniques for encoding digital video is inter-frame prediction or inter prediction. Interframe prediction uses temporary redundancy among different frames. Temporarily adjacent video frames usually contain pixel blocks that are substantially the same. During the encoding process, the motion vector determines the traffic dependencies between the block of pixels in one frame and a block of similar pixels in another frame. Accordingly, the system is not required to encode a block of pixels twice, but rather encodes a pixel block once and provides a traffic vector for another block of pixels.

[0004] Another technique for encoding digital video is intra-frame prediction. Intra-frame prediction encodes a frame or part of it with no reference to pixels in other frames. Intra-frame prediction uses spatial redundancy among the pixel blocks within the frame. Because the spatially adjacent pixel blocks generally have similar attributes, the efficiency of the coding process is increased by referring to the spatial mutual correlation between adjacent blocks. This correlation can be used by prediction of the target block based on the prediction modes used in adjacent blocks.

Summary of the Invention [0005] The present invention provides a unique intra-frame prediction process that improves video coding efficiency. H.264 / AVC uses reference pixels in the horizontal border located directly above the target block to be predicted, and reference pixels in the vertical border are located directly to the left of the target block. The present invention obtains at least a portion of either the horizontal border pixel array or the vertical border pixel array. Then, the acquired pixels are added to other border pixels to widen their layout. Intra-frame prediction is only made based on this extended system of border pixels. In an embodiment of the present invention,

[0006] The present invention eliminates the decision-making process of selecting either a horizontal boundary or a vertical boundary from which reference pixels are acquired. The present invention also eliminates the process of repeating the calculation of the position of a vertical boundary crossing the direction of prediction, where typically the process of repeating the calculation involves a dividing operation. The elimination of these processes allows the intra-frame prediction process to be carried out in Single-Instruction Multiple Data (SIMD) architectures, thus improving the computational efficiency of video coding.

[0007] In an embodiment of the present invention, at least some of the pixels from the vertical border are acquired using a vertical pixel identifier expressed by:

[Sze * col 1, angle J where size is the size of the target block to be predicted, angle means the direction of prediction, and col is the counter that is decreased by 1 from -1 to angle. The acquired pixels are added to the horizontal pixels in the location identified by the [col] identifier of the horizontal pixel.

[0008] In another embodiment, when acquiring at least some pixels of the vertical boundary, InvAngle is calculated from

N * size angle _. where N is an integer being the power of 2. Then, at least some of the pixels from the vertical border are acquired, using the identifier of the vertical pixel, which is expressed as [col * InvAngle >> log₂N]. The acquired pixels are added to the horizontal pixels at the location specified by the [col] identifier of the horizontal pixel.

[0009] In another embodiment, InvAngle is obtained from a look-up table that lists InvAngle values ​​with respect to the angle value.

[0010] In another embodiment, a pixel is identified from among the vertical border pixels using a vertical pixel [row], where the row is a counter increments of 1 from 0 to size. The acquired pixel is added to the pixels of the horizontal boundary in the position identified by the identifier [int + 1] of the horizontal pixel, where int is an integer representing the position of the pixel crossing the prediction direction.

[0011] The present invention also provides an encoding apparatus and a decoding apparatus that employs an intra-frame prediction operation in which at least some of either a horizontal dot pixel array or a vertical border pixel array is acquired. Then, the acquired pixels are added to other border pixels to enlarge the pixel layout. Intra-frame prediction is carried out only on the basis of an extended set of border pixels. BRIEF DESCRIPTION OF THE DRAWING FIGURES [0012]

FIG. 1 is a block diagram showing an exemplary hardware architecture on which the present invention may be implemented.

FIG. 2 is a block diagram showing a video encoding device in general to which the present invention may be applied.

FIG. 3 is a block diagram showing a video decoding device in general to which the present invention may be applied.

FIG. 4 is a block diagram showing functional modules of an encoding device according to an embodiment of the present invention.

FIG. 5 is a flowchart showing the intra-frame prediction process performed by an intra-frame prediction module in accordance with an embodiment according to the present invention.

FIG. 6 is a block diagram showing function modules of a decoding apparatus according to an embodiment of the present invention.

FIG. 7 is a diagram showing the prediction directions illustrating the 4x4 prediction modes supported by H.264 / AVC.

FIG. 8 is a diagram showing the prediction directions proposed in document No. JCT-VC A119.

FIG. 9 is a flow chart showing the process proposed in JCT-VC

A119, a block generation that was predicted according to one of the prediction directions shown in FIG. 7.

FIG. 10 is a flowchart showing a low complexity intra-frame prediction process performed according to an embodiment of the present invention.

FIG. 11A is a schematic view showing a prediction block and pixel layouts of the horizontal and vertical boundaries.

FIG. 11B is a schematic view showing a horizontal border pixel arrangement plus vertical pixel pixels.

FIG. 12 is a flowchart showing the process of enlarging a horizontal border pixel arrangement performed according to an embodiment of the present invention.

FIG. 13 is a flowchart of another embodiment of magnifying a horizontal border pixel arrangement.

FIG. 14 is a flowchart showing a low complexity intra-frame prediction process performed in accordance with another embodiment of the present invention.

DETAILED DESCRIPTION OF THE DRAWING AND CURRENT FIGURES FOR USE [0013] FIG. 1 shows an exemplary hardware architecture of a computer 100, wherein the present invention may be implemented. It should be noted that the hardware architecture shown in FIG. 1 may be common to both the video encoding apparatus and the video decoding apparatus that employ embodiments of the present invention. The computer 100 includes a processor 101, memory 102, storage device 105, and one or more input and / or output devices (I / O) 106 (or peripherals) that are connected so as to be able to communicate via the local interface 107. Local the interface 105 may be, e.g., but not limited to one or more buses or other wired or wireless connections,

The processor 101 is a hardware device for running software, in particular that stored in memory 102. The processor 101 may be any specialized or commercially available processor, a main computing unit (CPU), or an auxiliary computing unit among a plurality of processors associated with the computer 100, a microprocessor based on semiconductor technology (in the form of a microchip or a set of system structures), or generally any device for running software instructions.

[0015] The memory 102 consists of a computer readable medium that can include any memory or a combination of volatile memory elements (e.g., random access memory (RAM, such as DRAM, SRAM, SDRAM, etc.)) and non-volatile memory elements. (for example, ROM, hard disk, tape, CDROM, and the like). Furthermore, the memory 102 can use electronic, magnetic, optical and other types of storage media. The computer-readable medium may be any means capable of storing, connecting, broadcasting or transmitting a program for use by, or in combination with, an instruction execution system, subassembly or device. It should be noted that the memory 102 may have a distributed architecture in which the various components are located at a distance from each other,

[0016] The software 103 in memory 102 may include one or more separate programs, each of which includes an ordered set of executable instructions to perform the logic functions of the computer 100, as described below. In the example of FIG. 1, the software 103 in the memory 102 determines the functionality of the video encoding or video decoding of the computer 100 according to the present invention. Furthermore, although it is not required, it is possible for the memory 102 to include an operating system (O / S) 104. The operating system 104 primarily controls the execution of computer programs and provides queuing, input control, data and file management, memory management and communications control and related services.

[0017] The storage device 105 of the computer 100 may be one of many types of storage devices, including stationary storage devices or portable storage devices. For example, the storage device 105 may be a magnetic tape, disk, flash memory, volatile memory, or other storage device. Furthermore, the storage device 105 may be a secure digital memory card, or any other type of removable storage device 105. The I / O devices 106 may include input devices, e.g., but not limited to a touch screen, keyboard, mouse, scanner, microphone, or other. input device. Furthermore, the I / O devices 106 may also include output devices, e.g., but not limited to, a display or other output devices.

[0019] As is well known to those skilled in the art, video compression is obtained by removing repetitive information in a video sequence. There are many different video coding standards, examples of which include MPEG-1, MPEG-2, MPEG-4, H.261, H.263, and H.264 / AVC. It should be noted that the present invention is not limited to applications for a specific video coding standard. However, the following description of the present invention is provided using the example of the standard H.264 / AVC. H.264 / AVC is the latest video encoding standard and achieves significant performance improvements over existing coding standards, such as MPEG-1, MPEG-2, H.261 and H.263.

[0020] In H.264 / AVC, each frame or video image can be separated into several slices. These clippings are then divided into blocks (sizes) 16 * 16 pixels called macroblocks, which can then be further divided into blocks 8 * 16, 16 * 8, 8 * 8, 4 * 8, 8 * 4, up to 4 * 4 pixels. H.264 / AVC supports five types of slices. In sections I, all macroblocks are coded using intra-frame prediction. In macroblocks, macroblocks can be coded using intra-frame or inter-frame prediction. P-slices allow the use of only one motion compensated prediction (MCP) signal per macroblock. In B sections macroblocks can be coded using intra-frame or inter-frame prediction. Two MCP signals can be used for one prediction. The SP slices allow the P slices to be effectively switched between different video streams. The SI slice is an exact match for the SP slice for random access, or for restoring to the state before the error occurred, when only intra-frame prediction is used.

[0021] In FIG. 2 shows a general form of a video coding apparatus in which the present invention may be applied. The blocks shown in the figure show the functional modules implemented by the processor 101 that executes the program 103 in memory 102. The image of the video frame 200 is input into the video encoding device 201.

The video coding device considers the image 200 in the units of the macroblocks 200A. Each macroblock includes several pixels of image 200. On each macroblock a transformation is carried out into transformation coefficients, followed by quantization to conversion factor levels. In addition, intra-frame or inter-frame prediction is used to not encode directly on image data, but on their differences to pixel values ​​that have been predicted, thereby obtaining small values ​​that can be more easily compressed.

[0022] For each slice, the coding device 201 generates several syntax elements that form a coded version of the macroblocks of the respective slice. All other data components in syntax elements that are associated with the coding of transform coefficients, such as transform coefficient levels or a materiality map indicating the omitted transform coefficient levels, are called the syntax elements of the remaining data. In addition to these syntax elements of the remaining data, the syntax elements generated by the video encoding device 201 include control information syntax elements including control information about how to encode each macroblock and how to decode it accordingly. In other words, the syntax elements can be divided into two categories. The first category of control information syntax elements includes elements that relate, for example, to a type of macroblock, a sub-macroblock type, and information about prediction modes of both spatial and temporal type, as well as control information based on a macroblock or segment. In the second category, all elements of other data, such as a materiality map indicating the positions of all significant coefficients within a block of quantized transformation coefficients and transform coefficient values ​​that are indicated in the unit levels corresponding to the quantization steps, are combined and become the syntax elements of the remaining data. and information on the prediction modes of both spatial and temporal type, as well as control information based on a slice or based on a macroblock. In the second category, all elements of other data, such as a materiality map indicating the positions of all significant coefficients within a block of quantized transformation coefficients and transform coefficient values ​​that are indicated in the unit levels corresponding to the quantization steps, are combined and become the syntax elements of the remaining data. and information on the prediction modes of both spatial and temporal type, as well as control information based on a slice or based on a macroblock. In the second category, all elements of other data, such as a materiality map indicating the positions of all significant coefficients within a block of quantized transformation coefficients and transform coefficient values ​​that are indicated in the unit levels corresponding to the quantization steps, are combined and become the syntax elements of the remaining data.

[0023] The coding apparatus 201 comprises an entropy encoder that encodes the syntax elements and generates arithmetic codewords for each slice. When generating arithmetic codewords for a slice, the entropy coder uses statistical relationships between the values ​​of the data elements of the syntax in the bitstream of the video signal. Video encoding device 201 outputs the encoded video signal for the image slice 200 to the video decoding device 301 shown in FIG. 3.

[0024] In FIG. 3 is a pictorial view of a video decoding apparatus in which the present invention may be applied. The blocks shown in the figure show similar functional modules implemented by a processor 101 executing program 103 in memory 102. Video decoding device 301 receives the encoded signal and first decodes the entropy signal back to the syntax elements. The video decoding device 301 uses the syntax elements to reproduce the macroblock after the macroblock and then a clipping section of the image 300A patterns of the pixels image in the image 300.

[0025] In FIG. 4 shows the functional modules of the video encoding device 201. These functional modules are implemented by a processor 101 executing program 103 in memory 102. The input video image is a frame or field of an ordinary (uncompressed) video image determined by sampling points representing primary color components such as chrominance ("chroma") and luminance ("luma"). ") (Other components are possible, for example hue, saturation and value). The input video image is divided into macroblocks 400, each of which represents a rectangular image area consisting of 16 * 16 pixels of the luma component for the image color. The input image is also divided into macroblocks, each of which represents 8 * 8 pixels of each of the two chroma components for the image color. In the general operation of the coding equipment, the macroblocks introduced to the input can be temporally or spatially predicted using intra-frame or inter-frame prediction. However, it was accepted for the sake of discussion that macroblocks 400 are all type I macroblocks and are subject to only intra-frame prediction.

[0026] Intra-frame prediction is made in intra-frame prediction module 401, the operation of which will be discussed in detail below. The intra-frame prediction module 401 generates a prediction block 402 from the horizontal and vertical border pixels of the neighboring blocks that have previously been encoded, restored, and stored in the frame's 403 memory. The residue 404 from the prediction block 402, which is the difference between the target block 400 and the prediction block 402, is transformed, scaled, and quantized by the transformation / quantization module 405, using methods and techniques known to those skilled in the video coding field.

[0027] Video encoding device 201 includes decoding functionality for performing intra-frame prediction on target blocks. This decoding functionality includes a reverse transformation / quantization module 409 that performs inverse quantization and inverse transformation of the quantized transformation coefficients 406 to obtain a decoded prediction residue 410 that is added to the prediction block 402. The sum of the decoded prediction residue 410 and the prediction block 402 is a reconstructed block 411 that is stored in the frame memory 403 and will be read and used by the intra-frame prediction module 401 to create the prediction block 402 to decode the succeeding target block 400.

[0028] In FIG. 5 is a flowchart of processes performed by intra-frame prediction module 401. According to the H.264 / AVC standard, the intra-frame prediction uses the prediction of each pixel of the target block 400 for multiple prediction modes using interpolation of the border pixels ("reference pixel") of neighboring blocks previously encoded and reproduced. These modes are distinguished by the prediction positive integers 0, 1, 2, ... each of which is associated with another instruction, or algorithm, to perform a specific prediction pixels in the target block 400. The intraframe prediction unit 401 performs the intraframe prediction modes of the respective prediction creates different prediction blocks. With the full search algorithm ("FS"), each of the prediction blocks formed is compared to the target block 400 to find the optimal prediction algorithm that minimizes the prediction residue 404, or creates the smallest prediction 404 prediction among the prediction modes. The recognition of the optimal prediction mode is compressed and sent to the device 301 for decoding together with other elements of the control information syntax.

[0029] Each prediction mode can be described by a general prediction direction as described in words (e.g., upward, upright, diagonal downwards to the left). The direction of the prediction can be described graphically by an angular direction, which is expressed by an arrow diagram, such as shown in FIG. 7. In this type of diagram, each arrow can be considered as representing the direction of the prediction or the prediction mode. The angle corresponding to the prediction mode has a general relationship with the direction from the position of the weighted average reference pixels used to predict the target pixel to the position of the target pixel. Note that the prediction modes include a DC prediction mode that is not related to any direction of prediction and, therefore, it can not be described graphically in a diagram as opposed to other prediction modes. In the DC prediction mode, the prediction block 402 is created in such a way that each pixel in the prediction block 402 is set uniformly relative to the mean value of the reference pixel.

[0030] Returning to FIG 5, the prediction mode is started in Step 501. Next, in Step 502, it is determined whether the prediction mode indicates DC prediction. If this is the case, proceed to Step 503 where the DC prediction block 402 is created with the average value of the reference pixels in Step 503. If the prediction mode indicates otherwise, the prediction block 402 is created according to the instruction or algorithm associated with the prediction mode in the Step. 504, which process will be discussed in detail below. After Step 503 or Step 504, proceed to Step 505, where it is determined whether prediction blocks are created for all prediction modes. If the intra-frame prediction works for all prediction modes, go to Step 506. Otherwise, the prediction mode is increased in Step 507,

[0031] In FIG. 6 shows functional modules of the device 301 for video decoding. These function modules are implemented by a processor 101 executing program 103 in memory 102. The encoded video signal from the video encoding device 201 is first received by the entropy decoder 600 and entropy decoded back to the transformed transformation coefficients 601. The quantized transformation coefficients 601 are inversely quantized and converted by the inverse quantization / transformation module 602 to create a prediction residue 603. The intra-frame prediction module 604 is notified of the prediction mode selected by the coding device 201. According to the selected prediction mode, the intra-frame prediction module 604 performs an intra-frame prediction process similar to that performed in Steps 502, 503 and 504 in FIG. 5 to create a prediction block 605, using pixel boundaries of neighboring blocks previously reproduced and stored in frame memory 606. A prediction block 605 is added to the prediction residue 603 to reproduce the block 607 of the decoded video signal. The restored block 607 is stored in the frame memory 606 to be used in the prediction of the subsequent block.

[0032] In the following, a detailed description of the process from Step 504 performed by the intra-frame prediction modules 401 and 604 is made to create a prediction block with one of the prediction modes except for the DC prediction mode.

H.264 / AVC supports Intra 4 4 intra prediction, Intra 8 8 prediction and Intra 16 prediction. 16. Intra 4 4 prediction is commonly used where there are many important details in the image. Intra 4 4 prediction makes a separate prediction of sixteen luma 4 * 4 blocks within a macroblock. Intra 4 4 is predicted with nine prediction modes, including one DC prediction mode. The spatial directions of prediction with Intra_4 * 4 prediction are performed as shown in FIG. 7. Intra_8 * 8 is predicted with nine prediction modes, including one DC prediction mode. Intra_16 * 16 is predicted with four prediction modes, including one DC prediction mode. [0033] Recent studies show that an increase in the number of prediction directions, or an increase in the number of prediction modes, generally improves the efficiency of video compression. See, for example, document No. JCT-VC A119 ("Angular Intra Prediction") and JCT-VC A124 ("Arbitrary Direction Intra") transmitted to the Joint Collaborative Team on Video Coding (JCT-VC). The increase in the number of prediction directions leads to an increase in the number of angular divisions of the available prediction directions, and thus to an increase in the number of candidates for the prediction block. The increased number of candidates for the prediction block simply increases the chances of getting a prediction block, which is almost the same as the target block to be encoded. In FIG. 8 is a diagram showing the prediction directions proposed in document No. JCT-VC A119. In FIG. 8, the reference pixels consist of seventeen (17) horizontal pixels and seventeen (17) vertical pixels, where the upper-left pixel is common for both horizontal and vertical boundaries. Therefore, there are 33 different prediction directions available for creating prediction pixels in an 8x8 block. The JCT-VC A124 offers arbitrary targeted intra-frame prediction, in which the number of prediction directions is adjusted according to the size of the block to be predicted.

[0034] In FIG. 9 is a flowchart showing the process proposed in JCT-VC A119 to form a block along one of the prediction directions shown in FIG. 8. In the following description of this process, some algorithms are simplified to facilitate clarification. Furthermore, the described process is limited to intra-frame prediction along a direction that is substantially vertical. Intra-frame prediction along a direction that is essentially horizontal can be implemented symmetrically with the process of FIG. 9, as shown in the software provided by JCT-VC A119. Although FIG. 8 shows the 8x8 block to be predicted, the process shown in FIG. 9 can be extended to various amounts of pixels in a variety of configurations. For example, the block to be predicted may contain a 4x4 pixel system. The prediction block can also include an 8x8 pixel layout, a 16x16 pixel layout, or larger pixel layouts. Other pixel configurations, including both square and rectangular systems, can also create a prediction block.

[0035] In Step 900 of FIG. 9, reference pixels on the horizontal and vertical borders that lie, respectively, directly above and to the left of the target block, are read from adjacent blocks that have been previously encoded, restored and stored in the frame memory such as the memory 403 shown in FIG. 4. Pixels from the horizontal border are stored in the memory space called "refH". Pixels from the vertical border are saved in the memory space called "refV". Returning to FIG. 8, the reference pixels are recognized by their coordinates in the coordinate system starting from the upper-left position in the 8x8 block. Thus, the horizontal border pixels have the coordinates expressed by p [x, y] where x = 0, 1 ... 16 ay = 0. The vertical pixel has coordinates expressed by p [x, y] where x = 0, y = 0 , -1, -2 ...- 16. [0036] Accepted, that the horizontal border pixels stored in the memory refH area are recognized by the logical address (x) where x = 0, 1 ... 16, and the horizontal border pixels stored in the refV area of ​​the memory are analogously recognized by the logical address (y) where y = 0 , -1, -2 ...- 16, where each pixel is written at the address having the number in the coordinate from which it is read. Thus, as the horizontal and vertical pixels are graphically depicted in FIG. 8, refH and refV areas of memory can be considered as expanding linearly and perpendicular to each other, and each has a length equal to 2xsize + 1, where "size" is a parameter representing the size of the target block. It has been assumed that size has a value equal to a integer being 2, such as 4, 8, 16 ... Low-pass filter as described in chapter 8.3.2.2.1 in H.

[0037] In Step 901, the counter referred to as "row" is set to zero ("0"). The row counter takes a value from 0 to size and indicates the position of the row of the prediction pixel in the prediction block. In Step 902, a parameter called "pos" is calculated as anglex (row + 1). angle is a parameter having a fractional number in a fixed-point record. For this reason, angle consists of a full part and a fractional part, and the fractional part has a fixed number of binary numbers. angle represents one of the prediction directions shown in FIG. 8. For example, "angle = -size" equates the prediction direction that passes through the coordinates [x = 0, y = 0] in FIG. 8. A positive angle identifies the prediction direction that only crosses the horizontal boundary, while an angle with a negative value identifies the prediction direction that intersects both horizontal and vertical boundaries. angle changes within the range defined by the number of prediction directions that you intend to use. As proposed in JCT-VC A124, the number of prediction directions to be used can be determined according to the size of the block to be predicted. In the following description, it is assumed that the angle occupies a fractional number which varies within the range "-size" to "size". It should be noted that the range limits for angle can be determined by other values. [0038] Like angle, the pos parameter consists of a fractional part and a fractional part, and its fractional part consists of a fixed number of binary digits, which is equal to the logarithm of base 2 from the range boundary for angle, which can be expressed by log2_size accordingly to the above assumption, that the range limit for angle is set to size. pos identifies the intersection between the horizontal boundary and the prediction direction represented by angle. Returning to Step 902, the action "pos >> log2_size specifies an integer in pos, which is stored in the parameter" int ", and the action" pos & (size - 1) "determines the fractional number wpos, which is saved in the parameter" frac " . The ">>" action calls the arithmetic function of offset-in-law of binary numbers. The "&" action calls the arithmetic function "and". which is saved in the "frac" parameter. The ">>" action calls the arithmetic function of offset-in-law of binary numbers. The "&" action calls the arithmetic function "and". which is saved in the "frac" parameter. The ">>" action calls the arithmetic function of offset-in-law of binary numbers. The "&" action calls the arithmetic function "and".

[0039] In Step 903, it is determined whether the angle has a value equal to or greater than zero ("0"). If angle is equal to or greater than zero, go to Step 904. Otherwise, Step 913. Angle equal to or greater than zero suggests that you can rely only on reference pixels located on the horizontal boundary, or stored in refH, in order to to obtain prediction pixels in the prediction block. On the other hand, angle less than zero suggests that reference pixels located on the vertical boundary, or stored in refV, are necessary to obtain prediction pixels in the prediction block.

[0040] In step 904, it is determined if the frac is not zero. If frac is not zero, go to Step 905. If frac is zero, Step 906 occurs. A zero frac suggests that the prediction pixel in the prediction block can be copied directly from the reference pixel at the horizontal boundary. A non-zero frac suggests that the direction of the prediction crosses the horizontal boundary at a non-integer location, and it is necessary to interpolate more than one reference pixel to obtain prediction pixels in the prediction block.

[0041] In step 905, the counter called "col" is set to zero ("0"). The col counter is used to address the reference pixel in refH. In Step 907, the two reference pixels identified by "int + col + 1" and "int + col + 2" are obtained from refH. These two reference pixels are averaged to weighted or interpolated at frac to obtain a reference pixel v. In particular, the reference pixel in refH identified by "int + col + 1" is multiplied by "size-frac" and stored in parameter a. The reference pixel in refH identified by "int + col + 2" is multiplied by "frac" and stored in parameter b. Parameters a and b are then added and divided by size, i.e. (size - frac) + frac. Dividing by size can be replaced by moving to the right by log2_size. The received prediction pixel is stored in an array of memory regions called "pred" that represents the prediction block for the target block in a particular direction of prediction. Each memory area in pred is identified by the row and col parameters. Then, the col is increased by 1 in Step 908 and compared to the size in Step 909. Until col is smaller than size, Steps 907 and 908 are repeated. When col becomes equal to size, go to Step 920.

[0042] If it is determined that frac is zero in Step 904, the col counter is set to zero in Step 906. In Step 910, the prediction pixel is copied directly from refH (int + col + 1) and then stored in the appropriate area memory in pred. col is then incremented by 1 in Step 911 and compared to size in Step 912. Until col is smaller than size, Steps 910 and 912 are repeated. When col becomes equal to size, Step 920 follows.

[0043] Referring to Step 903, an angle of less than zero requires reference pixels with refV to obtain prediction pixels in the prediction block. The col counter is set to zero in Step 913. Next, in Step 914, it is determined whether "int + col + 1" is less than zero. "Int + col + 1" equal to or greater than zero suggests that you can still rely only on reference pixels written in refH to obtain prediction pixels in the prediction block, and Step 915 follows. The process performed in Step 915 is similar to that of Stage 907, and its description will not be repeated here. col is then incremented by 1 in Step 916 and compared to size in Step 917. As long as col is smaller than size, Steps 914, 915 and 916 are repeated. When col becomes equal to size, Step 920 follows.

[0044] If it is determined that "int + col + 1" is less than zero in Step 914, reference pixels stored in refV are needed to obtain prediction pixels in the prediction block. In Step 918, the intersection between the vertical limit and the prediction direction is determined first. In step 918, the position is represented by pos2. It should be noted that in Step 902, pos, i.e. the location of the intersection between the horizontal boundary and the prediction direction, is determined by "angle * (row + 1)". Given that angle expresses the ratio of horizontal and vertical differences, the angle is calculated^-1 * (col + 1) ", instead of" angle * (row + 1) ", to establish the intersection between the vertical boundary and the direction of the prediction. As assumed above, angle is in the range -size to size (-size <angle <size). Therefore, the ratio a between angle and size is determined by:

angle then angle '¹, is determined by:

size (-1 <α <1).

<img file="PL2594076T3_D0001.tif" />

And if so, then pos2 is determined in Step 918 as the square size multiplied by col + 1 and then divided by the absolute value of the angle as follows:

size² χ (col +1) pos2 = [ang / ej [0045] Like pos, pos2 has a fractional number in a fixed-point record that consists of a full and a fractional part. The fractional part consists of the number of binary digits set by log2_size. The whole part pos2 is saved in parameter int2, and the fractional part pos2 is written in the parameter frac2. In Step 919, the two reference pixels identified by "int2 + row + 1" and "int2 + row + 2" are obtained from refV. These two reference points are averaged weighted or interpolated with frac2 to obtain a reference pixel v. In particular, a reference pixel with refV (int2 + row + 1) is multiplied by "size - frac2" and stored in parameter a. The reference pixel with refV (int2 + row + 2) is multiplied by "frac2" and stored in parameter b . These parameters a and b are then added and divided by size, or are shifted to the right by log2_size. The resulting prediction pixel is stored in the corresponding memory "pred" area. Steps 914, 918 and 919 and 916 are repeated until col becomes equal to size, in Step 917.

[0046] In Step 920, the row is incremented by 1. Then, in Step 921, the row is smaller than size. As long as the row is smaller than size, Steps 902 are repeated to obtain a reference pixel in the prediction block. This operation ends when the ditch becomes equal in size in Step 921.

[0047] As mentioned above, increasing the number of candidates in the prediction block contributes to the improvement of the coding efficiency, and at the same time increasing the number of candidates in the prediction block leads to an increase in computational load. For this reason, in order to increase the number of candidates of the prediction block to thereby improve the coding efficiency, the process of creating the prediction block candidates should be reviewed in order to achieve further efficiency of the process. Considering the process shown in FIG. 9, you can see two computing bottlenecks. The first computational bottleneck is the comparison and branching operations of Step 914, which are repeated in a loop. The second bottleneck is the splitting operation from Step 918, which is also performed in the loop.

[0048] Nowadays, for the efficient calculations, the Single-Instruction Multiple Data (SIMD) architecture is available. SIMD allows computers with many processor components to carry outthey did the same operation on many data simultaneously. However, typical SIMD architectures do not support performing splitting or joining / branching in a loop, and thus can not be used to implement the process shown in FIG. 9 due to the fact that it comprises looped Stages 914 and 918, although the loops starting from Step 907 and 910 are sufficiently error-proof to be implemented by SIMD. It is therefore an object of the present invention to get rid of computational bottlenecks from the process shown in FIG. 9 and providing intra-frame prediction with low complexity, which will allow ordinary SIMD architectures to be used to perform parallel processing for all of the prediction directions shown in FIG. 8.

[0049] In FIG. 10 is a flowchart showing a low complexity intra-frame prediction process performed according to an embodiment of the present invention that is designed to replace the process of FIG. 9 in carrying out the process in Step 504 of FIG. 5. In FIG. 10, the same steps that were carried out in FIG. 9 have the same step numbers as those in FIG. 9, e.g. Stages 900, 901, 902, 904, 905, 906, 907, 908, 909, 910, 911, 912, 920 and 921. The description of these common steps will not be repeated here. Steps 1000 and 1001 are specific steps for the process of FIG. 10. As can be seen from the comparison of the process shown in FIG 9, the process of FIG 10 eliminates the comparison step from Step 903 and all of the branched steps to the left of Step 903 that is realized when the angle is less than zero,

[0050] In the added Steps 1000 and 1001, it is determined whether the angle is equal to or greater than -1. When angle is equal to or greater than -1, reference pixels located on the horizontal border are sufficient to generate a prediction pixel in the prediction block, and reference pixels on the vertical border are not needed. On the other hand, when angle is less than -1, reference pixels on the vertical boundary are needed to generate a prediction pixel in the prediction block. In Step 1001, reference pixels written in refH are expanded in the negative direction using at least some of the pixels stored in refV. In FIG. 11A and 11B are schematic views showing the refH expansion performed in Step 1001. In FIG. 11A, the reference pixels 1102 written in refH come from the horizontal border located above the target block 1101. Reference pixels 1103 recorded in refV come from the vertical border to the left of the target block 1101. As shown in FIG. 11B, after Step 1001 of FIG. 10, some of the reference pixels in refV are copied to refH, and refH has the expanded portion 1104 expanding in the negative direction.

[0051] In FIG. 12 is a flowchart showing details of the process being performed in Step 1001. In Step 1201, the col counter is set to -1. col is used to identify the address of the extended refH part. In Step 1202, the reference pixel in refV to be copied to the extended portion of the refH is identified by:

size * col angle

Dividing in the above equation is a division of integers, and the result of the equation is an integer. This equation works similar to the process from Step 918 of FIG. 9.

In Step 918, the total value of pos2 is calculated by:

(size² X (col +1)), ^Δ---- &gt;&gt; log2 _ size.

angle

It should be noted that shifting to the right by log2_size is equivalent to dividing by size.

[0052] In Step 1203, col is reduced by 1. Then, it is determined in Step 1204 to determine whether col is equal to angle. If col is not equal to angle, then the action returns to Step 1202. Steps 1202 and 1203 are repeated until the col becomes equal to the angle. Thus, reference pixels are read from refV in a descending order, or from top to bottom of a vertical boundary, and copied to refH also in descending order, or from right to left of the horizontal boundary. In addition, not all of the reference pixels in refV are copied to refH. Only reference pixels in the range from the top to the intersection point of the prediction direction are copied from refV to refH.

[0053] Returning to FIG. 10, the process steps starting from Step 902 are copied from FIG. 9, and comprise the steps of generating prediction pixels branched to the right of the comparison step of Step 903 in FIG. 9. However, it should be noted that these steps of FIG. 10 use the extended refH (sum of parts 1102 + 1104 in FIG. 11B), while the corresponding steps of FIG. 9 use the original refH (part 1102 in FIG. 10A). Because refH is expanded in the negative direction, no separate intra-frame prediction function specifically designed to use reference pixels stored in refV, such as branched to the left of Step 903 in FIG. 9.

[0054] In FIG. 13 is a flowchart of another embodiment of refH enlargement using reference pixels in refV. The process shown in FIG. 11 and 12 eliminates the bottleneck steps of Steps 914 and 918 shown in FIG. 9, and therefore the efficiency of the intra-frame prediction process is expected to increase. The process shown in FIG. 13 eliminates the division operations performed in Step 1202 of FIG. 12 from the reference pixel copy loops from refV to refH. By eliminating the splitting operation, it is expected that the process shown in FIG. 13 will further increase the efficiency of the intra-frame prediction process.

[0055] The process shown in FIG. 13 replaces Step 1202 of FIG. 12 Steps 1301 and 1302. Step 1302 is included in the reference pixel copy loop from refV to refH, while Step 1301 is outside this loop. Step 1301 introduces a new parameter called "InvAngle". InvAngle is determined by:

size

256x angle _.

Multiplying by 256 is equivalent to shifting to the left by 8 and ensures that every bit resulting from the "size / angle" operation is included in the calculation of the reference pixel reference in refV. In Step 1302, the address of the reference pixel in refV to be copied to the extended portion of the refH is determined by:

col * InvAngle &gt;&gt; 8.

The result "col * InvAngle" is shifted to the right by 8 to reverse the left-shift operation carried out in Step 1301. Note that the right-shift operation of Step 1302 is effective for rounding down the result of "col * InvAngle". To round to the nearest whole number, a round off offset of 128 may be added to the result of "col * InvAngle" before performing the right shift operation. It should be noted that the number "256" is only an example, and Step 1301 may adapt a different number of offset, preferably an integer being power 2, until the number is large enough to keep all bits resulting from the "size / angle" operation. For example, the number may be 64 in Step 1301, instead of 256, and the number of the right shift may be 6 in the Stage

1302, instead of 8. If 64 is used, then the rounding offset should be 32.

[0056] The calculations made in Step 1301 can be replaced by a search operation to further reduce the computational load. In other words, a search table has been prepared that stores the InvAngle values ​​with respect to the angle value. Table 1 below is an exemplary search table in Step 1301.

Table 1

<td>angle</td><td>1</td><td>2</td><td>3</td><td>4</td><td>5</td><td>6</td><td>7</td><td>8</td>

<td>InvAngle</td><td>2048</td><td>1024</td><td>683</td><td>512</td><td>410</td><td>341</td><td>293</td><td>256</td>

It is assumed that in the table above, the size size is 8, and the angle takes the integer values ​​from 4 to 8. However, it should be noted that the size is not limited to 8, and can take a different value, such as 4 and 16. In addition, angle can be a fraction number in a fixed-point record as defined above.

[0057] When the reference pixel is copied from refV to refH in Step 1202 of FIG. 12 or in Step 1302 of FIG. 13, the reference pixel may pass through a low-pass filter to reduce possible aliasing in the prediction block. The strength of this low pass filter can vary according to the angle value. For example, when angle is -size, a low pass filter can be used, and when angle is -2, a strong lowpass filter can be used.

[0058] As explained above, not all reference pixels are copied from refV to refH. Since not all of the reference pixels in refV are copied, some information is lost when copying pixels. To mitigate this loss of information, the resolution of reference pixels in refH and refV can be doubled so that refH and refV contain not only pixels from previously coded and reconstructed blocks, but also one pixel between two neighboring reproduced pixels that is generated by interpolating the two neighboring pixels pixels. The two adjacent pixels can simply be averaged to generate an interpolation pixel. The interpolation process can be performed when the reference pixels in Step 900 of FIG. 9. When the pixel resolution is doubled in refH and refV, identifying the reference pixel addresses stored in refH and refV, such as performed in Steps 907, 910, 915 and 919 in FIG. 9, and Step 1001 in FIG. 10, must be rescaled. For example, "int + col + 1" carried out in Steps 907, 910 and 915 must be changed to "int + 2 * col + 2". "Int + col + 2" implemented in Steps 907, 910, 915 should be changed to "int + 2 * col + 3". "Int2 + row + 1" and "int2 + row + 2" implemented in Stage 919 should be changed to "int2 + 2 * row + 2" and "int2 + 2 * row + 3" respectively. 915 should be changed to "int + 2 * col + 3". "Int2 + row + 1" and "int2 + row + 2" implemented in Stage 919 should be changed to "int2 + 2 * row + 2" and "int2 + 2 * row + 3" respectively. 915 should be changed to "int + 2 * col + 3". "Int2 + row + 1" and "int2 + row + 2" implemented in Stage 919 should be changed to "int2 + 2 * row + 2" and "int2 + 2 * row + 3" respectively.

[0059] In another embodiment, the process of Step 1202 of FIG. 12 can be simply changed to "" refH \ col "refV [-col]" to further simplify the copying process. Despite the deterioration of prediction accuracy, this embodiment provides the least complexity for intra-frame prediction operations.

[0060] FIG. 11B shows the extended portion 1104 added to refH. The extended portion 1104 does not need to be created by reference pixels with refV. The extended portion 1104 may be formed of pixels from the area of ​​the previously reproduced block that spatially corresponds to the position of the expanded portion 1104. In FIG. 11B, because refH (parts 1102 and 1104) is extended in the negative direction, it is in the range from -size to 2 * size. The extended refH range can be scaled to a range from 0 to 3 size - 1 by adding the appropriate offset when addressing the reference pixels in the extended refH. The same applies to rescaling the refV range.

[0061] In another embodiment, the range constraint angle can be chosen freely. In the above embodiments, it has been assumed that the angle assumes a value in the range of -size to size (-size &lt;angle &lt;size). In other words, in the above embodiments, the limits of the angle range are determined by the size of the target block. Note that the limits of the angle range can be specified regardless of the size of the target block, although it is still preferred that the range constraint be specified as an integer being power 2, so that log2_rangelimit is a positive integer and the equation "rangelimit = 1 &lt;&lt; log2_rangelimit "remained true. Choosing a large number as a rangelimite,

[0062] If the limit of the angle range is determined irrespective of the size of the target block, the size appearing in FIG. 9 and 10 must be replaced by rangelimit, and log2_size must be replaced by log2_rangelimit, with the exception of Steps 909, 912, 917 and 921. A comparison of "angle&gt; -1" performed in Step 1000 of FIG. 10 must also be replaced by "angle χ sizel / rangelimit&gt; -1" or "angle χ size&gt; -rangelimit". In addition, the size appearing in Steps 1202 and 1301 of FIG. 12 and 13 must be replaced by rangelimit, and the comparison "col = angle?" Performed in Step 1204 must be replaced by "col = angle χ size / rangelimit?" If rangelimit is introduced as a limitation of the angle range, then Table 1 (presented above) can be changed as follows:

<td colspan="4">this</td><td colspan="5">bale 2</td>

<td>Angle *</td><td>2</td><td>5</td><td>9</td><td>13</td><td>17</td><td>21</td><td>26</td><td>32</td>

<td>InvAngle</td><td>4096</td><td>1638</td><td>910</td><td>630</td><td>482</td><td>390</td><td>315</td><td>256</td>

In Table 2, rangelimit is set to 32. Angle * is equal to the approximate integer "rangelimit χ tan (π χ angle / 8)", where angle = 1, 2, 3, 4, 5, 6, 7 and 8. InvAngle equals 256 χ rangelimit / angle *. The values ​​from Table 2 are all integers that were obtained by rounding up. Instead of being rounded up, these numbers can be rounded down. In Table 3 below, InvAngle equals 32 χ rangelimit / angle *. Since "32" is used instead of "256", the accuracy of the prediction is necessarily smaller than that of Table 2.

<td colspan="4">this</td><td colspan="5">bale 3</td>

<td>angle *</td><td>2</td><td>5</td><td>9</td><td>13</td><td>17</td><td>21</td><td>26</td><td>32</td>

<td>InvAngle</td><td>512</td><td>204</td><td>113</td><td>78</td><td>60</td><td>48</td><td>39</td><td>32</td>

[0064] In FIG. 14 is a flowchart demonstrating another embodiment that further simplifies the process shown in FIG. The process shown in FIG. 10 copying reference pixels from refV to refH is performed before the process enters the main prediction loop, while the copying process shown in FIG. 14 is made within the main prediction loop. In addition, the process shown in FIG. 14 eliminates the InvAngle variable. Steps 900, 902 and 921 shown in FIG. 14 are derived from the respective steps of FIG. 10. [0065] In Step 1401, the lastInt counter is initiated with the value -1. lastInt shows the last pixel index that has been added to refH. In Step 902, pos is calculated by angle χ (row + 1). As explained above, pos determines the location of the intersection point between the boundaries and the prediction direction shown as angle. In the context of FIG. 9, Step 902 results in a pos that identifies the position of the intersection between the horizontal boundary and the prediction direction determined by angle. In addition, in

Step 902, the part being an integer, in pos is stored in int, and the fractional part in pos is saved in the parameter "frac". In Step 1402, it is determined whether the int is smaller than the lastInt. If int is smaller than lastInt, the reference pixel in refV identified by the row is copied to refH under the address identified by "int + 1". Step 1402 consists of Steps 904, 905, 906, 907, 908, 909, 910, 911 and 912 shown in FIG. 9 and 10, the description of which is not repeated here. In Step 1405, the int is copied to lastInt. The copying operation int to lastInt can be performed in Step 1403, instead of in Step 1405.

[0066] The copy operation in Step 1403 copies the same pixel that was copied in Steps 1202 and 1302, where rounding down is used in these steps. Step 1403 can be modified to make the roundings to the nearest integer by conditionally using "row + 1" instead of "row" in Step 1403 when the fractional frac position calculated in Step 902 is greater than the offset that is specified by rangelimit + (angle&gt; &gt; 1). It should be noted that the angle is -ve, and frac is + ve. The use of "row + 1" causes rounding up. To cause a conditional row increase of 1, the process performed in Step 1403 is changed to refH [int +1] refV [row - ((offset frac) &gt;&gt; 31)], assuming that in a 32-bit arithmetic, right shift o "offset frac" gives -1 when frac is greater than offset and gives 0 otherwise. Thus, the address identifier "" row - ((offset - frac) &gt;&gt; 31) "becomes" row + 1 "when frac is greater than offset and becomes" row "otherwise. When the offset is set to rangelimit, then "Offset - frac" will always be positive, and therefore no rounding will occur. [0067] Below is a listing of the source code written in C ++ programming language that implements the process shown in FIG 14. The source code has been modified from the TComPrediction :: xPredIntraAng function found in the TcomPrediction.cpp file, which is part of the TMuC 0.7 software developed by JCT-VC, which is available at row - ((offset - frac) &gt;&gt; 31) "becomes" row + 1 "when frac is bigger than offset and becomes" row "otherwise. If the offset is set to rangelimit, then "offset - frac" will always be positive and therefore no rounding will occur. [0067] Below is a listing of the source code written in C ++ programming language that implements the process shown in FIG. 14. The source code has been modified from the TComPrediction :: xPredIntraAng function found in the TcomPrediction.cpp file, which is part of the TMuC 0.7 software developed by JCT-VC, which is available at row - ((offset - frac) &gt;&gt; 31) "becomes" row + 1 "when frac is bigger than offset and becomes" row "otherwise. If the offset is set to rangelimit, then "offset - frac" will always be positive and therefore no rounding will occur. [0067] Below is a listing of the source code written in C ++ programming language that implements the process shown in FIG. 14. The source code has been modified from the TComPrediction :: xPredIntraAng function found in the TcomPrediction.cpp file, which is part of the TMuC 0.7 software developed by JCT-VC, which is available at [0067] Below is a listing of the source code written in C ++ programming language that implements the process shown in FIG. 14. The source code has been modified from the TComPrediction :: xPredIntraAng function found in the TcomPrediction.cpp file, which is part of the TMuC 0.7 software developed by JCT-VC, which is available at [0067] Below is a listing of the source code written in C ++ programming language that implements the process shown in FIG. 14. The source code has been modified from the TComPrediction :: xPredIntraAng function found in the TcomPrediction.cpp file, which is part of the TMuC 0.7 software developed by JCT-VC, which is available at<a href="http://hevc.kw.bbc.co.uk/svn/jctvc.a124/tags/0.7">http://hevc.kw.bbc.co.uk/svn/jctvc.a124/tags/0.7</a>.

// Function for deriving the simplified angular intra predictions // Function for obtaining simplified angular inter-frame predictions

Void TComPrediction:: xPredIntraAng (Int * pSrc, Int iSrcStride, Pel * &amp; rpDst,

Int iDstStride, UInt iWidth, UInt iHeight, UInt uiDirMode, Bool bAbove, Bool bLeft) {

Int k, 1;

Int deltaInt, deltaFract, refMainIndex;

Int intraPredAngle = 0;

Int absAng = 0;

Int signAng = 0;

Int blkSize = iWidth;

Bool modeDC = false;

Bool modeVer = false;

Bool modeHor = false;

Pel * pDst = rpDst;

// Map the mode index to the main prediction direction and angle // Map the mode indicator to the main direction of prediction and angle if (uiDirMode == 0) modeDC = true;

else if (uiDirMode &lt;18) modeVer = true;

else modeHor = true;

intraPredAngle = modeVer? uiDirMode - 9: modeHor? uiDirMode - 25:

0;

absAng = abs (intrapredAngle);

signAng = intraPredAngle &lt;0? -1: 1;

// Set bitshifts and scale the angle parameter to size2 // Set the bit offsets and scale the angle parameter to size2

Int iAngTable [9] = {0, 2, 5, 9, 13, 17, 21, 26, 32}; absAng = iAngTable [absAng]; intraPredAngle = signAng * absAng;

// Do the DC prediction // Perform the prediction of DC if (modeDC) {

Pel dcval = predIntraGetPredValDC (pSrc, iSrcStride, iWidth, iHeight, bAbove, bLeft);

for (k = 0; k &lt;blkSize; k ++) {for (l = 0; l &lt;blkSize; 1 ++) {pDst (k * iDstStride + 1] = dcval;

}}

} // Do angular predictions // Perform angular predictions

<td>else</td><td colspan="3">{</td>

<td>Pel</td><td>tmp;</td><td></td><td></td>

<td>int</td><td>* pSrcTL = pSrc</td><td>- iSrcStride</td><td>- 1;</td>

<td>int</td><td colspan="2">iStepMain = (modeVer)? 1:</td><td>iSrcStride;</td>

<td>f</td><td>(intraPredAngle</td><td>== 0) {</td><td></td>

for (k-0; k &lt;blkSize; k ++) {for (l = 0; 1 &lt;blkSize; 1 ++) {pDst [k * iDstStride + 1] = pSrcTL [(1 + 1) * iStepMain];

}}

} else {

Int iStepSide = (modeVer)? iSrcStride 1; int lastDeltaInt = -1;

Int iOffset = 32 + (intraPredAngle &gt;&gt; 1); // enables rounding to nearest side reference // allows rounding to the nearest side reference // Int iOffset = 32; // no rounding. (without rounding)

Pel ref [2 * MAX_CU_SIZE];

Pel * refMain = ref + ((intraPredAngle &lt;0)? BlkSize: 0); if (intraPredAngle&gt; 0) {for (k = 0; k &lt;2 * blkSize; k ++) refMain [k] = pSrcTL [(k + 1) * iStepMain];

} else {for (k = -1; k &lt;blkSize; k ++) // the rest are copied later in step 1403, as and when required // the rest is copied later in step 1403, if required by refMain [k] = pSrcTL [(k + 1) * iStepMain];

} for (k = 0; k &lt;blkSize; k ++) {

Int deltaPos = (k + 1) * intraPredAngle; deltalnt = deltaPos &gt;&gt; 5;

deltaFract = deltaPos &amp; (32 - 1);

if (deltalnt &lt;lastDeltalnt) {// step 1402 (step 1402) lastDeltaInt = deltaInt;

refMain [deltaInt] = pSrcTL [(k - ((iOffsetdeltaFract) &gt;&gt; 31)) * iStepSide];

// step 1403 // step 1403 ^} // step 1404 // step 1404 if (deltaFract) {// Do linear filtering // Do a linear filtering for (1 = 0; 1 &lt;blkSize; 1 ++) {refMainIndex = 1 + deltaInt:

pDst [k * iDstStride + 1] = (Pel) (((32-deltaFract) * refMain [refMainIndex] + deltaFract * refMain [refMainlndex + 1] + 16) &gt;&gt; 5);

}}

else {// Just copy the integer samples // Copy total samples for (1 = 0; 1 &lt;&lt; blkSize; 1 ++) {pDst [k * iDstStride + 1] = refMain [1 + deltaInt];

}}

}}

// Toggle block if it is a horizontal mode if (modeHor) {for (k = 0; k &lt;blksize-1; k ++) {for (1 = k + 1; 1 &lt; blkSize: 1 ++) {tmp = pDst [k * iDstStride + 1]; pDst (k * iDstStride + 1] = pDst (1 * iDstStride + k]; pDst [1 * iDstStride + k] = tmp;

}}

} ^} [0068] Given that many changes and modifications of the present invention will undoubtedly become apparent to a person of average skill in the field after reading the above description, it should be taken into account that each particular embodiment shown and described for explanation, not is in any way considered as limiting. Therefore, references to details of various embodiments are not intended to limit the scope of the claims, which in themselves discuss only those features considered relevant to the present invention.