Sign In to Follow Application
View All Documents & Correspondence

"Computational Complexity And Precision Control In Transform Based Digital Media Codec"

Abstract: A digital media encoder/decoder includes signaling of various modes relating to computation complexity and precision at decoding. The encoder may send a syntax element indicating arithmetic precision (e.g., using 16 or 32-bit operations) of the transform operations performed at decoding. The encoder also may signal whether to apply scaling at the decoder output, which permits a wider dynamic range of intermediate data at decoding, but adds to computational complexity due to the scaling operation.

Get Free WhatsApp Updates!
Notices, Deadlines & Correspondence

Patent Information

Application #
Filing Date
13 August 2009
Publication Number
45/2009
Publication Type
INA
Invention Field
COMMUNICATION
Status
Email
lsmds@lakshmisri.com
Parent Application
Patent Number
Legal Status
Grant Date
2017-05-15
Renewal Date

Applicants

MICROSOFT CORPORATION.,
ONE MICROSOFT WAY, REDMOND, WASHINGTON 98052-6399

Inventors

1. SRINIVASAN, SRIDHAR
C/O MICROSOFT CORPORATION., INTERNATIONAL PATENTS, ONE MICROSOFT WAY, REDMOND, WASHINGTON 98052-6399
2. TU, CHENGJIE
C/O MICROSOFT CORPORATION., INTERNATIONAL PATENTS, ONE MICROSOFT WAY, REDMOND, WASHINGTON 98052-6399
3. REGUNATHAN, SHANKAR
C/O MICROSOFT CORPORATION., INTERNATIONAL PATENTS, ONE MICROSOFT WAY, REDMOND, WASHINGTON 98052-6399

Specification

Background
Block Transform-Based Coding
[001] Transform coding is a compression technique used in many digital media (e.g., audio, image and video) compression systems. Uncompressed digital image and video is typically represented or captured as samples of picture elements or colors at locations in an image or video frame arranged in a two-dimensional (2D) grid. This is referred to as a spatial-domain representation of the image or video. For example, a typical format for images consists of a stream of 24-bit color picture element samples arranged as a grid. Each sample is a number representing color components at a pixel location in the grid within a color space, such as RGB, or YIQ, among others. Various image and video systems may use various different color, spatial and time resolutions of sampling. Similarly, digital audio is typically represented as time-sampled audio signal stream. For example, a typical audio format consists of a stream of 16-bit amplitude samples of an audio signal taken at regular time intervals.
[002] Uncompressed digital audio, image and video signals can consume considerable storage and transmission capacity. Transform coding reduces the size of digital audio, images and video by transforming the spatial-domain representation of the signal into a frequency-domain (or other like transform domain) representation, and then reducing resolution of certain generally less perceptible frequency components of the transform-domain representation. This generally produces much less perceptible degradation of the digital signal compared to reducing color or spatial resolution of images or video in the spatial domain, or of audio in the time domain.
(003) More specifically, a typical block transform-based encoder/decoder system 100 (also called a "codec") shown in Figure 1 divides the uncompressed digital image's pixels into fixed-size two dimensional blocks (Xi, ... Xn), each block possibly overlapping with other blocks. A linear transform 120-121 that does spatial-frequency analysis is applied to each block, which converts the spaced samples within the block to a set of frequency (or transform) coefficients generally representing the strength of the digital signal in corresponding frequency bands over the block interval. For compression, the transform coefficients may be selectively quantized 130 (i.e., reduced in resolution, such as by dropping least significant bits of the coefficient values or otherwise mapping values in a higher resolution number set to a lower resolution), and also entropy or variable-length

coded 130 into a compressed data stream. At decoding, the transform coefficients will inversely transform 170-171 to nearly reconstruct the original color/spatial sampled
image/video signal (reconstructed blocks X,,... X„).
roo4j The block transform 120-121 can be defined as a mathematical operation on a vector x of size N. Most often, the operation is a linear multiplication, producing the transform domain output y = M x, M being the transform matrix. When the input data is arbitrarily long, it is segmented into A'^ sized vectors and a block transform is applied to each segment. For the purpose of data compression, reversible block transforms are chosen. In other words, the matrix M is invertible. In multiple dimensions (e.g., for image and video), block transforms are typically implemented as separable operations. The matrix multiplication is applied separably along each dimension of the data (i.e., both rows and columns).
[005] For compression, the transform coefficients (components of vector >') may be selectively quantized (i.e., reduced in resolution, such as by dropping least significant bits of the coefficient values or otherwise mapping values in a higher resolution number set to a lower resolution), and also entropy or variable-length coded into a compressed data stream. [006J At decoding in the decoder 150, the inverse of these operations (dequantization/entropy decoding 160 and inverse block transform 170-171) are applied on the decoder 150 side, as show in Fig. I. While reconstructing the data, the inverse matrix M' (inverse transform 170-171) is applied as a multiplier to the transform domain data. When applied to the transform domain data, the inverse transform nearly reconstructs the original time-domain or spatial-domain digital media.
[007] In many block transform-based coding applications, the transform is desirably reversible to support both lossy and lossless compression depending on the quantization factor. With no quantization (generally represented as a quantization factor of 1) for example, a codec utilizing a reversible transform can exactly reproduce the input data at decoding. However, the requirement of reversibility in these applications constrains the choice of transforms upon which the codec can be designed.
[008] Many image and video compression systems, such as MPEG and Windows Media, among others, utilize transforms based on the Discrete Cosine Transform (DCT). The DCT is known to have favorable energy compaction properties that result in near-optimal data compression. In these compression systems, the inverse DCT (IDCT) is

employed in the reconstruction loops in both the encoder and the decoder of the compression system for reconstructing individual image blocks.
Quantization
too9j Quantization is the primary mechanism for most image and video codecs to control compressed image quality and compression ratio. According to one possible definition, quantization is a term used for an approximating non-reversible mapping function commonly used for lossy compression, in which there is a specified set of possible output values, and each member of the set of possible output values has an associated set of input values that result in the selection of that particular output value. A variety of quantization techniques have been developed, including scalar or vector, uniform or non¬uniform, with or without dead zone, and adaptive or non-adaptive quantization.
[010] The quantization operation is essentially a biased division by a quantization parameter QP which is performed at the encoder. The inverse quantization or multiplication operation is a multiplication by QP performed at the decoder. These processes together introduce a loss in the original transform coefficient data, which shows up as compression errors or artifacts in the decoded image.
Summary
[Oil] The following Detailed Description presents tools and techniques to control computational complexity and precision of decoding with a digital media codec. In one aspect of the techniques, the encoder signals one of scaled or unsealed precision modes to use at the decoder. In the scaled precision mode, the input image is pre-multiplied (e.g., by 8) at the encoder. The output at the decoder also is scaled by rounded division. In the unsealed precision mode, no such scaling operations are applied. In the unsclaed precision mode, the encoder and decoder can deal with a smaller dynamic range for transform coefficient, and thus has lower computational complexity.
[012] In another aspect of the techniques, the codec may also signal the precision required for performing transform operations to the decoder. In one implementation, an element of the bitstream syntax signals whether to employ a lower precision arithmetic operations for the transform at the decoder.
[0131 This Summary is provided to introduce a selection of concepts in a simplified form that is further described below in the Detailed Description. This summary is not intended to identify key features or essential features of the claimed subject matter,

nor is it intended to be used as an aid in determining the scope of the claimed subject matter. Additional features and advantages of the invention will be made apparent from the following detailed description of embodiments that proceeds with reference to the accompanying drawings.
Brief Description Of The Drawings
1014] Figure 1 is a block diagram of a conventional block transform-based codec in the prior art.
[015] Figure 2 is a flow diagram of a representative encoder incorporating the block pattern coding.
rois] Figure 3 is a flow diagram of a representative decoder incorporating the block pattern coding.
[017] Figure 4 is a diagram of the inverse lapped transform including a core transform and post-filter (overlap) operation in one implementation of the representative encoder/decoder of Figures 2 and 3.
[018] Figure 5 is a diagram of identifying the input data points for the transform operations.
(0191 Figure 6 is a block diagram of a suitable computing environment for implementing the media encoder/decoder of Figures 2 and 3.
Detailed Description
[020] The following description relates to techniques to control precision and computational complexity of a transform-based digital media codec. The following description describes an example implementation of the technique in the context of a digital media compression system or codec. The digital media system codes digital media data in a compressed form for transmission or storage, and decodes the data for playback or other processing. For purposes of illustration, this exemplary compression system incorporating the computational complexity and precision control is an image or video compression system. Alternatively, the technique also can be incorporated into compression systems or codecs for other digital media data. The computational complexity and precision control technique does not require that the digital media compression system encodes the compressed digital media data in a particular coding format.

1. Encoder/Decoder
[0211 Figures 2 and 3 are a generalized diagram of the processes employed in a representative 2-dimensional (2D) data encoder 200 and decoder 300. The diagrams present a generalized or simplified illustration of a compression system incorporating the 2D data encoder and decoder that implement compression using the computational complexity and precision control techniques. In alternative compression systems using the control techniques, additional or fewer processes than those illustrated in this representative encoder and decoder can be used for the 2D data compression. For example, some encoders/decoders may also include color conversion, color formats, scalable coding, lossless coding, macroblock modes, etc. The compression system (encoder and decoder) can provide lossless and/or lossy compression of the 2D data, depending on the quantization which may be based on a quantization parameter varying from lossless to lossy.
(0221 The 2D data encoder 200 produces a compressed bitstream 220 that is a more compact representation (for typical input) of 2D data 210 presented as input to the encoder. For example, the 2D data input can be an image, a frame of a video sequence, or other data having two dimensions. The 2D data encoder divides a frame of the input data into blocks (illustrated generally in Figure 2 as partitioning 230), which in the illustrated implementation are non-overlapping 4x4 pixel blocks that form a regular pattern across the plane of the frame. These blocks are grouped in clusters, called macroblocks, which are 16x16 pixels in size in this representative encoder. In turn, the macroblocks are grouped into regular structures called tiles. The tiles also form a regular pattern over the image, such that tiles in a horizontal row are of uniform height and aligned, and tiles in a vertical column are of uniform width and aligned. In the representative encoder, the tiles can be any arbitrary size that is a multiple of 16 in the horizontal and/or vertical direction. Alternative encoder implementations can divide the image into block, macroblock, tiles, or other units of other size and structure.
[0231 A "forward overlap" operator 240 is applied to each edge between blocks, after which each 4x4 block is transformed using a block transform 250. This block transform 250 can be the reversible, scale-free 2D transform described by Srinivasan, U.S. Patent Application No. 11/015,707, entitled, "Reversible Transform For Lossy And Lossless 2-D Data Compression," filed December 17, 2004. The overlap operator 240 can be the reversible overlap operator described by Tu et al., U.S. Patent Application No. 11/015,148, entitled, "Reversible Overlap Operator for Efficient Lossless Data

Compression," filed December 17, 2004; and by Tu et a!., U.S. Patent Application No. 11/035,991, entitled, "Reversible 2-Dimensional Pre-ZPost-Filtering For Lapped Biorthogonal Transform," filed January 14, 2005. Alternatively, the discrete cosine transform or other block transforms and overlap operators can be used. Subsequent to the transform, the DC coefficient 260 of each 4^4 transform block is subject to a similar processing chain (tiling, forward overlap, followed by 4x4 block transform). The resulting DC transform coefficients and the AC transform coefficients are quantized 270, entropy coded 280 and packetized 290.
[024] The decoder performs the reverse process. On the decoder side, the transform coefficient bits are extracted 310 from their respective packets, from which the coefficients are themselves decoded 320 and dequantized 330. The DC coefficients 340 are regenerated by applying an inverse transform, and the plane of DC coefficients is "inverse overlapped" using a suitable smoothing operator applied across the DC block edges. Subsequently, the entire data is regenerated by applying the 4x4 inverse transform 350 to the DC coefficients, and the AC coefficients 342 decoded from the bitstream. Finally, the block edges in the resulting image planes are inverse overlap filtered 360. This produces a reconstructed 2D data output.
[02S] In an exemplary implementation, the encoder 200 (Figure 2) compresses an input image into the compressed bitstream 220 (e.g., a file), and the decoder 300 (Figure 3) reconstructs the original input or an approximation thereof, based on whether lossless or lossy coding is employed. The process of encoding involves the application of a forward lapped transform (LT) discussed below, which is implemented with reversible 2-dimensional pre-/post-filtering also described more fully below. The decoding process involves the application of the inverse lapped transform (ILT) using the reversible 2-dimensional pre-/post-filtering.
[026] The illustrated LT and the ILT are inverses of each other, in an exact sense, and therefore can be collectively referred to as a reversible lapped transform. As a reversible transform, the LT/ILT pair can be used for lossless image compression.
[027] The input data 210 compressed by the illustrated encoder 200/decoder 300 can be images of various color formats (e.g., RGB/YUV4:4:4, YUV4:2:2 or YUV4:2:0 color image formats). Typically, the input image always has a luminance (Y) component. If it is a RGBA'UV4:4:4, YUV4:2:2 or YUV4:2:0 image, the image also has chrominance components, such as a U component and a V component. The separate color planes or components of the image can have different spatial resolutions. In case of an input image in

the YUV 4:2:0 color format for example, the U and V components have half of the width and height of the Y component.
[028] As discussed above, the encoder 200 tiles the input image or picture into macroblocks. In an exemplary implementation, the encoder 200 tiles the input image into 16x16 pixel areas (called "macroblocks") in the Y channel (which may be 16x16, 16x8 or 8x8 areas in the U and V channels depending on the color format). Each macrobiock color plane is tiled into 4x4 pixel regions or blocks. Therefore, a macrobiock is composed for the various color formats in the following manner for this exemplary encoder implementation:
1. For a grayscale image, each macrobiock contains 16 4x4 luminance (Y) blocks.
2. For a YUV4:2:0 format color image, each macrobiock contains 16 4x4 Y blocks, and 4 each 4x4 chrominance (U and V) blocks.
3. For a YUV4:2:2 format color image, each macrobiock contains 16 4x4 Y blocks, and 8 each 4x4 chrominance (U and V) blocks.
4. For a RGB or YUV4:4:4 color image, each macrobiock contains 16 blocks each of Y, U and V channels.
[029] Accordingly, after transform, a macrobiock in this representative encoder 200/decoder 300 has three frequency sub bands: a DC sub band (DC macrobiock), a low pass sub band (low pass macrobiock), and a high pass sub band (high pass macrobiock). In the representative system, the low pass and/or high pass sub bands are optional in the bitstream - these sub bands may be entirely dropped.
1030] Further, the compressed data can be packed into the bitstream in one of two orderings: spatial order and frequency order. For the spatial order, different sub bands of the same macrobiock within a tile are ordered together, and the resulting bitstream of each tile is written into one packet. For the frequency order, the same sub band from different macroblocks within a tile are grouped together, and thus the bitstream of a tile is written into three packets: a DC tile packet, a low pass tile packet, and a high pass tile packet. In addition, there may be other data layers.
[0311 Thus, for the representative system, an image is organized in the following "dimensions":
Spatial dimension : Frame —» Tile —> Macrobiock; Frequency dimension : DC | Low pass | High pass; and
Channel dimension: Luminance | Chrominance 0 | Chrominance 1 ... (e.g. as Y | U | V). The arrows above denote a hierarchy, whereas the vertical bars denote a partitioning.

[032] Although the representative system organizes the compressed digital media data in spatial, frequency and channel dimensions, the flexible quantization approach described here can be applied in alternative encoder/decoder systems that organize their data along fewer, additional or other dimensions. For example, the flexible quantization approach can be applied to coding using a larger number of frequency bands, other format of color channels (e.g., YIQ, RGB, etc.), additional image channels (e.g., for stereo vision or other multiple camera arrays).
2. Inverse Core and Lapped Transform
[033] Overview
[034] In one implementation of the encoder 200/decoder 300, the inverse transform
on the decoder side takes the form of a two-level lapped transform. The steps are as follows:
. An Inverse Core Transform (ICT) is applied to each 4x4 block corresponding
to reconstructed DC and lowpass coefficients arranged in a planar array known as the DC plane.
A post filter operation is optionally applied to 4x4 areas evenly straddling
blocks in the DC plane. Further, a post filter is applied to boundary 2x4 and
4x2 areas, and the four 2x2 corner areas are left untouched.
• The resulting array contains DC coefficients of the 4x4 blocks corresponding
to the first-level transform. The DC coefficients are (figuratively) copied into a larger array, and the reconstructed highpass coefficients populated into the remaining positions. An ICT is applied to each 4x4 block.
A post filter operation is optionally applied to 4x4 areas evenly straddling
blocks in the DC plane. Further, a post filter is applied to boundary 2x4 and
4x2 areas, and the four 2x2 comer areas are left untouched.
[035] This process is shown in Figure 4.
[036] The application of post filters is governed by an OVERLAPINFO syntax
element in the compressed bitstream 220. OVERLAPINFO may take on three values:
If OVERLAPJNFO = 0, no post filtering is performed.
If OVERLAPINFO = 1, only the outer post filtering is performed.
. If OVERLAPINFO = 2, both inner and outer post filtering is performed.
(037) Inverse Core Transform

(038) The Core Transform (CT) is inspired by the conventionally known 4x4
Discrete Cosine Transform (DCT), yet it is fundamentally different. The first key difference is that the DCT is linear whereas the CT is nonlinear. The second key difference is that due to the fact that it is defined on real numbers, the DCT is not a lossless operation in the integer to integer space. The CT is defined on integers and is lossless in this space. The third key difference is that the 2D DCT is a separable operation. The CT is non-separable by design.
f039j The entire inverse transform process can be written as the cascade of three
elementary 2^2 transform operations, which are:
2x2 Hadamard transform: T_h
Inverse ID rotate: InvTodd
inverse 2D rotate: InvToddodd
fo4oj These transforms are implemented as non-separable operations and are
described first, followed by the description of the entire ICT.
[0411 2D 2x2 Hadamard Transform T h
[042] The encoder/decoder implements the 2D 2x2 Hadamard transform T_h as
shown in the following pseudo-code table. R is a rounding factor which may take on the value 0 or I only. T_h is involutory (i.e. two applications of T_h on a data vector [abed] succeed in recovering the original values of [a b c d], provided R is unchanged between the applications). The inverse T_h is T_h itself.
[043] Inverse ID Rotate InvT odd
[044] The lossless inverse of Todd is defined by the pseudocode in the following
table.

invisible to the rest of the processes. Further, the quantization levels are scaled accordingly such that a stream created with the primary machine precision and decoded using the secondary machine precision (and vice versa) produces an acceptable image.
[068] The secondary machine precision cannot be used when lossless compression
is desired. The machine precision used in creating a compressed file is explicitly marked in the header.
to69] The secondary machine precision is equivalent to using scaled arithmetic in
the codec, and hence this mode is referred to as Scaled. The primary machine precision is referred to as Unsealed.
[0701 The example encoder/decoder is designed to provide good encoding and
decoding speed. A design goal of the example encoder/decoder is that the data values on both encoder and decoder do not exceed 16 signed bits for an 8 bit input. (However, intermediate operation within a transform stage may exceed this figure.) This holds true for both modes of machine precision.
[07X] Conversely, when the secondary machine precision is chosen, the range
expansion of the intermediate values is by 8 bits. Since the primary machine precision avoids a pre-multiplication by 8, its range expansion is 8 - 3 = 5 bits.
[072] The first example encoder/decoder uses two different word lengths for
intermediate values. These word lengths are 16 and 32 bits.
[0731 Second Example Bitstream Syntax and Semantics
[0741 The second example bitstream syntax and semantics is hierarchical and is
comprised of the following layers: Image, Tile, Macroblock and Block.

Image (IMAGE) IMAGE 0{
IMAGE_HEADER bAlphaPlane = FALSE IMAGE_PLANE_HEADER if (ALPHACHANNEL_FLAG) { bAlphaPlane = TRUE IMAGE_PLANE_HEADER }

bits

Num
Variable
Variable
Variable

Descriptor
struct
struct
Struct

INDEX_TABLE TILE

Variable Variable

struct struct

}

32 32
Image Header (IMAGE_HEADER) IMAGE_HEADER (){
GDISIGNATURE RESERVED! RESERVED2 TILING_FLAG
FRE0UENCYMODE_BITSTREAM_FLAG IMAGE_ORIENTATION
INDEXTABLE_PRESENT_FLAG OVERLAPJNFO SHORT_HEADER_FLAG LONG_WORD_FLAG WINDOWING_FLAG TRIM_FLEXBITS_FLAG RESERVED3
ALPHACHANNEL_FLAG SOURCE_CLR_FMT SOURCE_BITDEPTH If (SHORT_HEADER_FLAG) {
WIDTH_MINUS1
HEIGHT_MINUS1
} else {
WIDTH_MINUS1
HEIGHT_MINUS1 }

bits

Num
Descriptor

64 uimsbf
4 uimsbf
4 uimsbf
1 bool
1 uimsbf
3 uimsbf
1 uimsbf
2 uimsbf
1 bool
1 bool
1 bool
1 bool
3 uimsbf
1 bool
4 uimsbf
4 uimsbf
16 uimsbf
16 uimsbf
uimsbf uimsbf

if (TILING_FLAG) {
NUM_VERT_TILES_MINUS 1 12 uimsbf
12 uimsbf
NUM_HORIZ_TILES_MINUS 1
}
for (n = 0; n <


NUM_VERT_TILES_MINUS1; n-H-) {
If(SHORT_HEADER_FLAG)
8 uimsbf
WIDTH IN MB OF TILE MINUS l[n]
else
16 uimsbf
WIDTH IN MB OF TILE MINUS l[n]
}
for (n = 0; n <


NUM_H0RIZ_TILES_MINUS1; n++) {
If(SHORT_HEADER_FLAG)
8 uimsbf
HEIGHT IN MB OF TILE MINUS![n]
else
16 uimsbf
HEIGHT IN MB OF TILE MINUS ![n]
}
if (WINDOWING_FLAG) {


NUM_TOP_EXTRAPIXELS 6 uimsbf
NUM_LEFT_EXTRAPIXELS 6 uimsbf
6 uimsbf
NUM_BOTTOM_EXTRAPIXELS
NUM_RIGHT_EXTRAPIXELS }
1 6 uimsbf
} IMAGE_PLANE_HEADER () { Num bits

CLR_FMT
NO_SCALED_FLAG
BANDS_PRESENT
if (CLR_FMT== YUV444) {
CHROMACENTERING
COLOR_INTERPRETATION
}
Else if (CLR_FMT == NCHANNEL) {
NUM_CHANNELS_MINUS 1
COLOR_INTERPRETATION
}
if (SOURCE_CLR_FMT == BAYER) {
BAYER_PATTERN
CHROMA_CENTERING_BAYER
COLOR_INTERPRETATION
}
if(SOURCE_BrTDEPTH e {BD16,BD16S,BD32,BD32S}) { SHIFT_BITS
}
if (SOURCE_BITEPTH == BD32F) {
LEN_MANTISSA
EXP_BIAS
} DC_FRAME_UNIFORM
if (DC_FRAME_UNIFORM) {
DC_QP()
}
if (BANDS_PRESENT != SB_DC_ONLY) { USE_DC_QP
if (USE_DC_OP == FALSE) { LP_FRAME_UNIFORM if (LP_FRAME_lJNrFORM) { NUM_LP_QPS = 1

3 uimsbf
1 boo!
4 uimsbf
4 uimsbf
4 uimsbf
4 4
uimsbf uimsbf

2 uimsbf
2 uimsbf
4 uimsbf
8 uimsbf
8 uimsbf
8 uimsbf
1 bool
variable struct
1 boo!
1 bool

LP_QP()

variable struct

}

}
if (BANDS_PRESENT != SB_NO_HIGHPASS) { USE_LP_QP
if(USE_LP_QP== FALSE) { HP_FRAME_UNIFORM if (HP_FRAME_UNIFORM) { NUM_HP_OPS = 1 HP„QP() } } }

boo I
boo I
variable struct

}

FLUSH BYTE

variable

1075) Some selected bitstream elements from the second example bitstream syntax
and semantics are defined below.
1076] Long Word Flag (LONG_WORD_FLAG) {1 bit)
(0771 LONGWORDFLAG is a I-bit syntax element and specifies whether 16-
bit integers may be used for transform computations. In this second example bitstream syntax, if LONG_WORD_FLAG = = 0 (FALSE), 16-bit integer numbers and arrays may be used for the outer stage of transform computations (intermediate operations within the transform (such as (3*a+l)»l) are performed with higher accuracy). If LONG_WORD_FLAG = = TRUE, 32-bit integer numbers and arrays shall be used for transform computations.
[078] Note: 32-bit arithmetic may be used to decode an image regardless of the
value of LONGWORDFLAG. This syntax element can be used by the decoder to choose the most efficient word length for implementation.
(0791 No Scaled Arithmetic Flag (N0_SCALED_FLAG)(1 bit)
(0801 NOSCALEDFLAG is a 1-bit syntax element that specifies whether the
transform uses scaling. If NOSCALEDFLAG == 1, scaling shall not be performed. If

NOSCALEDFLAG == 0, scaling shall be used. In this case, scaling shall be performed by appropriately rounding down the output of the final stage (color conversion) by 3 bits.
to8i] Note: NO_SCALED_FLAG shall be set to TRUE if lossless coding is
desired, even if lossless coding is used for only a subregion of an image. Lossy coding may use either mode.
[0821 Note: The rate-distortion performance for lossy coding is superior when
scaling is used (i.e. NO_SCALED_FLAG == FALSE), especially at low QPs.
4. Signaling and Use of Long Word Flag
[083] One example image format for the representative encoder/decoder supports a
wide range of pixel formats, including high dynamic range and wide gamut formats. Supported data types include signed integer, unsigned integer, fixed-point float and floating¬point float. Supported bit depths include eight, 16, 24 and 32 bits per color channel. The example image format allows for lossless compression of images that use up to 24 bits per color channel, and lossy compression of images that use up to 32 bits per color channel.
[084] At the same time, the example image format has been designed to provide
high quality images and compression efficiency and allow low-complexity encoding and decoding implementations.
[085] To support low-complexity implementation, the transform in an example
image format has been designed to minimize expansion in dynamic range. The two-stage transform increases dynamic range by only five bits. Therefore, if the image bit depth is eight bits per color channel, 16 bit arithmetic may be sufficient for performing all transform operations at the decoder. For other bit depths, higher precision arithmetic may be needed for transform operations.
[086] The computational complexity of decoding a particular bitstream can be
reduced if the precision required for performing transform operations is known at the decoder. This information can be signaled to a decoder using a syntax element (e.g., a 1-bit flag in an image header). Described signaling techniques and syntax elements can reduce computational complexity in decoding bitstreams.
[0871 In one example implementation, the I-bit syntax element
LONG_WORD_FLAG is used. For example, if LONG_WORD_FLAG - = FALSE, 16-bit integer numbers and arrays may be used for the outer stage of transform computations, and if LONG_WORD_FLAG == TRUE, 32 bit integer numbers and arrays shall be used for transform computations.

[089] In the one implementation of the representative encoder/decoder, the in-place
transform operations may be performed on 16-bit wide words, but intermediate operations within the transform (such as computation of the product 3*a for a "lifting" step given by b += (3*a+l)»l) ) are performed with higher accuracy (e.g., 18 bits or higher precision). However, in this example, the intermediate transform values a and b themselves may be stored in 16-bit integers.
[089] 32-bit arithmetic may be used to decode an image regardless of the value of
the LONG_WORD_FLAG element. The LONGWORDFLAG element can be used by the encoder/decoder to choose the most efficient word length for implementation. For example, an encoder may choose to set the LONG WORDFLAG element to FALSE if it can verify that the 16-bit and 32-bit precision transform steps produce the same output value.
5. Signaling and Use of NO_SCALED_FLAG
1090] One example image format for the representative encoder/decoder supports a
wide range of pixel formats, including high dynamic range and wide gamut formats. At the same time, the design of the representative encoder/decoder optimizes image quality and compression efficiency and enables low-complexity encoding and decoding implementations.
[091] As discussed above, the representative encoder/decoder uses two stage
hierarchical block-based transform, where all the transform steps are integer operations. The small rounding errors present in these integer operations result in loss of compression efficiency during lossy compression. To combat this problem, one implementation of the representative encoder/decoder defines two different precision modes for decoder operations: the scaled mode and the unsealed mode.
[092] In the scaled precision mode, the input image is pre multiplied by 8 (i.e. left
shifted by 3 bits) at the encoder, and the final output at the decoder is divided by 8 with rounding (i.e. right shifted by 3 bits). Operation in the scaled precision mode minimizes the rounding errors, and results in improved rate-distortion performance.
to93] In the unsealed precision mode, there is no such scaling. An encoder or
decoder operating in unsealed precision mode has to deal with a smaller dynamic range for transform coefficients, and thus has lower computational complexity. However, there is a small penalty in compression efficiency for operating in this mode. Lossless coding (with

no quantization, i.e. setting the Quantization Parameter or QP to 1) can only use the unsealed precision mode for guaranteed reversibility.
10941 The precision mode used by the encoder in creating a compressed file is
explicitly signaled in the image header of the compressed bitstream 220 (Figure 2) using the NO_SCALED_FLAG. It is recommended that the decoder 300 use the same precision mode for its operations.
[095] NO_SCALED_FLAG is a 1-bit syntax element in the image header that
specifies the precision mode as follows:
[0961 If NO_SCALED_FLAG == TRUE, unsealed mode should be used for
decoder operation.
[097] If NOSCALEDFLAG == FALSE, scaling should be used. In this case,
scaled mode should be used for operation by appropriately rounding down the output of the final stage (color conversion) by 3 bits.
10981 The rate-distortion performance for lossy coding is superior when unsealed
mode is used (i.e. NOSCALEDFLAG == FALSE), especially at low QPs. However, the computation complexity is lower when unsealed mode is used due to two reasons:
[099] Smaller dynamic range expansion in the unsealed mode means that shorter
words may be used for transform computations, especially in conjunction with the "LONGWORDFLAG." In VLSI implementations, the reduced dynamic range expansion means that the gate logic implementing the more significant bits may be powered down.
[0100] The scaled mode requires an add and right bit shift by 3 bits (implementing a rounded divide by 8) on the decoder side. On the encoder side, it requires a left bit shift by 3 bits. This is slightly more computationally demanding than the unsealed mode overall.
(01011 Further, the unsealed mode allows for the compression of more significant bits than does the scaled mode. For instance, the unsealed mode permits the lossless compression (and decompression) of up to 27 significant bits per sample, using 32 bit arithmetic. In contrast, the scaled mode allows the same for only 24 bits. This is because of the three additional bits of dynamic range introduced by the scaling process.
C01021 The data values on decoder do not exceed 16 signed bits for an 8 bit input for both modes of precision. (However, intermediate operation within a transform stage may exceed this figure.)
[01031 Note: NO_SCALED_FLAG is set to TRUE by the encoder, if lossless coding (QP=1) is desired, even if lossless coding is required for only a subregion of an image.

[01041 The encoder may use either mode for lossy compression. It is recommended that the decoder use the precision mode signaled by NOSCALED MODE for its operations. However, the quantization levels are scaled such that a stream created with the scaled precision mode and decoded using the unsealed precision mode (and vice versa) produces an acceptable image in most cases.
6. Scaling Arithmetic For Increased Accuracy
(0105) in one implementation of the representative encoder/decoder, the transforms (including color conversion) are integer transforms and implemented through a series of lifting steps. In those lifting steps, truncation errors hurt transform performance. For lossy compression cases, to minimize the damage of truncation errors and thus maximize transform performance, input data to a transform needs to be left shifted several bits. However, another highly desired feature is if the input image is 8 bits, then the output of every transform should be within 16 bits. So the number of left shift bits cannot be large. The representative decoder implements a technique of scaling arithmetic to achieve both goals. The scaling arithmetic technique maximizes transform performance by minimizing damage of truncation errors, and still limits output of each transform step to be within 16 bits if input image is 8 bits. This makes simple 16-bit implementation possible.
(oiosi The transforms utilized in the representative encoder/decoder are integer transforms and implemented by lifting steps. Most lifting steps involve a right shift, which introduces truncation errors. A transform generally involves many lifting steps, and accumulated truncation errors hurt transform performance visibly.
[0107] One way to reduce the damage of truncation errors is to left shift the input data before the transform in the encoder, and right shift the same number of bits after transform (combined with quantization) at the decoder. As described above, the representative encoder/decoder has a two-stage transform structure: optional first stage overlap + first stage CT + optional second stage overlap + second stage CT. Experiments show that left shift by 3 bits is necessary to minimize the truncation errors. So in lossy cases, before color conversion, input data may be left shifted by 3 bits, i.e. multiplied or scaled by a factor of 8 (e.g., for the scaled mode described above).
(0108) However, color conversion and transforms expand data. If input data is shifted by 3 bits, the output of second stage 4x4 OCT has a 17-bit dynamic range if input data is 8 bits (output of every other transform is still within 16 bits). This is hugely undesired since it prevents 16-bit implementation, a highly desired feature. To get around

this, before the second stage 4 x 4 CT, the input data is right shifted by 1 bit and so the output is also within 16 bits. Since the second stage 4 x 4 CT applies to only 1/16 of the data (the DC transform coefficients of the first stage DCT), and the data is already scaled up by first stage transform, so the damage of truncation errors here is minimal.
[0109] So in lossy cases for 8-bit images, on encoder side, input is left shifted by 3 bits before color conversion, and right shifted 1 bit before second stage 4x4 CT. On the decoder side, the input is left shifted by 1 bit before first stage 4x4 IDCT, and right shifted by 3 bits after color conversion.
7. Computing Environment
[0110) The above-described processing techniques for computational complexity and precision signaling in a digital media codec can be realized on any of a variety of digital media encoding and/or decoding systems, including among other examples, computers (of various form factors, including server, desktop, laptop, handheld, etc.); digital media recorders and players; image and video capture devices (such as cameras, scanners, etc.); communications equipment (such as telephones, mobile phones, conferencing equipment, etc.); display, printing or other presentation devices; and etc. The computational complexity and precision signaling techniques in a digital media codec can be implemented in hardware circuitry, in firmware controlling digital media processing hardware, as well as in communication software executing within a computer or other computing environment, such as shown in Figure 6.
[0111] Figure 6 illustrates a generalized example of a suitable computing environment (600) in which described embodiments may be implemented. The computing environment (600) is not intended to suggest any limitation as to scope of use or functionality of the invention, as the present invention may be implemented in diverse general-purpose or special-purpose computing environments.
[0112] With reference to Figure 6, the computing environment (600) includes at least one processing unit (610) and memory (620). In Figure 6, this most basic configuration (630) is included within a dashed line. The processing unit (610) executes computer-executable instructions and may be a real or a virtual processor. In a multi¬processing system, multiple processing units execute computer-executable instructions to increase processing power. The memory (620) may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of the two. The memory (620) stores software (680) implementing the

described digital media encoding/decoding with computational complexity and precision signaling techniques.
[0113] A computing environment may have additional features. For example, the computing environment (600) includes storage (640), one or more input devices (650), one or more output devices (660), and one or more communication connections (670). An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing environment (600). Typically, operating system software (not shown) provides an operating environment for other software executing in the computing environment (600), and coordinates activities of the components of the computing environment (600).
[0114] The storage (640) may be removable or non-removable, and includes magnetic disks, magnetic tapes or cassettes, CD-ROMs, CD-RWs, DVDs, or any other medium which can be used to store information and which can be accessed within the computing environment (600). The storage (640) stores instructions for the software (680) implementing the described digital media encoding/decoding with computational complexity and precision signaling techniques.
[0115] The input device(s) (650) may be a touch input device such as a keyboard, mouse, pen, or trackball, a voice input device, a scanning device, or another device that provides input to the computing environment (600). For audio, the input device(s) (650) may be a sound card or similar device that accepts audio input in analog or digital form from a microphone or microphone array, or a CD-ROM reader that provides audio samples to the computing environment. The output device(s) (660) may be a display, printer, speaker, CD-writer, or another device that provides output from the computing environment (600).
[0116J The communication connection(s) (670) enable communication over a communication medium to another computing entity. The communication medium conveys information such as computer-executable instructions, compressed audio or video information, or other data in a modulated data signal. A modulated data signal is a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media include wired or wireless techniques implemented with an electrical, optical, RF, infrared, acoustic, or other carrier.
[0117] The described digital media encoding/decoding with flexible quantization techniques herein can be described in the general context of computer-readable media.

Computer-readable media are any available media that can be accessed within a computing environment. By way of example, and not limitation, with the computing environment (600), computer-readable media include memory (620), storage (640), communication media, and combinations of any of the above.
roiis] The described digital media encoding/decoding with computational complexity and precision signaling techniques herein can be described in the general context of computer-executable instructions, such as those included in program modules, being executed in a computing environment on a target real or virtual processor. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Computer-executable instructions for program modules may be executed within a local or distributed computing environment.
(0119) For the sake of presentation, the detailed description uses terms like "determine," "generate," "adjust," and "apply" to describe computer operations in a computing environment. These terms are high-level abstractions for operations performed by a computer, and should not be confused with acts performed by a human being. The actual computer operations corresponding to these terms vary depending on implementation.
[0120] In view of the many possible embodiments to which the principles of our invention may be applied, we claim as our invention all such embodiments as may come within the scope and spirit of the following claims and equivalents thereto.

We claims:
1. A digital media decoding method comprising: receiving a compressed digital media bitstream at a digital media decoder; parsing a syntax element from the bitstream signaling a degree of arithmetic precision to use for transform computations during processing of the digital media data; and outputting a reconstructed image.
2. The digital media decoding method of claim 1 wherein the syntax element signals to use one of a high arithmetic precision or a low arithmetic precision.
3. The digital media decoding method of claim 2 wherein the high arithmetic precision is 32-bit number processing, and the low arithmetic precision is 16-bit number processing.
4. The digital media decoding method of claim 2 further comprising:
decoding blocks of transform coefficients from the compressed digital media
bitstream;
in the case that the syntax element signals use of the high arithmetic precision, applying an inverse transform to the transform coefficients using high arithmetic precision processing; and
in the case that the syntax element signals use of the low arithmetic precision, applying an inverse transform to the transform coefficients using low arithmetic precision processing.
5. The digital media decoding method of claim 4 wherein the high arithmetic
precision is 32-bit number processing, and the low arithmetic precision is 16-bit number
processing.
6. The digital media decoding method of claim 2 further comprising:
decoding blocks of transform coefficients from the compressed digital media
bitstream;

applying an inverse transform to the transform coefficients using high arithmetic precision processing regardless of the degree of arithmetic precision signaled via the syntax element.
7. A digital media encoding method comprising:
receiving digital media data at a digital media encoder;
making a decision whether to use lower precision arithmetic for transform computations during processing of the digital media data;
representing the decision whether to use the lower precision arithmetic for transform computations with a syntax element in an encoded bitstream, wherein the syntax element is operable to communicate the decision to a digital media decoder; and
outputting the encoded bitstream.
8. The digital media encoding method of claim 7 wherein said making a
decision comprises:
verifying whether the lower precision arithmetic for transform computations produces a same decoder output as using a higher precision arithmetic for transform computations; and
deciding whether to use the lower precision arithmetic based upon said verifying.
9. The digital media encoding method of claim 7 wherein said lower precision arithmetic is a 16-bit arithmetic precision.
10. The digital media encoding method of claim 7 further comprising:
making a decision whether to apply a scaling of the input digital media data prior to transform coding; and
representing the decision whether to apply the scaling with a syntax element in the encoded bitstream.
11. The digital media encoding method of claim 10 wherein said making a decision whether to apply a scaling comprises deciding not to apply scaling of the input digital media data when losslessly encoding the digital media data.
12. A digital media decoding method comprising:

receiving a compressed digital media bitstream at a digital media decoder;
parsing a syntax element from the bitstream signaling choice of precision modes for transform computations during processing of the digital media data;
in the case that a first precision mode using scaling is signaled, scaling output of the decoder;
in the case that a second precision mode without scaling is signaled, omitting to apply scaling of the output; and
outputting a reconstructed image.
13. The digital media decoding method of claim 12 wherein said scaling output of the decoder comprises rounded division of the output by a number.
14. The digital media decoding method of claim 12 wherein said rounded division of the output is a rounded division by the number 8.
15. The digital media decoding method of claim 12 further comprising:
parsing a second syntax element from the bitstream signaling whether to use a lower
arithmetic precision for transform computations during processing of the digital media data;
decoding blocks of transform coefficients from the compressed digital media bitstream; and
in the case that the second precision mode without scaling and the use of lower arithmetic precision are signaled, performing inverse transform processing of the transform coefficients using the lower arithmetic precision.
16. The digital media decoding method of claim 15 wherein said lower arithmetic precision is a 16-bit arithmetic precision.
17. The digital media decoding method of claim 12 wherein the digital media data is encoding using a two stage transform structure having a first stage transform followed by a second stage transform on DC coefficients of the first stage transform, the digital media decoding method further comprising:
decoding digital media data from the compressed digital media bitstream; applying an inverse second stage transform to the digital media data; applying an inverse first stage transform to the digital media data;

performing color conversion of the digital media data; and
wherein said scaling output of the decoder in the case that the first precision mode using scaling is signaled, comprises:
left shifting the digital media data by a single bit before input to the inverse first stage transform; and
right shifting the digital media data by three bits after the color conversion.
18. The digital media decoding method of claim 12 wherein said compressed digital media bitstream is encoded according to a syntax scheme defining separate primary image plane and alpha image plane for an image, the syntax element signaling choice of precision mode being signaled per image plane, whereby the precision mode of the primary image plane and the alpha image plane are independently signaled, and the decoding method comprises performing said actions of parsing the syntax element signaling choice of precision mode for each image plane, and in the case that the first precision mode using scaling is signaled for a respective image plane, scaling output of the decoder for the respective image plane.

Documents

Application Documents

# Name Date
1 4796-CHENP-2009-RELEVANT DOCUMENTS [15-09-2023(online)].pdf 2023-09-15
1 abs 4796-chenp-2009 abstract 13-08-2009.jpg 2009-08-13
2 4796-CHENP-2009-RELEVANT DOCUMENTS [26-09-2022(online)].pdf 2022-09-26
2 4796-chenp-2009 power of attorney 13-08-2009.pdf 2009-08-13
3 4796-CHENP-2009-RELEVANT DOCUMENTS [22-09-2021(online)].pdf 2021-09-22
3 4796-chenp-2009 pct search report 13-08-2009.pdf 2009-08-13
4 4796-CHENP-2009-RELEVANT DOCUMENTS [27-03-2020(online)].pdf 2020-03-27
4 4796-chenp-2009 pct 13-08-2009.pdf 2009-08-13
5 4796-CHENP-2009-RELEVANT DOCUMENTS [28-05-2019(online)].pdf 2019-05-28
5 4796-chenp-2009 form-5 13-08-2009.pdf 2009-08-13
6 4796-CHENP-2009-RELEVANT DOCUMENTS [28-03-2019(online)].pdf 2019-03-28
6 4796-chenp-2009 form-3 13-08-2009.pdf 2009-08-13
7 4796-CHENP-2009-RELEVANT DOCUMENTS [14-03-2019(online)].pdf 2019-03-14
7 4796-chenp-2009 form-2 13-08-2009.pdf 2009-08-13
8 4796-CHENP-2009-RELEVANT DOCUMENTS [28-03-2018(online)].pdf 2018-03-28
8 4796-chenp-2009 form-1 13-08-2009.pdf 2009-08-13
9 4796-CHENP-2009-RELEVANT DOCUMENTS [15-03-2018(online)].pdf 2018-03-15
9 4796-chenp-2009 drawings 13-08-2009.pdf 2009-08-13
10 4796-chenp-2009 descrption(complete) 13-08-2009.pdf 2009-08-13
10 4796-CHENP-2009-PatentCertificateCoverLetter.pdf 2017-05-15
11 4796-chenp-2009 correspondence others 13-08-2009.pdf 2009-08-13
11 Abstract_Granted 283313_15-05-2017.pdf 2017-05-15
12 4796-chenp-2009 claims 13-08-2009.pdf 2009-08-13
12 Claims_Granted 283313_15-05-2017.pdf 2017-05-15
13 4796-chenp-2009 abstract 13-08-2009.pdf 2009-08-13
13 Description_Granted 283313_15-05-2017.pdf 2017-05-15
14 4796-chenp-2009 form-3 11-02-2010.pdf 2010-02-11
14 Drawings_Granted 283313_15-05-2017.pdf 2017-05-15
15 4796-chenp-2009 form-18 13-01-2011.pdf 2011-01-13
15 Abstract [04-01-2017(online)].pdf 2017-01-04
16 4796-chenp-2009 correspondence others 13-01-2011.pdf 2011-01-13
16 Claims [04-01-2017(online)].pdf 2017-01-04
17 4796-CHENP-2009 FORM-6 26-02-2015.pdf 2015-02-26
17 Correspondence [04-01-2017(online)].pdf 2017-01-04
18 Description(Complete) [04-01-2017(online)].pdf 2017-01-04
18 MTL-GPOA - KONPAL.pdf 2015-03-13
19 MS to MTL Assignment.pdf 2015-03-13
19 Description(Complete) [04-01-2017(online)].pdf_117.pdf 2017-01-04
20 Examination Report Reply Recieved [04-01-2017(online)].pdf 2017-01-04
20 FORM-6-1301-1400(KONPAL).26.pdf 2015-03-13
21 4796-CHENP-2009-FER.pdf 2016-09-08
21 Other Document [04-01-2017(online)].pdf 2017-01-04
22 Other Document [02-01-2017(online)].pdf 2017-01-02
22 Petition Under Rule 137 [02-01-2017(online)].pdf 2017-01-02
23 Other Document [02-01-2017(online)].pdf 2017-01-02
23 Petition Under Rule 137 [02-01-2017(online)].pdf 2017-01-02
24 4796-CHENP-2009-FER.pdf 2016-09-08
24 Other Document [04-01-2017(online)].pdf 2017-01-04
25 FORM-6-1301-1400(KONPAL).26.pdf 2015-03-13
25 Examination Report Reply Recieved [04-01-2017(online)].pdf 2017-01-04
26 Description(Complete) [04-01-2017(online)].pdf_117.pdf 2017-01-04
26 MS to MTL Assignment.pdf 2015-03-13
27 Description(Complete) [04-01-2017(online)].pdf 2017-01-04
27 MTL-GPOA - KONPAL.pdf 2015-03-13
28 4796-CHENP-2009 FORM-6 26-02-2015.pdf 2015-02-26
28 Correspondence [04-01-2017(online)].pdf 2017-01-04
29 4796-chenp-2009 correspondence others 13-01-2011.pdf 2011-01-13
29 Claims [04-01-2017(online)].pdf 2017-01-04
30 4796-chenp-2009 form-18 13-01-2011.pdf 2011-01-13
30 Abstract [04-01-2017(online)].pdf 2017-01-04
31 4796-chenp-2009 form-3 11-02-2010.pdf 2010-02-11
31 Drawings_Granted 283313_15-05-2017.pdf 2017-05-15
32 4796-chenp-2009 abstract 13-08-2009.pdf 2009-08-13
32 Description_Granted 283313_15-05-2017.pdf 2017-05-15
33 4796-chenp-2009 claims 13-08-2009.pdf 2009-08-13
33 Claims_Granted 283313_15-05-2017.pdf 2017-05-15
34 4796-chenp-2009 correspondence others 13-08-2009.pdf 2009-08-13
34 Abstract_Granted 283313_15-05-2017.pdf 2017-05-15
35 4796-chenp-2009 descrption(complete) 13-08-2009.pdf 2009-08-13
35 4796-CHENP-2009-PatentCertificateCoverLetter.pdf 2017-05-15
36 4796-chenp-2009 drawings 13-08-2009.pdf 2009-08-13
36 4796-CHENP-2009-RELEVANT DOCUMENTS [15-03-2018(online)].pdf 2018-03-15
37 4796-CHENP-2009-RELEVANT DOCUMENTS [28-03-2018(online)].pdf 2018-03-28
37 4796-chenp-2009 form-1 13-08-2009.pdf 2009-08-13
38 4796-CHENP-2009-RELEVANT DOCUMENTS [14-03-2019(online)].pdf 2019-03-14
38 4796-chenp-2009 form-2 13-08-2009.pdf 2009-08-13
39 4796-CHENP-2009-RELEVANT DOCUMENTS [28-03-2019(online)].pdf 2019-03-28
39 4796-chenp-2009 form-3 13-08-2009.pdf 2009-08-13
40 4796-CHENP-2009-RELEVANT DOCUMENTS [28-05-2019(online)].pdf 2019-05-28
40 4796-chenp-2009 form-5 13-08-2009.pdf 2009-08-13
41 4796-CHENP-2009-RELEVANT DOCUMENTS [27-03-2020(online)].pdf 2020-03-27
41 4796-chenp-2009 pct 13-08-2009.pdf 2009-08-13
42 4796-CHENP-2009-RELEVANT DOCUMENTS [22-09-2021(online)].pdf 2021-09-22
42 4796-chenp-2009 pct search report 13-08-2009.pdf 2009-08-13
43 4796-chenp-2009 power of attorney 13-08-2009.pdf 2009-08-13
43 4796-CHENP-2009-RELEVANT DOCUMENTS [26-09-2022(online)].pdf 2022-09-26
44 4796-CHENP-2009-RELEVANT DOCUMENTS [15-09-2023(online)].pdf 2023-09-15
44 abs 4796-chenp-2009 abstract 13-08-2009.jpg 2009-08-13

ERegister / Renewals

3rd: 06 Jul 2017

From 20/02/2010 - To 20/02/2011

4th: 06 Jul 2017

From 20/02/2011 - To 20/02/2012

5th: 06 Jul 2017

From 20/02/2012 - To 20/02/2013

6th: 06 Jul 2017

From 20/02/2013 - To 20/02/2014

7th: 06 Jul 2017

From 20/02/2014 - To 20/02/2015

8th: 06 Jul 2017

From 20/02/2015 - To 20/02/2016

9th: 06 Jul 2017

From 20/02/2016 - To 20/02/2017

10th: 06 Jul 2017

From 20/02/2017 - To 20/02/2018

11th: 15 Jan 2018

From 20/02/2018 - To 20/02/2019

12th: 08 Jan 2019

From 20/02/2019 - To 20/02/2020

13th: 08 Jan 2020

From 20/02/2020 - To 20/02/2021

14th: 05 Jan 2021

From 20/02/2021 - To 20/02/2022

15th: 03 Jan 2022

From 20/02/2022 - To 20/02/2023

16th: 04 Jan 2023

From 20/02/2023 - To 20/02/2024

17th: 19 Feb 2024

From 20/02/2024 - To 20/02/2025

18th: 14 Feb 2025

From 20/02/2025 - To 20/02/2026