Abstract: Systems, methods, and devices for sharpening image data are provided. One example of an image signal processing system includes a YCC processing pipeline that includes luma sharpening logic. The luma sharpening logic may sharpen the luma component while avoiding sharpening some noise. Specifically, a multi-scale unsharp mask filter may obtain unsharp signals by filtering an input luma component, and sharp component determination logic may determine sharp signals representing differences between the unsharp signals and the luma component. Sharp lookup tables may “core” the sharp signals, which may prevent some noise from being sharpened. Output logic may determine a sharpened output luma signal by combining the sharp signals with, for example, luma component or one of the unsharp signals.

Abstract: Systems and methods for processing YCC image data provided. In one example, an electronic device includes memory to store image data in RGB or YCC format and a YCC image processing pipeline to process the image data. The YCC image processing pipeline may include receiving logic configured to receive the image data in RGB or YCC format and color space conversion logic configured to, when the image data is received in RGB format, convert the image data into YCC format. The YCC image processing logic may also include luma sharpening and chroma suppression logic; brightness, contrast, and color adjustment logic; gamma logic; chroma decimation logic; scaling logic; and chroma noise reduction logic.

Abstract: Memory latency tolerance methods and apparatus for maintaining an overall level of performance in block processing pipelines that prefetch reference data into a search window. In a general memory latency tolerance method, search window processing in the pipeline may be monitored. If status of search window processing changes in a way that affects pipeline throughput, then pipeline processing may be modified. The modification may be performed according to no stall methods, stall recovery methods, and/or stall prevention methods. In no stall methods, a block may be processed using the data present in the search window without waiting for the missing reference data. In stall recovery methods, the pipeline is allowed to stall, and processing is modified for subsequent blocks to speed up the pipeline and catch up in throughput. In stall prevention methods, processing is adjusted in advance of the pipeline encountering a stall condition.

Abstract: In the video encoders described herein, blocks of pixels from a video frame may be encoded (e.g., using CAVLC encoding) in a block processing pipeline using wavefront ordering (e.g., in knight's order). Each of the encoded blocks may be written to a particular one of multiple DMA buffers such that the encoded blocks written to each of the buffers represent consecutive blocks of the video frame in scan order. A transcode pipeline may operate in parallel with (or at least overlapping) the operation of the block processing pipeline. The transcode pipeline may read encoded blocks from the buffers in scan order and merge them into a single bit stream (in scan order). A transcoder core of the transcode pipeline may decode the encoded blocks and encode them using a different encoding process (e.g., CABAC). In some cases, the transcoder may be bypassed.

Abstract: A knight's order processing method for block processing pipelines in which the next block input to the pipeline is taken from the row below and one or more columns to the left in the frame. The knight's order method may provide spacing between adjacent blocks in the pipeline to facilitate feedback of data from a downstream stage to an upstream stage. The rows of blocks in the input frame may be divided into sets of rows that constrain the knight's order method to maintain locality of neighbor block data. Invalid blocks may be input to the pipeline at the left of the first set of rows and at the right of the last set of rows, and the sets of rows may be treated as if they are horizontally arranged rather than vertically arranged, to maintain continuity of the knight's order algorithm.

Abstract: A video encoder may include a context-adaptive binary arithmetic coding (CABAC) encode component that converts each syntax element of a representation of a block of pixels to binary code, serializes it, and codes it mathematically, after which the resulting bit stream is output. A lookup table in memory and a context cache may store probability values for supported contexts, which may be retrieved from the table or cache for use in coding syntax elements. Depending on the results of a syntax element coding, the probability value for its context may be modified (e.g., increased or decreased) in the cache and, subsequently, in the table. After coding multiple syntax elements, and based on observed access patterns for probability values, a mapping or indexing for the cache or the table may be modified to improve cache performance (e.g., to reduce cache misses or access data for related contexts using fewer accesses).

Abstract: Block processing pipeline methods and apparatus in which reference data are stored to a memory according to tile formats to reduce memory accesses when fetching the data from the memory. When the pipeline stores reference data from a current frame being processed to memory as a reference frame, the reference samples are stored in macroblock sequential order. Each macroblock sample set is stored as a tile. Reference data may be stored in tile formats for luma and chroma. Chroma reference data may be stored in tile formats for chroma 4:2:0, 4:2:2, and/or 4:4:4 formats. A stage of the pipeline may write luma and chroma reference data for macroblocks to memory according to one or more of the macroblock tile formats in a modified knight's order. The stage may delay writing the reference data from the macroblocks until the macroblocks have been fully processed by the pipeline.

Abstract: The video encoders described herein may make an initial determination to designate a macroblock as a skip macroblock, but may subsequently reverse that decision based on additional information. For example, an initial skip mode decision may be based on aggregate distortion metrics for the luma component of the macroblock (e.g., SAD, SATD, or SSD), then reversed based on an individual pixel difference metric, an aggregate or individual pixel metric for a chroma component of the macroblock, or on the position of the macroblock within a macroblock row. The final skip mode decision may be based, at least in part, on the maximum difference between any pixel in the macroblock (or in a region of interest within the macroblock) and the corresponding pixel in a reference frame. The initial skip mode decision may be made during an early stage of a pipelined video encoding process and reversed in a later stage.

Abstract: Methods and apparatus for configuring multiple components of a subsystem are described. The configuration memory of each of a plurality of components coupled to an interconnect includes a global configuration portion. The configuration memory of one of the components may be designated as a master global configuration for all of the components. A module coupled to the interconnect may receive writes to the components from a configuration source. For each write, the module may decode the write to determine addressing information and check to see if the write is addressed to the master global configuration. If the write is addressed to the master global configuration, the module broadcasts the write to the global configuration portion of each of the components via the interconnect. If the write is not addressed to the master global configuration, the module forwards the write to the appropriate component via the interconnect.

Abstract: Blocks of pixels from a video frame may be encoded in a block processing pipeline using wavefront ordering, e.g. according to knight's order. Each of the encoded blocks may be written to a particular one of multiple buffers such that the blocks written to each of the buffers represent consecutive blocks of the frame in scan order. Stitching information may be written to the buffers at the end of each row. A stitcher may read the rows from the buffers in order and generate a scan order output stream for the frame. The stitcher component may read the stitching information at the end of each row and apply the stitching information to one or more blocks at the beginning of a next row to stitch the next row to the previous row. Stitching may involve modifying pixel(s) of the blocks and/or modifying metadata for the blocks.

Abstract: A block processing pipeline that includes a software pipeline and a hardware pipeline that run in parallel. The software pipeline runs at least one block ahead of the hardware pipeline. The stages of the pipeline may each include a hardware pipeline component that performs one or more operations on a current block at the stage. At least one stage of the pipeline may also include a software pipeline component that determines a configuration for the hardware component at the stage of the pipeline for processing a next block while the hardware component is processing the current block. The software pipeline component may determine the configuration according to information related to the next block obtained from an upstream stage of the pipeline. The software pipeline component may also obtain and use information related to a block that was previously processed at the stage.

Abstract: Methods and apparatus for caching neighbor data in a block processing pipeline that processes blocks in knight's order with quadrow constraints. Stages of the pipeline may maintain two local buffers that contain data from neighbor blocks of a current block. A first buffer contains data from the last C blocks processed at the stage. A second buffer contains data from neighbor blocks on the last row of a previous quadrow. Data for blocks on the bottom row of a quadrow are stored to an external memory at the end of the pipeline. When a block on the top row of a quadrow is input to the pipeline, neighbor data from the bottom row of the previous quadrow is read from the external memory and passed down the pipeline, each stage storing the data in its second buffer and using the neighbor data in the second buffer when processing the block.

Abstract: A block processing pipeline in which blocks are input to and processed according to row groups so that adjacent blocks on a row are not concurrently at adjacent stages of the pipeline. A stage of the pipeline may process a current block according to neighbor pixels from one or more neighbor blocks. Since adjacent blocks are not concurrently at adjacent stages, the left neighbor of the current block is at least two stages downstream from the stage. Thus, processed pixels from the left neighbor can be passed back to the stage for use in processing the current block without the need to wait for the left neighbor to complete processing at a next stage of the pipeline. In addition, the neighbor blocks may include blocks from the row above the current block. Information from these neighbor blocks may be passed to the stage from an upstream stage of the pipeline.

Abstract: Block processing pipeline methods and apparatus in which pixel data from a reference frame is prefetched into a search window memory. The search window may include two or more overlapping regions of pixels from the reference frame corresponding to blocks from the rows in the input frame that are currently being processed in the pipeline. Thus, the pipeline may process blocks from multiple rows of an input frame using one set of pixel data from a reference frame that is stored in a shared search window memory. The search window may be advanced by one column of blocks by initiating a prefetch for a next column of reference data from a memory. The pipeline may also include a reference data cache that may be used to cache a portion of a reference frame and from which at least a portion of a prefetch for the search window may be satisfied.

Abstract: A block processing pipeline in which macroblocks are input to and processed according to row groups so that adjacent macroblocks on a row are not concurrently at adjacent stages of the pipeline. The input method may allow chroma processing to be postponed until after luma processing. One or more upstream stages of the pipeline may process luma elements of each macroblock to generate luma results such as a best mode for processing the luma elements. Luma results may be provided to one or more downstream stages of the pipeline that process chroma elements of each macroblock. The luma results may be used to determine processing of the chroma elements. For example, if the best mode for luma is an intra-frame mode, then a chroma processing stage may determine a best intra-frame mode for chroma and reconstruct the chroma elements according to the best chroma intra-frame mode.

Abstract: A method of signaling additional chroma QP offset values that are specific to quantization groups is provided, in which each quantization group explicitly specifies its own set of chroma QP offset values. Alternatively, a table of possible sets of chroma QP offset values is specified in the header area of the picture, and each quantization group uses an index to select an entry from the table for determining its own set of chroma QP offset values. The quantization group specific chroma QP offset values are then used to determine the chroma QP values for blocks within the quantization group in addition to chroma QP offset values already specified for higher levels of the video coding hierarchy.

Abstract: A method of signaling additional chroma QP offset values that are specific to quantization groups is provided, in which each quantization group explicitly specifies its own set of chroma QP offset values. Alternatively, a table of possible sets of chroma QP offset values is specified in the header area of the picture, and each quantization group uses an index to select an entry from the table for determining its own set of chroma QP offset values. The quantization group specific chroma QP offset values are then used to determine the chroma QP values for blocks within the quantization group in addition to chroma QP offset values already specified for higher levels of the video coding hierarchy.

Abstract: Some embodiments provide a method of operating a device to capture an image of a high dynamic range (HDR) scene. Upon the device entering an HDR mode, the method captures and stores multiple images at a first image exposure level. Upon receiving a command to capture the HDR scene, the method captures a first image at a second image exposure level. The method selects a second image from the captured plurality of images. The method composites the first and second images to produce a composite image that captures the HDR scene. In some embodiments, the method captures multiple images at multiple different exposure levels.

Abstract: The present disclosure generally relates to systems and methods for image data processing. In certain embodiments, an image processing pipeline may compute noise statistics associated with image data by receiving a frame of the image data having a plurality of pixels. The image processing pipeline may then identify a plurality of portions of the frame of the image data such that each portion of the plurality of portions has a flat surface. The image processing pipeline may then calculate a plurality of gradients for each portion of the plurality of portions, determine one or more dominant gradient orientations for each portion of the plurality of portions, and generate a histogram that represents a plurality of dominant gradient orientations that corresponds to the plurality of portions. After generating the histogram, the image processing pipeline may store the histogram, which may represent the noise statistics, in a memory.

Abstract: Various techniques are disclosed for collecting and processing auto-focus statistics data in an image signal processor (ISP). In one embodiment, a statistics collection engine in an ISP front-end processing unit may be configured to collect coarse (based on decimated raw data) and fine auto-focus statistics. Coarse auto-focus statistics may be collected on decimated Bayer RGB data and/or on linear camera luma values. Fine auto-focus statistics may be collected on raw Bayer RGB using a combination of a horizontal filter and edge detector, or may be collected on BayerY data (by applying a 3×1 transform to the raw Bayer RGB data). Edge sums may be accumulated using the filter outputs to determine auto-focus statistics.