throbber
I|||||||||||||||||||||||l||||l|||||||||||||||||l|||||||||l||||||||||||||l||
`USOO668'i'4l0l£1
`
`(12) United States Patent
`Brown
`
`(10) Patent N0.:
`(45) Date n1’ Patent:
`
`US 6,687,410 B1
`Feb. 3, 2004
`
`(iraffagnino
`2121.11.11]
`61211111 Proctor 1:1.
`:11.
`8.-'2tJU(J Adiletta ctal.
`5121101 Cltaddha
`8121.11.11
`dc Ouciroz ct al.
`8121.11.11 Wang
`1.1211112 Chaddha
`
`..
`
`
`
`3821236
`3751241]
`3821236
`3481412
`38212'r'(J
`3481611?
`3?5;‘241J.l1‘i
`
`1i,1.131,93"1 A *
`6,11".-"2,83l1 A *
`6,lUl,2?6 A "
`6,233,017 B1 *
`15,275,621} 132 *
`15,281,942 B1 *
`6,331,881 B1 *
`
`FOREIGN PATENT DOCUMENTS
`
`W0
`
`W0 93 14601]
`
`7.-"1993
`
`D'l‘HE.R PUBLICATIONS
`
`IBM Technical 1)isclosure Bulletin, IBM (Iorp., New York,
`vol. 34 No.
`1, Jun., 1999 (Jun. 1991), pp. 289-291,
`XPOt.1U21U22U, ISSN: 0018-8689 p. 291, line 5—last line.
`
`* cited by examiner
`
`Priittntjv E.trmt:'ner—.Io.se L. Course
`
`(57)
`
`ABSTRACT
`
`The present invention is a compression scheme for com-
`pressing audio and video data. An image is divided into
`blocks of pixels. In one test, if all of the pixels are approxi-
`mately equal to the corresponding pixels in the previous
`block, then no data is sent for that block. In a seeunLl1esl,if
`all of the pixels in a block are approximately equal to a mean
`pixel value, then only one color value is transmitted. In a
`thircl
`test,
`if quantization of the pixels via compantling
`results in an acceptable representation, the quantization is
`performed. The present invention uses quantization codes.
`that are proportional to the logarithm ofthe magnitude olthe
`range quantized, computation of a magnitude byte that
`permits rapid discovery of the number of hits used for
`quantization of a block, recursive packing and unpacking of
`quantized pixel data, and two-dimensional paths through the
`block.
`
`14 Claims, '1' Drawing Sheets
`
`DSFIIE i|.D¢K G PLIELS
`3-H
`
`PERFORM TEST A
`ifl
`
`
`
`1
`
`Google Inc.
`(3000 1025
`[PR of US Pat. No. 1,974,339
`
`(54) METHOD AND APPARATUS FOR
`COMPRESSION AND DECOMPRESSION OF
`DATA
`
`(75)
`
`Inventor: Russell A. Ilruwn, Palo Alto, CA (US)
`
`(73) Assignee: Sun Micmsystems, Inc., Palo Alto, CA
`(US)
`
`( *1 Notice:
`
`Subject to any disclaimer, the term olithis
`patent is extended or adjusted under 35
`U.S.C.‘. 154(1)) by 0 days.
`
`(2-1) App]. No.: o9;499,2152
`
`(22
`
`Filed:
`
`Feb. 7, 20110
`
`Gl]6K 9,136
`Int. (:1?
`(51)
`3821239
`(52) U.S. Cl.
`3821232, 236,
`(58) Field of Search
`38?J238—24[1, 242, 248, 250; 3581432, 433;
`348f384.l, 394.l—395.l, 4UU.l—4(l4.l, 4U7.l—4l6.l,
`420.1, 421 .1, 425.2, 430.-1, 431 .1, 375,-'24n.n2—24n.o3,
`240.1 1-240. 1 6, 24018-2-’-10.2, 240. 22-24-0.25;
`341.-"51, 63, 65, 67, 79. 107; 7081203, 300,
`3117-3118, 313, 316-317, 4110-4115
`
`
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`358.1133
`382,-1233
`3821253
`348,391
`3821232
`
`3481699
`
`211980 Kcnichi et :11.
`1,-“I991 Watanabe ct al.
`S,-“[097 Knowles el al.
`2.11998 Manda el al.
`4,-“I998 Music
`511998 Suzuki ct al.
`12.11993 Peak
`111999 Lee
`li‘2|'J1'JCI Sun
`21200:] Pau
`
`..
`
`
`
`4,809_.(1f)'1' A
`4,984,076 A "
`5,661,822 A *
`5,721,':'91 A *
`5,739,861 A *
`5,754,698 A *
`s,a4'1_.ms A
`5,352,251 A
`15,014,181 A *
`6.03.295 A
`
`
`
`

`
`U.S. Patent
`
`Feb. 3, 2004
`
`Sheet 1 of 7
`
`US 6,687,410 B1
`
`DEFINE BLOCK OF PIXELS
`10.1
`
`PERFORM TEST A
`122
`
`NO DATA
`TRANSMISSION
`19.4.
`
`TEST A sA11sI=IED?
`Jfl
`
`
`
`PERFORM TEST 3
`
`10.5
`
`
`
`
`
`APPLY
`com-Ressson
`
`
`
`111?.
`
`TEST B
`
`SATISFIED?
`
`M
`APPLY
`
`COM PRESSiON
`
`1.12
`
`
`
`
`
`TEST C
`SATISFIED?
`199.
`
`
`
`
`
`
`BLOCK
`UNCOMPRESSED
`1.1.1.
`
`FIGURE 1
`
`PERFORM TEST C
`10!
`
`

`
`U.S. Patent
`
`Feb. 3, 2004
`
`Sheet 2 01'?
`
`US 6,687,410 B1
`
`GET NEXT PIXEL BLOCK
`
`2&0.
`
`
`
`TEST PIXEL EQUALITY
`
`am
`
`ALL PIXELS EQUAL?
`
`
`
`
`SET LAST
`
`TRANSMITTED BLOCK
`AS PREVIOUS BLOCK
`
`Z93.
`
`CALCULATE BLOCK
`VARIANCE
`
`
`
`223.
`
`
`UPDATE
`WITHIN
`COUNTER
`THRESHOLD?
`
`E
`
`2§§
`
`
`
`
`
`
`GO TO TEST 8
`
`
`
`
`31
`
`FIGURE 2
`
`

`
`U.S. Patent
`
`Feb. 3, 2004
`
`Sheet 3 of 7
`
`US 6,687,410 B1
`
`OBTAIN NEXT PIXEL
`BLOCK
`
`3_0_Q
`
`3.93.
`
`
`
`no Lust SQUARES
`
`£113
`
`
`TEST
`SATISFIED?
`
`E.
`
`
`
`60 TO TEST c
`
`
`
`.3.9_§
`
`FIGURE 3
`
`
`
`
`ALL PIXELS EQUAL?
`
`OUTPUT CODE
`
`

`
`U.S. Patent
`
`Feb. 3, 2004
`
`Sheet 4 01'?
`
`US 6,687,410 B1
`
`
`
`FIGURE 4
`
`

`
`U.S. Patent
`
`Feb. 3, 2004
`
`Sheet 5 of 7
`
`US 6,687,410 B1
`
`
`
`FIGURE 5
`
`

`
`U.S. Patent
`
`Feb. 3, 2004
`
`Sheet 6 of 7
`
`US 6,687,410 B1
`
`

`
`U.S. Patent
`
`Feb. 3, 2004
`
`Sheet 7 01'?
`
`US 6,687,410 B1
`
`
`
`
`OBTAIN NEXT PIXEL
`BLOCK
`
`19.0
`
`SET HAGNITUDE BYTE
`TO ZERO
`
`
`
`E
`
`
`
`
`
`
`
`OUTPUT PACKEO
`CODES AND INITSAL
`
`BYTE
`
`22%
`
`
`
`IQ.
`
`PRODUCE CODES
`
`CALCULATE
`
`VARIANCE
`
`I91
`
`
`
`
`
`PACK QUANTIZATION
`CODES
`
`
`7.01
`
`
`
`
`TEST
`
`SA'l1SFIED?
`Z29
`L03.
`
`
`EXAMINE MAGNITUDE
`BYTE
`
`OUTPUT 3 BITS PER
`PIXEL
`
`I95
`
`FIGURE 7
`
`

`
`US 6,6814 10 B1
`
`1
`METHOD AND APPARATUS FOR
`COMPRESSION AND DECOMPRESSION OF
`DATA
`
`BACKGROUND
`
`1. Field of the Invention
`
`This invention relates to the field of data compression.
`Portions of the disclosure of this patent document contain
`material that is subject to copyright protection. The copy-
`right owner has no objection to the facsimile reproduction
`by anyone of the patent document or the patent disclosure as
`it appears in the Patent and Trademark Office tile or records,
`but otherwise reserves all copyright rights whatsoever. Sun,
`Sun Mierosystems, and MAJC, are trademarks or registered
`trademarks of Sun Microsystems, Inc. in the United States
`and other countries.
`
`2. Background
`Computer systems are increasingly being used to play
`back multimedia (audio and video) files. Current computer
`systems are often unable transfer data quickly enough from
`storage to allow adequate playback. To solve this problem,
`the multimedia data is compressed for transmission and
`decompressed for playback. However, some compression -
`schemes are not suitable for environments where there is
`
`10
`
`2
`In a third test, it is determined if quantization of the pixels
`via eompanding result in an acceptable representation ofthe
`pixel values. If so, the quantization is used.
`The present
`invention uses quantization (companding)
`codes that are proportional to the logarithm of the magnitude
`of the range quantiaed, computation of a magnitude byte that
`permits rapid discovery of the number of bits used for
`quantization of a block, recursive packing and unpacking of
`quantized pixel data, and two-dimensional paths (even 4
`parallel paths) through the 4 by 4 or 8 by 8 block. In the case
`of image processing, the eornpanding algorithm is initialized
`for each block using one byte of pixel data, which represents
`the unquantized representation of the initial pixel of the
`block. Quantization [companding) proceeds on a pixel-by-
`- pixel basis for each pixel in the block. Thus there are only
`a finite number of pixels processed for a given block before
`the quantization algorithm is reset using the unquanlized
`representation of the initial pixel of the next block. Because
`only a finite number of pixels is processed, there is a high
`probability that only a limited range of quantization codes
`will be used for a given block. Therefore,
`there is an
`excellent chance that
`the quantization codes for a given
`block will fit into one or two bits, not the maximum of four
`bits. This et‘Iect permits compression of the quantization
`codes via the recursive packing algorithm.
`BRIEF DESCRIPIION OF THE DRAWINGS
`
`little processing power available.
`Computers are often used to process, play back, and
`display video data. This video data may come from sources
`such as storage devices, on-line services, VCRs, cable
`systems, broadcast
`television tuners, etc. Video data is
`memory intensive, that is, video data requires large amounts
`of memory for storage and use by a computer system.
`To reduce the transmission bandwidth and memory
`requirements when working with video data, various com-
`pression schemes have been developed so that less storage
`space is needed to store video information and a smaller
`bandwidth is needed to transmit it. Prior art video compres-
`sion schemes include Motion JPEG, MPEG-1, MPEG-2,
`Indeo, Quicktime, True Motion-S, CinePak, etc.
`Many prior art compression schemes rely on fast process-
`ing or powerful processors to decompress image or audio
`data. Many current systems exist where there is very little
`processing power available at
`the point of display. For
`example, a so called “thin” client that is part of a computer
`system may lack sophisticated processing power. A scheme
`is required that can compress and decompress data with little
`computational efi°ort.
`SUMMARY OF TIIE INVENTION
`
`The present invention is a eomprcssion—scheme for com-
`pressing audio and video data. For image compression, an
`image is divided into blocks of pixels. The blocks may be
`4x4 pixels, 5x5 pixels, 3x8 pixels, etc. A number of algo-
`rithms are used on each block to determine the best method
`ofcompressing that block ofpixels. In one embodiment, the
`invention perfonns tests on the blocks. In one embodiment,
`the pixels of the block are compared to analogous pixels in
`a previous block. For example, the top left pixel of a block
`is compared to the top left pixel of the previous block and
`so on. If all of the pixels are approximately equal to the
`corresponding pixels in the previous block,
`then no data
`need be sent for that block, instead, the previous data can be
`used. In a second test, it is determined if all of the pixels in
`a block are approximately equal to a mean pixel value. If so,
`then only one color value need be transmitted for the block.
`
`FIG. 1 is a flow diagram illustrating the operation of one
`embodiment of the present invention.
`FIG. 2 is a flow diagram illustrating the operation of one
`embodiment of test A of the present invention.
`FIG. 3 is a flow diagram illustrating one embodiment of
`test B of the present invention.
`FIG. 4 is a diagram of the path taken by the compander
`through a block of pixels.
`FIG. 5 illustrates alternate paths taken by the compander
`in the present invention.
`FIG. ti is a block diagram of a compander.
`FIG. 7 is a flow diagram illustrating one embodiment of
`test C of the present invention.
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`A compression scheme for multimedia data is described.
`In the following description, numerous specific details are
`set forth in order to provide a more detailed description of
`the invention. It will be apparent, however, to one skilled in
`the art, that the present invention may be practiced without
`these specific details. In other instances, well known details
`have not been provided so as to not unnecessarily obscure
`the invention.
`
`The present invention is directed to a compression scheme
`for multimedia data. In an embodiment
`that compresses
`video data, compression is applied to each video frame of
`the video data. Each frame consists of lines of pixels. The
`pixels are grouped into blocks of pixels. The pixels are then
`subjected to a series of tests to determine if a simple or less
`computationally intensive compression scheme can be
`applied to the block. The tests are simply the attempted
`application of increasingly more complex compression tech-
`niques. If a test
`is successful,
`that
`is, if the attempted
`compression results in adequate compression and acceptable
`quality, then no more testing is done and that compression
`scheme is applied to the block. If a test fails for lack of
`adequate. compression or quality,
`then the next
`test
`in
`sequence is attempted.
`
`4-0
`
`45
`
`50
`
`_
`
`E0
`
`65
`
`

`
`3
`The tests are attempted until adequate compression and
`quality are accomplished, or until
`the last
`test has been
`reached. The invention has the advantage of reducing the
`computation required for compression and for achieving
`greater compression rates than single algorithm schemes
`without loss of quality. A flow diagram of the operation of
`the invention is illustrated in FIG. I. At step 101 a block of
`pixels is defined. This block may he 4x4, 5x5, 8x8, or any
`other suitable block size. At step 102 a first
`test A is
`performed on the block. At decision block 103 it is deter-
`mined whether the test
`is satisfied for compression and
`quality. If so, the system sends no data at step 104 and
`returns to step 101.
`If the decision at block 103 is not satisfied, the system
`applies a second test B at step 105. At decision step 106 it
`is determined whether the test is satisfied for compression
`and quality. If so, that compression scheme is applied at step
`107 and the system returns to step 101.
`If the decision at step 106 is not satisfied, the system
`performs test C‘ on the block at step 108. At decision block
`109 it
`is determined if the test
`resulted in appropriate
`compression and quality. If so. the scheme is applied at step
`110 and the system retrieves the next block at step 101. If
`not, the block is uncompressed (step 111).
`Although the system of FIG. 1 shows the use of three tests
`for compression, the present invention can be used with any
`number of tests as appropriate. The number of tests used
`may impact the speed of compression and decompression.
`Where that is ofconcern, fewer tests may be used. However,
`the present
`invention contemplates an asymmetrical
`compressionidecompression scheme, where compression
`might take longer than decompression.
`
`In one embodiment of the invention, gamma corrected
`RGB color components for each pixel are transformed to ‘
`obtain Y, Cb, and Cr components. Y, Cb, and Cr are
`compressed independently to produce compression data for
`the block of pixels. For each of Y, Cb, and Cr, the compres-
`sion scheme produces six different compression codes that
`vary according to the block under consideration. Thus, for
`each pixel within a block,
`there are three outputs, each
`consisting of a compression code followed by a variable
`number of bytes of compressed data.
`The compression codes of this embodiment of the present
`invention (applied to a 4x4 block of pixels) are as follows:
`
`4-0
`
`45
`
`Contpressinn Code
`
`Interpretation
`
`Bytes
`
`50
`
`0
`I
`2
`3-
`4
`:3
`
`0 bits per pixel
`H2 hit per pixel
`I hit per pixel
`3 bits per pixel
`4 bits per pixel
`8 bits per pixel
`
`0
`I
`3
`5
`9
`16
`
`US 6,6814 10 B1
`
`4
`
`Test A
`In one embodiment of the invention, test A determines
`whether each pixel in the block being tested is approxi-
`mately equal to the corresponding pixel in a previous block.
`For purposes of this discussion, the block being tested is
`referred to as the “present block” and the block to which it
`is compared is referred to as a "previous block". The
`previous block may be a block in a previous frame (such as
`a block in the corresponding block position as the present
`block). Allematively, the previous block may be a block in
`the same frame as the present block, such as the immediately
`preceding block.
`In test A, a variance is calculated between the present
`block and the previous block. This previous variance may be
`calculated as:
`
`10
`
`V_a=2(Pr'—tn'J:
`where p,. represents the present pixel value and b,. represents
`the previous pixel value.
`If the previous variance VP falls below a threshold
`referred to as the “previous variance threshold”, then the
`previous block of pixels is an adequate approximation of the
`present block of pixels and it can be substituted for the
`present block. This is very efficient encoding since no block
`data need be transmitted for the present block.
`The present invention provides additional optimization in
`this embodiment. If all three color components (Y, Cb, Cr)
`pass the variance test A, there is an assumption that the block
`of data is probably part of an image background that does
`not change much between subsequent frames of the image
`sequence. It is also likely that this block of pixels is adjacent
`to other blocks of pixels that represent other relatively
`invariant parts of the image background. When this occurs,
`the invention initializes a counter to one, and for each
`subsequent, adjacent block for which all three colors pass
`the variance test, the counter is incremented by one. This
`creates a run length limited (RLL) optimization of test A.
`Whereas use of the opcode byte permits each block to be
`represented by one byte, the RM. optimization permits the
`representation of many blocks by only two bytes, where the
`first byte specifies the run length encoding and the second
`byte represents the length of the run. Ifonly the second byte
`were used to indicate run length, only 255 blocks could be
`included in a run. This limitation is overcome by using part
`of the opcode byte to encode the most significant bits of the
`run length value.
`The opcode byte contains three compression codes
`encoded in radix-6 format. Because each compression code
`can assume a value of 0 through 5, the opcode byte assumes
`values of 0 through 215, leaving 40 unused values in the
`opcode byte. These unused values can be taken advantage of
`to encode the MSB’s of the run length. Letting o represent
`the value of the opcode byte and c represent the value of the
`count byte, then the values maybe obtained from the count
`value via:
`
`o-(mu I'll) >8}-t-21 6
`c=c0mt.r— [ I_’r.‘armI> =8) <-<8]
`
`The present invention combines the three compression
`codes into one “opcode” byte,
`followed by a variable
`number of bytes of compressed data for each of Y, Cb, and
`Cr.
`
`The opcode byte is constructed by packing the three
`compression codes in radix-6 format. Letting (Ty,
`(.‘,._.,.,, and
`CC, represent
`the compression codes for Y, Cb, and Cr
`respectively, the opcode byte 0 is constructed as:
`
`O=fi[6CI’.+C(_-&J+CC,
`
`where >> represents the right shift operator and >>8 is
`equivalent to division by 256, and where << represents the
`left shift operator and <48 is equivalent to multiplication by
`256. When the opcode byte and the count byte have been
`calculated as above, then the count value may be obtained
`from these two bytes by:
`count-[(0-316_t<<8]+n
`
`E0
`
`65
`
`This approach allows the encoding of a run length of
`10,239.
`
`10
`
`

`
`US 6,6814 10 B1
`
`10
`
`-
`
`5
`The lirst test of this embodiment of the present invention
`looks for blocks that are approximately identical, that
`is,
`their variance is within some threshold value. If a series of
`blocks have pixel values that vary slowly, each present
`block, when compared with a previous block, may satisfy
`the conditions of test A. However, when test A is satisfied,
`the same block is used again and again by the decoder. In
`some situations, that could lead to propagation of error.
`Consider where 100 consecutive blocks vary from each
`other by some small value. If test A is not satisfied for the
`tirst block, the pixel values of that block are transmitted. The
`first block now becomes the previous block and the next
`block becomes the present block. If a comparison of the
`present and previous blocks now satisfies test A, the result
`is to send no data, because the decoder can use the previ-
`ously sent block (that is, the first block.) If this situation
`were to repeat for 100 blocks, the first block would be used
`by the decoder for all of the 100 blocks, even though after
`"100 repeats the difference in pixel values between the first
`block and the present block is 100 times the difference
`between any two consecutive blocks. In this situation, the
`decoder uses the first block for the present block even
`though the large difference between the two blocks does not
`satisfy the conditions of test A.
`The problem can be eliminated by designating the most
`recently transmitted block as the previous block. With this
`approach, each present block is compared to the block
`actually transmitted (in the above example, the first block.)
`In this manner, gradual changes in pixel values will even-
`tually exceed the threshold for test Aand result in transmis-
`sion of the present block (and correspondingly replace the
`previous block with the newly transmitted block.)
`It should be noted that,
`in one embodiment of the
`invention, test Acan include a check for exact equality of a
`pixel of one block and a cort‘espot1ding pixel of another .
`block. Exact equality is subsumed in the test for approximate
`equality, but
`the exact equality test has relatively low
`computational cost and can result
`in higher compression
`speeds, particularly for synthetic graphic images.
`FIG. 2 is a flow diagram of one embodiment oftest A. At
`step 200, the pixel block to be examined is obtained. At step
`201 the pixels are tested for equality with corresponding
`pixels of another block. At decision block 202, if all pixels
`are equal, compression code 0 is transmitted at step 208.
`If the pixels are not equal at block 202 the block variance
`is calculated at step 203. At decision block 204 it
`is
`determined if the variance is within the desired threshold. If
`
`4-0
`
`45
`
`not, the system moves to test B at step 207.
`If the variance threshold is met at step 204, compression
`code 0 is transmitted at step 208. At step 209,
`the last
`transmitted block is set as the previous block as the system
`returns to step 200.
`Test B
`then a second type of
`test,
`If the block fails the first
`comparison (test B) is applied. Test I3 is actually a two part
`test. First, test B determines whether all pixels within the
`block are equal
`to one another.
`If so,
`the compression
`algorithm outputs compression code 1, followed by one byte
`representing the constant value of the color component
`within the block.
`If all of the pixels in the block are not equal, then the
`least—squares variance v“, is computed for the block to see
`if all of the pixels in the block are approximately equal to
`some mean value as follows:
`
`where N is the number of pixels in the block and p,.
`represents the pixel values. If the least-squares variance is
`less than a low-variance threshold, then the mean pixel value
`
`50
`
`_
`
`E0
`
`65
`
`ll
`
`6
`for the block is a reasonable approximation to the value of
`all pixels within the block. In this case, the algorithm outputs
`compression code 1, followed by one byte representing the
`mean pixel value for the block. Note that a positive least-
`squares variance test
`is the second instance where the
`compression algorithm outputs compression code 1 fol-
`lowed by one byte of data. The first instance was the case
`where all pixels were equal to one another within the block.
`The least-squares variance test is a more general test that
`subsumes the case where all pixels are equal. Thus, it is
`possible to eliminate the test for equality of pixels, and allow
`this condition to be detected as a least-squares variance of
`zero. However, the equality test has a low computational
`cost and could result
`in higher compression speeds for
`images with traditional amounts of single color back-
`grounds. This feature may, for example, be enabled when
`compressing synthetic images, as they are more likely to
`have regions of constant pixel values. The feature may be
`disabled when compressing video images, which may lack
`such uniform backgrounds.
`FIG. 3 is a How diagram illustrating one embodiment of
`test B. At step 300, the next pixel block to be examined is
`obtained. At step 301 an equality test is performed to see if
`all of the pixels in the block are equal. If so, compression
`code 1 is transmitted at step 302 and the system returns to
`step 300.
`If all of the pixels are not equal then the least squares
`variance test is applied at step 303. If the variance test is
`satisfied at decision block 304, the system outputs compres-
`sion oode 1 at step 302 and returns to step 300. If the
`variance test is not satisfied, the system proceeds to test C at
`step 305.
`Test C
`
`If the least-squares variance is greater than the low-
`variance threshold,
`then the simple cases have been
`exhausted, and the pixels within the block are subjected to
`Test (i. For each 8-bit pixel value, the quantizer produces a
`4-bit quantization code that represents the quantized differ-
`ence between the pixel value and the value of the previous
`pixel within the block. (Note that
`the definition of the
`previous pixel can mean a number of things).
`Consider the following quantization algorithm:
`for each block
`
`lastm value=tirst,3 pixel
`for each pixel” value p in block
`diff-p—last 13 value
`qu value=quant[diff]
`last” value-clamp[last_ value
`+d,3 quant[q_vatue]]
`emit qm value
`end
`end
`The quantization algorithm is implemented using two
`table lookups. The quantfditf] operation is accomplished via
`a
`lookup table addressed by a 9-bit signed difference
`between successive pixel values. The clamp[last13 value+
`dquant[q,3 value]] operation is accomplished via a lookup
`table addressed by a 12-bit value that
`is obtained by cat-
`enating the 4-bit q,3 value with the 8-bit last” value.
`An extension of the above quantization algorithm permits
`estimation of the coarseness of the quantization. As the
`quantizer creates the quantized values for a particular block,
`it creates the quantization variance vq:
`
`"'.7'2(I7;"fJ'i'i:
`where p, represent the original pixel values and (:1, represent
`the quantized pixel values. If the quantization variance
`
`

`
`7
`the quantization will
`exceeds a high-variance threshold,
`introduce too much error into the pixel representation, and
`hence the quantized data must not be used. In this case, the
`compression algorithm outputs compression code 5, fol-
`lowed by 16 bytes representing the 16 unquantized pixel
`values for the 4x4 block (or 64 bytes for an 8><8 block.) Prior
`to comparison to the low— or high-variance thresholds,
`respectively,
`the least-squares variance and quantization
`variance can be normalized to the square of the mean pixel
`value for the block. The normalized variance expresses a
`constant ratio between the least-squares error and the mean
`pixel value for the block. Because the human visual system
`is sensitive to ratios of light intensity, this approach models
`the threshold test after the physiologic response of the
`human visual system.
`Returning now to the discussion of quantization, if the
`quantization variance does not exceed the high-variance
`threshold, then the quantized pixel values will be output.
`However, often it is possible to output fewer than four bits
`per pixel of quantized data. In order to output fewer than
`[our bits, it is necessary to define quantization codes such
`that there is a correlation between the number ofbits used by
`a particular quantization code, and the magnitude of the
`difference that is quantized. Such a definition is:
`
`|)i1Tercnce
`
`-255 to -91
`-90 to -71
`-"EU to -51
`-50 to -31
`-30 [CI -16
`-15 to -8
`-7 to -3
`-'3 to U
`1 to 2
`.1 to 7
`S to 15
`16 to St]
`31 in 50
`5] [0 70
`Ti
`to 90
`91 to 255
`
`codc
`
`14
`12
`10
`8
`6
`4
`2
`0
`J
`3
`5
`'.-'
`9
`H
`13
`15
`
`4-0
`
`This coding can be important, because for many blocks
`the interpixel variation is sufficiently small that any quan-
`tization code produced for these blocks may he represented
`using two bits, or even one bit.
`A test of the number of bits required to represent any
`quantization code for a particular block may be implemented
`as follows. Prior to producing the quantization codes, the
`quantizer initializes a magnitude byte to zero. As the quan-
`tizer creates each quantization code, it inclusively ORs the
`code into this magnitude byte. When the quantizer has
`finished creating quantization codes for all pixels of the
`block,
`the magnitude byte contains a value that may be
`bit-tested to determine the maximum number of bits _
`
`45
`
`S0
`
`required to represent any quantization code for the block.
`Once the number of bits required to represent any quan-
`tization code for the block is determined. the compression
`algorithm packsthc quantization codes as two, four, or eight
`pixels per byte, oorresponding to four, two or one bit per
`pixel, respectively. It is possible to pack the quantization
`codes as follows.
`A 4-><4 block contains 16 quantization codes. The quan-
`tizer plaoes these 16 codes into an array of 16 unsigned
`characters, with each code occupying the four
`least-
`significant bits of a character. Using the union type available
`in C,
`it
`is possible to simultaneously represent
`the
`
`60
`
`65
`
`12
`
`US 6,687,410 B1
`
`8
`16-element character array as an array of eight shorts, four
`integers, or two long longs:
`
`typ-tzdcf union block {
`unsigned char e[1ti]:
`unsigned short s[3]:
`unsigned int i[4]'.
`unsigned long long ll[2]:
`} Block:
`
`10
`
`Then with a variable b of type Block, it is possible to pack
`the quantization codes recursively into the two-, four- and
`eight—pixels—per—byte representations as follows:
`
`37-!t'[0]=((b-If[D]<<4]|(b-H[1]);
`
`b—"iT0]=((b—'fIl}]}<<3)|{b—'tTl]]1
`
`I5"-*il3l=[(-'7"-9ll3]J<<1Ji(b"-Till}:
`
`The first of the above operations packs the codes as two
`pixels per byte, the second packs them as four pixels per
`byte, and the third packs them as eight pixels per byte. The
`worst case, where quantization codes are to be packed eight
`bits per pixel, requires only three shifts and three inclusive
`ORs per 4x4 block, making for an etlicient scheme. This
`scheme may be adapted without difficulty to other block
`sizes, for example, and 8x8 block.
`These recursive packing operations affect the ordering of
`the quantization codes within the 16-element array. If the
`codes were initially arranged in the following order in the
`array for a 4x4 block:
`01234S6789101112131=t-15
`
`then the recursive packing operations shuffles the codes
`successively as the packing operation proceeds from four to
`two to one bit per pixel, as shown below:
`08192103 1] 4125 136 14715
`04812 1591326 101437 11 15
`024-681012l41357911 1315
`This permutation of the order of the codes is acceptable, so
`long as the decoder unpacks the codes in the proper order.
`For a 4x4 block, the four-, two- and one-bit-per-pixel
`representations require eight, four and two bytes, respec-
`tively. To these bytes is appended one additional byte which
`represents the unquantized value of the first pixel
`in the
`block. This byte provides an accurate starting point for the
`decoder at
`the beginning of each block. This approach
`makes the decoder less sensitive to bit errors that may arise
`due to transmission noise affecting the encoded image data.
`Additionally, this approach increases the probability that the
`quantized pixel data may be represented using less than four
`bits per pixel.
`Depending upon which packing representation is used,
`the compression algorithm outputs a compression code (4, 3,
`or 2) followed by one byte representing the value of the lirst
`pixel of the block, followed by eight, four or two bytes of
`quantized pixel data {for a 4x4 block.)
`FIG. 7 is a flow diagram illustrating one embodiment of
`test C. At step 700 the next pixel block to be examined is
`obtained. At step 701 the magnitude byte is initialized to
`zero. At step 702 the companding algorithm produces the
`4-bit quantization codes. Also at this step, each quantization
`code is inclusively ORed into the magnitude byte. At step
`703 the quantization variance VP is calculated from the
`original pixel values p,. and the quantized pixel values q,..
`Note that this step may be performed contemporaneously
`with step 702.
`
`

`
`US 6,6814 10 B1
`
`9
`At step 704 the quantization variance is examined. If the
`quantization variance exceeds the high—varianoe threshold,
`then 8 bits per pixel are output
`in step 705, and control
`transfers back to step 700 to process the next block of pixels.
`If, however, the quantization variance does not exceed this
`threshold, then the 4-bit quantization codes will be packed
`and outputted. In step 706 the magnitude byte is examined
`to determine the number of bits required to represent the
`quantization codes (4, 2, or I). In step 707 the quantization
`codes are packed via the recursive packing algorithm. In step
`708,
`the 8 bit value of the initial pixel of the block is
`outputted, followed by the packed quantization codes. Con-
`trol then transfers back to step 700 to process the next block
`of pixels.
`Prior Pixel
`The quantizer quantizes the difference between succes-
`sive pixels. A block of pixels is two-dimensional. For this
`reason, the quantixier is directed to follow a path through the
`block, such as the path from point a to point b shown in FIG.
`4 for a 4x4 block.
`
`10
`
`.
`
`10
`In order to update the value of the last pixel 1,, the encoder
`performs the same operations that are to be performed by the
`decoder. The dashed box encloses these operations.
`Specifically, the 4-bit quantized value q,. is dequantized to
`obtain a 9-bit value. This 9-bit dequ antized value is added to
`the 8-bit value of the last pixel l,- to obtain a 10-bit value.
`This 10-bit value occurs because the 4-bit quantized value q_.
`is not a fully accurate representation of the 8-bit pixel value
`p,., and so the value obtained by addition of the 9-bit
`dequantized value to the 8-bit value of the last pixel 1, may
`be less than 0 or greater than 255 (the allowed range for an
`8-bit number.) Therefore, the 10-bit value is passed through
`a low-pass filter {I.PF) which clamps it to the range of U to
`255. The resulting 8-bit value becomes the updated value for
`1,-. These techniques are known in the prior art. An imple-
`mentation of a compandcr in an alternate embodiment uses
`loo

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket