Patent Description:
Enabling disclosure for the protected invention is provided with the embodiments described in relation to <FIG>. The other figures, aspects, and embodiments are provided for illustrative purposes and do not represent embodiments of the invention unless when combined with all of the features respectively defined in the independent claims.

Various embodiments described herein relate to image capture devices capable of capture and on-board storage of compressed raw (for example, mosaiced according to a Bayer pattern color filter array or according to another type of color filter array), high resolution (for example, at least <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or ranges of values between any of these resolution levels) video image data. The compressed raw image data can be "raw" in the sense that the video data is not "developed", such that certain image processing image development steps are not performed on the image data prior to compression and storage. Such steps can include one or more of interpolation (for example, de-Bayering or other de-mosaicing), color processing, tonal processing, white balance, and gamma correction. For example, the compressed raw image data can be one or more of mosaiced (for example, not color interpolated, not demosaiced), not color processed, not tonally processed, not white balanced, and not gamma corrected. Rather, such steps can be deferred for after storage, such as for off-board post-processing, thereby preserving creative flexibility instead of than "baking in" particular processing decisions in camera.

The image processing and compression techniques described herein can be implemented in a variety of form factors. For instance, the techniques described herein for compressing and on-board storage of compressed raw image data can be implemented in a relatively small-form factor device, such as a smart phone having an integrated camera (or multiple cameras including front camera(s) and rear camera(s), or a small form factor camera. For instance, the processing techniques according to certain embodiments are tailored for implementation in a small form factor device having relatively limited power budget, processing capability, and physical real estate for incorporation of electronic components, etc. In another example, the compression techniques described herein can be implemented in relatively larger form factor cameras, including digital cinema cameras.

According to certain aspects, an image capture device can be configured to capture raw mosaiced image data, compress the raw image data, and store the image data in on-board memory of the image capture device.

Electronics residing of the image capture device can be configured to, as part of the compression, transform the raw mosaiced image data using a discrete cosine transform (DCT) or another transform (such as a transform that defines a finite sequence of data points in terms of a sum of functions oscillating at different frequencies) to obtain transform coefficients, and compress the transform coefficients. According to some embodiments, the electronics can be configured to perform the compression without using an image frame memory (for example, a dynamic random access memory [DRAM]) that stores a full image frame for processing purposes. For instance, the electronics can compress the transform coefficients using an on-chip first memory (for example, a static random-access memory [SRAM]) that is integrated with an image processing chip (for example, an application specific integrated circuit [ASIC] or field-programmable gate array (FPGA]), and without using any second DRAM or other memory positioned off-chip.

In certain embodiments, the electronics can nonetheless include a DRAM or other second memory off-chip. However, the off-chip memory in such embodiments may used for purposes other than compression of raw video image data, such as for pixel defect correction, addressing pixel pattern noise, or the like. This is unlike existing image capture devices, such as smart phones, which use an off-chip DRAM to perform image compression.

For instance, some existing image capture devices use an off-chip DRAM to calculate motion vectors for H. <NUM> compression. Certain embodiments described herein use DCT techniques, thereby facilitating memory-efficient compression, without the need to calculate motion vectors or use off-chip memory.

Performing compression without use of a full image frame memory (for example, an off-chip DRAM) enhances power efficiency (such as, by around <NUM> Watts (W) in some implementations), which is particularly useful in a small-form factor device such as a smart phone. According to certain aspects, the electronics of the image capture device consume less than <NUM> W or less than about <NUM> W during operation.

Features disclosed herein can, in certain embodiments, provide approaches for decoding as much of a frame as possible in real time and may enable decompression at a rate faster than <NUM> frames per second (fps). Moreover, the approaches can, in some implementations, make extensive use of a Graphical Processing Unit (GPU) of an electronic device and permit significant parallelization of operations while enabling a high image quality to be maintained.

According to some aspects, the image capture device includes a clock configured to control a timing at which the raw mosaiced image data is processed (for instance, compressed) by electronic circuitry, and the electronic circuitry is configured to correctly process the raw mosaiced image data despite the clock stopping for a period of time. This may be at least because the raw mosaiced image data can be processed by the electronic circuitry using memory that may not require refreshing.

According to certain aspects, the image capture device is configured to transform raw mosaiced image data to obtain transform coefficients. The device quantizes the transform coefficients to obtain quantized coefficients, and encodes at least some of the quantized coefficients by performing one or more of the following: dividing each quantized coefficient into a plurality of ranges and values within the plurality of ranges; determining a Huffman code for each quantized coefficient according to an individual range in which each quantized coefficient is included; and determining a Golomb code for each quantized coefficient according to an individual value within the individual range in which each quantized coefficient is included.

In some embodiments, an electronic device is disclosed. The electronic device includes a housing, an image sensor, a memory device, and one or more processors. The image sensor can generate image data from light incident on the image sensor. The one or more processors can: transform the image data using a discrete cosine transform to obtain transform coefficients, quantize the transform coefficients to obtain quantized transform coefficients including a first quantized transform coefficient and a second quantized transform coefficient different from the first quantized transform coefficient, encode the quantized transform coefficients to obtain encoded coefficients, and store the encoded coefficients to the memory device. The quantized transform coefficients can be encoded at least by: determining a first range of a plurality of ranges in which the first quantized transform coefficient is included, determining a second range of the plurality of ranges in which the second quantized transform coefficient is included, determining a first value within the first range to which the first quantized transform coefficient corresponds, determining a second value within the second range to which the second quantized transform coefficient corresponds, encoding, using a first algorithm, the first range as a first range code and the second range as a second range code, and encoding, using a second algorithm different from the first algorithm, the first value as a first value code and the second value as a second value code. The one or more processors vary the first algorithm from processing a first frame of the image data to processing a second frame of the image data, during processing of the image data. The second algorithm remains constant during processing of the image data by the one or more processors. The encoded coefficients are stored to the memory device. The encoded coefficients can include the first range code, the second range code, the first value code, and the second value code.

The electronic device of the preceding paragraph can include one or more of the following features: The first algorithm is a Huffman code, or the second algorithm is a Golomb code. The quantized transform coefficients can include a third quantized transform coefficient different from the first quantized transform coefficient and the second quantized transform coefficient, and the one or more processors can encode the quantized transform coefficients by at least: determining a third range of a plurality of ranges in which the third quantized transform coefficient is included, not determining a third value within the third range to which the third quantized transform coefficient corresponds, and encoding, using the first algorithm, the third range as a third range code, the encoded coefficients comprising the third range code. The discrete cosine transform can be a 16x16 discrete cosine transform. The one or more processors can encode the quantized transform coefficients at least by encoding DC coefficients of the quantized transform coefficients differently from AC coefficients of the quantized transform coefficients. The one or more processors can store a parameter for the first algorithm in a frame header for the encoded coefficients. The one or more processors can quantize the transform coefficients by at least using a first quantization table for green pixels of the image data and a second quantization table for red pixels and blue pixels of the image data, the first quantization table being different from the second quantization table. The image data can be moasiced image data. The image data can be raw moasiced image data. The housing can be a mobile phone housing, and the mobile phone housing can support the image sensor, the memory device, and the one or more processors. The housing can enclose the image sensor, the memory device, and the one or more processors, and the housing can removably attach to a mobile phone. The electronic device can further include a display configured to present holographic images generated by the one or more processors from the image data.

In some embodiments, a method of coding image data using an electronic device is disclosed. The method can include: generating, by an image sensor, image data from light incident on an image sensor; transforming, by one or more processors, the image data using a discrete cosine transform to obtain transform coefficients; quantizing, by the one or more processors, the transform coefficients to obtain quantized transform coefficients including a first quantized transform coefficient and a second quantized transform coefficient different from the first quantized transform coefficient; determining, by the one or more processors, a first range of a plurality of ranges that includes the first quantized transform coefficient and a second range of the plurality of ranges that includes the second quantized transform coefficient; determining, by the one or more processors, a first value within the first range that corresponds to the first quantized transform coefficient and a second value within the second range that corresponds to the second quantized transform coefficient; encoding, by the one or more processors, the first range as a first range code and the second range as a second range code; encoding, by the one or more processors, the first value as a first value code and the second value as a second value code; the second algorithm remaining constant during processing of the image data; varying the first algorithm from processing a first frame of the image data to processing a second frame of the image data, during processing of the image data; and storing the first range code, the second range code, the first value code, and the second value code to the memory device.

The method of the preceding paragraph can include one or more of the following features: The encoding the first and second ranges and the encoding the first and second values can be performed using lossless compression. The encoding the first and second ranges and the encoding the first and second values can be performed using variable length coding. The method can further include: retrieving the first range code, the second range code, the first value code, and the second value code from the memory device; and decoding, by the one or more processors, the first range code, the second range code, the first value code, and the second value code to obtain the first range, the second range, the first value, and the second value. The first range and the second range can be encoded as the first range code and the second range code using a Huffman code, or the first value and the second value can be encoded as the first value code and the second value code using a Golomb code. The transforming the image data can be performed using a 16x16 discrete cosine transform.

While certain embodiments are described with respect to specific resolutions (for example, at least <NUM> or at least <NUM>) or frame rates (for example, at least <NUM> frames per second), such embodiments are not limited to those frame rates or resolution levels. For instance, depending on the embodiment (for example, depending on sensor size) the techniques for on-board storage of compressed raw image data described herein can be capable of achieving resolution levels of at least <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or greater resolution levels, or resolution levels between and inclusive of any of the foregoing resolution levels (for example, between and inclusive of <NUM> and <NUM>). Similarly, depending on the embodiment, the techniques for on-board storage of compressed raw image data described herein can be capable of capturing or storing image data at frame rates of at least <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> or greater fps, or of frame rates between and inclusive of any of the foregoing resolution levels (for example, between and inclusive of <NUM> fps and <NUM> fps).

This disclosure describes, among other features, approaches for compressing video image data, such as raw Bayer data. The approaches desirably can, in certain embodiments, enable compression of the video image data using several lines of on-chip memory and without using a frame memory like DRAM. The compressed size of the video image data can be set and targeted for individual frames and adapted from frame-to-frame. Moreover, the approaches can provide a hardware-friendly implementation that enables a reduction in size and power consumption for devices which compress video image data. As a result, certain features of this disclosure can be particularly desirable for relatively smaller or low-power handheld devices, such as smart phones, where it may be desirable to save high quality video while limiting power consumption and system size. In some embodiments, such techniques can be used to compress fully-processed YUV data rather than raw.

Although the electronic devices described herein may be primarily described in the context of a smart phone, the disclosures are applicable to any of a variety of electronic devices with or without cellphone functionality, including digital still and motion cameras, personal navigation devices, mobile internet devices, handheld game consoles, or devices having any or a combination of the functions or other functions.

<FIG> illustrates a top, front, and left-side perspective view of a phone <NUM> that may implement one or more of the compression techniques or other features described herein. The phone <NUM> can be a smart phone. The front of the phone <NUM> includes a display <NUM>, cameras <NUM> (for instance, four cameras as illustrated), a first speaker grill 13A, and second speaker grills 13B, as well as one or more microphones (not shown). The left side of the phone <NUM> includes a first input <NUM>.

<FIG> illustrates a bottom, rear, and right-side perspective view of the phone <NUM>. The bottom of the phone includes a power input port <NUM>. The left side of the phone <NUM> includes second inputs <NUM>. The back of the phone <NUM> includes second cameras <NUM> (for instance, two cameras as illustrated), a flash <NUM>, a laser focus <NUM>, and a module connector <NUM>.

The display <NUM> can display a variety of applications, functions, and information and may also incorporate touch screen control features.

Each of the first cameras <NUM> and the second cameras <NUM> includes a capability for capturing video image data frames with various or adjustable resolutions and aspect ratios as described herein. The first cameras <NUM> can each generally face the same direction as one another, and the second cameras <NUM> can generally face the same direction as one another.

The first input <NUM> and the second inputs <NUM> can be buttons and receive user inputs from a user of the phone <NUM>. The first input <NUM> can, for example, function as a power button for the phone <NUM> and enable the user to control whether the phone <NUM> is turned on or off. Moreover, the first input <NUM> may serve as a user identification sensor, such as a finger print sensor, that enables the phone <NUM> to determine whether the user is authorized to access the phone <NUM> or one or more features of or files stored on the phone <NUM> or a device coupled to the phone <NUM>. The first input <NUM> can function as a device lock/unlock button, a button to initiate taking of a picture, a button to initiate taking of a video, or select button for the phone <NUM>. The second inputs <NUM> can function as a volume up button and a volume down button for the phone <NUM>. The functionality of the first input <NUM> and the second inputs <NUM> can be configured and varied by the user. Moreover, the side of the phone <NUM> can include scalloped or serrated edges as illustrated in <FIG> and as described in <CIT>.

Notably, the scallop in which the first input <NUM> is positioned may not include serrations while the other scallops may include serrations, which can assist a user with distinguishing the two edges of the phone <NUM> from one another, as well as the first input <NUM> from the second inputs <NUM>.

The phone <NUM> may receive no user inputs to the front of the phone <NUM> except via the display <NUM>, in some embodiments. The front of the phone <NUM> thus may include no buttons, and any buttons may be located on one or more sides of the phone <NUM>. Advantageously, such a configuration can, in certain embodiments, improve the ergonomics of the phone <NUM> (such as by enabling a user to not have to reach down to a front button) and increase an amount of space available for the display <NUM> on the phone <NUM>.

The module connector <NUM> can interchangeably couple with a module and receive power or data from or transmit power or data to the module or one or more other devices coupled to the module. The module can include a camera, a display, a video game controller, a speaker, a battery, an input/output expander, a light, a lens, a projector, and combinations of the same and the like. The module moreover may be stacked to one or more other module to form a series of connected modules coupled to the phone <NUM>, such as described in <CIT>.

The module connector <NUM> can include multiple contacts (for instance, <NUM> contacts in three rows or <NUM> contacts in one row, among other possibilities) that engage with contacts on a corresponding connector of a module to electronically communicate data. The multiple contacts can engage with a spring loaded connector or contacts of the module. In some implementations, the phone <NUM> can magnetically attach to or support the module, and the phone <NUM> and the module can each include magnets that cause the phone <NUM> to be attracted and securely couple. The phone <NUM> and the module can further be coupled in part via a friction fit, interlocking structures, fasteners, mechanical snap surface structures, mechanical latch surface structures, mechanical interference fit surface structures, or the like between one or more portions of the phone <NUM> and one or more portions of the module.

Additional information about coupling of and communicating data between a device and one or more modules can be found in <CIT> and <CIT> and <CIT>.

The dimensions of the phone <NUM> can vary depending on the particular embodiment. For example, the phone <NUM> can be approximately <NUM> high by <NUM> wide by <NUM> thick. In another example, the phone <NUM> can be about <NUM> in height, <NUM> wide and <NUM> thick. In yet another example, the phone <NUM> can be about <NUM> high, by <NUM> wide by <NUM> thick. In yet a further example, the phone <NUM> can be approximately <NUM> high by <NUM> wide by <NUM> thick. The display <NUM>, for instance, can be a <NUM>", <NUM>", <NUM>", <NUM>", <NUM>", <NUM>", <NUM>", <NUM>", or <NUM>" display.

<FIG> illustrates a side view of the phone <NUM> positioned for attachment to a camera module <NUM>, and <FIG> illustrates a perspective view of the phone <NUM> and the camera module <NUM> when attached. The camera module <NUM>, alone or in combination with the phone <NUM>, can implement one or more of the compression techniques or other features described herein. The camera module <NUM> can include a housing that supports magnets 34A and 34B and an input <NUM>. The magnets 34A and 34C can facilitate coupling of the housing to the phone <NUM>. The input <NUM> can be used to receive user inputs to the camera module <NUM> to control activities of the camera module <NUM> like changing of a mode or initiating capture of video. Although not illustrated in <FIG>, the camera module <NUM> can also include magnets on an opposite side of the housing of the camera module <NUM> from the side shown in <FIG> to couple the opposite side to the housing of the phone <NUM>.

The camera module <NUM> can further couple to an optical module <NUM> that may be interchangeable with one or more other optical modules. The optical module <NUM> can, for example, include one or more optical elements such as lenses, shutters, prisms, mirrors, irises, or the like to form an image of an object at a targeted location. Embodiments of camera modules and optical modules and approaches for coupling the camera modules and optical modules are further described in <CIT>.

The optical module <NUM> can include a removable lens <NUM> and a lens mount <NUM>, where the lens <NUM> may be inserted into an opening (not shown) of the lens mount <NUM>, and then rotated to secure the lens in place. In one embodiment, the lens mount <NUM> can include a button or other type of control, allowing for removal of the lens <NUM>. For instance, the user can push or otherwise interact with an interface element which allows the user to rotate the lens <NUM> in the opposite direction and remove the lens <NUM> from the opening of the lens mount <NUM>. In some embodiments, the lens mount <NUM> itself is removable and re-attachable via holes 45A, 45B, 45C, 45D, for example, by inserting a mounting screw through each hole. The lens mount <NUM> or the lens <NUM> can, for example, be one of those described in <CIT>.

The camera module <NUM> can include a module connector <NUM>, similar to or the same as the module connector <NUM>, that can interchangeably couple with an additional module (for example, engage with contacts on a corresponding connector of the additional module) and receive power or data from or transmit power or data to the module or one or more other devices coupled to the module. The additional module can include a camera, a display, a video game controller, a speaker, a battery, an input/output expander, a light, a lens, a projector, or combinations of the same and the like. In one example, the additional module connected to the module connector <NUM> can be an input/output expander and include one or more additional inputs that enable a user to control operations of the camera module <NUM>. The additional module moreover may have a form factor that permits coupling of a corresponding connector of the additional module to the module connector <NUM> without the additional module impeding placement or use of the lens mount <NUM> or obstructing a view through the lens <NUM> from an image sensor in the camera module <NUM> (for example, the additional module may not cover the entire surface of the camera module <NUM> that includes the module connector <NUM>). In some implementations, the additional module can magnetically attach to or be supported by the camera module, and the additional module and the camera module <NUM> can each include magnets that cause the two to be attracted and securely couple. Additionally or alternatively, coupling can be achieved at least via a friction fit, interlocking structures, fasteners, mechanical snap surface structures, mechanical latch surface structures, mechanical interference fit surface structures, or the like.

<FIG> illustrates a perspective view of a video camera <NUM>. The video camera <NUM> can include a brain module <NUM>, a lens mount module interface <NUM>, and a lens <NUM>. The video camera <NUM> can implement one or more of the compression techniques or other features described herein. Embodiments of the video camera <NUM> and its components are described in greater detail in in <CIT>and <CIT>.

<FIG> illustrates an image capture device <NUM> that can implement one or more of the compression techniques or other features described herein. The image capture device <NUM>, in some embodiments, can be or incorporated as part of the phone <NUM>, the camera module <NUM>, or the video camera <NUM>. The image capture device <NUM> can include a housing configured to support optics <NUM>, an image sensor <NUM> (or multiple image sensors), an image processing system <NUM>, a compression system <NUM>, and a memory device <NUM>. In some implementations, the image capture device <NUM> can further include a multimedia system <NUM>. The image sensor <NUM>, the image processing system <NUM>, the compression system <NUM>, and the multimedia system <NUM> may be contained within the housing during operation of the image capture device <NUM>. The memory device <NUM> can be also contained or mounted within the housing, mounted external to the housing, or connected by wired or wireless communication external to the image capture device <NUM>.

The optics <NUM> can be in the form of a lens system having at least one lens configured to focus an incoming image onto the image sensor <NUM>. In some embodiments, the optics <NUM> can be in the form of a multi-lens system providing variable zoom, aperture, and focus. The optics <NUM> can be in the form of a lens socket supported by the housing and receive multiple different types of lens systems for example, but without limitation, the optics <NUM> can include a socket configured to receive various sizes of lens systems including a <NUM>-<NUM> millimeter (F2. <NUM>) zoom lens, an <NUM>-<NUM> millimeter (F2. <NUM>) zoom lens, a <NUM> millimeter (F2. <NUM>) lens, <NUM> millimeter (F2. <NUM>) lens, <NUM> millimeter (F1. <NUM>) lens, <NUM> millimeter (F1. <NUM>) lens, <NUM> millimeter (F1. <NUM>) lens, <NUM> millimeter (F1. <NUM>) lens, or any other lens. As noted above, the optics <NUM> can be configured such that images can be focused upon a light-sensitive surface of the image sensor <NUM> despite which lens is attached thereto. Additional information regarding such a lens system can be found in <CIT>.

The image sensor <NUM> can be any type of video sensing device, including, for example, but without limitation, CCD, CMOS, vertically-stacked CMOS devices such as the Foveon® sensor, or a multi-sensor array using a prism to divide light between the sensors. The image sensor <NUM> can further include a color filter array such as a Bayer pattern filter that outputs data representing magnitudes of red, green, or blue light detected by individual photocells of the image sensor <NUM>. In some embodiments, the image sensor <NUM> can include a CMOS device having about <NUM> million photocells. However, other size sensors can also be used. In some configurations, video camera <NUM> can be configured to output video at "<NUM>" (e.g., <NUM> x <NUM> pixels), "<NUM>" (e.g., <NUM>,<NUM> x <NUM>,<NUM> pixels), "<NUM>. Sk," "<NUM>," "<NUM>," "<NUM>", or "<NUM>" or greater resolutions. As used herein, in the terms expressed in the format of "xk" (such as "<NUM>" and "<NUM>" noted above), the "x" quantity refers to the approximate horizontal resolution. As such, "<NUM>" resolution corresponds to about <NUM> or more horizontal pixels and "<NUM>" corresponds to about <NUM> or more pixels. Using currently commercially available hardware, the image sensor <NUM> can be as small as about <NUM> inches (<NUM>), but it can be about <NUM> inches, or larger. Additionally, the image sensor <NUM> can provide variable resolution by selectively outputting only a predetermined portion of the image sensor <NUM>. For example, the image sensor <NUM> or the image processing system <NUM> can be configured to allow a user to identify, configure, select, or define the resolution of the video data output. Additional information regarding sensors and outputs from sensors can be found in <CIT>.

The image processing system <NUM> can format the data stream from the image sensor <NUM>. The image processing system <NUM>, for instance, can separate the green, red, and blue image data into three or four separate data compilations. For example, the image processing system <NUM> can be configured to separate the red data into one red channel or data structure, the blue data into one blue channel or data structure, and the green data into one green channel or data structure. The image processing system <NUM> may also separate the green into two separate green data structures in order to preserve the disparity between the diagonally adjacent green pixels in a 2x2 Bayer pattern. The image processing system <NUM> can process the picture element values to combine, subtract, multiply, divide, or otherwise modify the picture elements to generate a digital representation of the image data.

The image processing system <NUM> can further include a subsampling system configured to output reduced or unreduced resolution image data to multimedia system <NUM>. For example, such a subsampling system can be configured to output image data to support <NUM>, <NUM>, <NUM>, 1080p, 720p, or any other resolution. Additionally, the image processing system <NUM> can include other modules or perform other processes, such as gamma correction processes, noise filtering processes, and the like. Examples of functionality provided by the image processing system <NUM> are described in <CIT>.

The compression system <NUM> can compress the image data from the image processing system <NUM> using a compression technique, such as the compression approach described with respect to <FIG>, or another technique. The compression system <NUM> can be in the form of a separate chip or chips (for example, FPGA, ASIC, etc.). The compression system <NUM> can be implemented with software and another processor or can be implemented with a combination of processors, software, or dedicated chips. For example, the compression system <NUM> can include one or more compression chips that perform a compression technique in accordance with DCT-based codecs.

The compression system <NUM> can compress the image data from the image processing system <NUM> using DCT-based codecs with rate control. In some embodiments, the compression system <NUM> performs a compression technique that modifies or updates compression parameters during compression of video data. The modified or updated compression parameters can be configured to achieve targeted or desired file sizes, video quality, video bit rates, or any combination of these. In some embodiments, the compression system <NUM> can be configured to allow a user or other system to adjust compression parameters to modify the quality or size of the compressed video output by the compression system <NUM>. For example, the image capture device <NUM> can include a user interface (not shown) that allows a user to input commands that cause the compression system <NUM> to change compression parameters.

The compression system <NUM> can compress the image data from the image processing system <NUM> in real time. The compression system <NUM> can perform compression using a single-pass to compress video frames. This can be used to eliminate the use of an intermediate frame memory used in some compression systems to perform multiple compression passes or to compress a current video frame based on the content from one or more previous video frames stored in an intermediate frame memory. This can reduce the cost or complexity of a video camera with on-board video compression. The compression system <NUM> can compress image data from the image processing system <NUM> in real time when the frame rate of the image data is at least <NUM> frames per second (fps), at least about <NUM> fps (e.g., <NUM> fps), at least about <NUM> fps, at least about <NUM> fps (e.g., <NUM> fps), at least about <NUM> fps, at least about <NUM> fps, at least about <NUM> fps (e.g., <NUM> fps), at least about <NUM> fps, at least about <NUM> fps, or less than or equal to about <NUM> fps. The compressed video can then be sent to the memory device <NUM>.

The memory device <NUM> can be in the form of any type of digital storage, such as, for example, but without limitation, hard disks, flash memory, or any other type of memory. In some embodiments, the size of the memory device <NUM> can be sufficiently large to store image data from the compression system <NUM> corresponding to at least about <NUM> minutes of video at <NUM> megapixel resolution, <NUM>-bit color resolution, and at <NUM> fps. However, the memory device <NUM> can have any size.

In embodiments that include the multimedia system <NUM>, the multimedia system <NUM> can allow a user to view video images captured by the image sensor <NUM> during operation or video images received from the compression system <NUM> or the memory device <NUM>. In some implementations, the image processing system <NUM> can include a subsampling system configured to output reduced resolution image data to the monitor system <NUM>. For example, such a subsampling system can be configured to output video image data to support "<NUM>," 1080p, 720p, or any other resolution. Filters used for de-mosaicing can also be adapted to perform down-sampling filtering, such that down-sampling and filtering can be performed at the same time. The multimedia system <NUM> can perform any type of decompression or de-mosaicing process to the data from the image processing system <NUM>. For example, the multimedia system <NUM> can decompress data that has been compressed as described herein. Thereafter, the multimedia system <NUM> can output a de-mosaiced or decompressed image data to a display of the multimedia system <NUM> or another display.

<FIG> illustrates additional components of the image capture device <NUM> according to some embodiments. <FIG>, in particular, depicts more implementation details of an embodiment of the image capture device <NUM> than <FIG>. As illustrated, the image capture device <NUM> is further in communication with frame memory <NUM>. The frame memory <NUM> can be DRAM, such as the RAM <NUM> of <FIG>.

The image capture device <NUM> further includes an image processing unit <NUM>. As shown, the image processing unit <NUM> can include the image processing system <NUM>, the compression system <NUM>, and on-chip memory <NUM>. The on-chip memory can, for example, be SRAM. Some or all of the components of the image processing unit <NUM> can be dedicated to use for processing and storage of image data (for example, compressed raw video image data) captured by the image capture device <NUM>, and may not be used for other purposes, such as for implementing telephone functionality associated with the image capture device <NUM>.

The image processing unit <NUM> can include one or more integrated circuits, chips or chipsets which, depending on the implementation, can include an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a combination thereof, or the like. According to certain embodiments, the on-chip memory <NUM> can be located within the same device (for example, ASIC, FPGA, or other chip[s]) as other components of the image processing unit <NUM>, such as the image processing system <NUM> and compression system <NUM>. For instance, the image processing unit <NUM> can include an ASIC or FPGA which implements the image processing system <NUM>, the compression system <NUM>, and the on-chip memory <NUM>. The on-chip memory <NUM> can therefore be referred to as an "on-chip" memory according to certain embodiments, whereas the frame memory <NUM> can be referred to as an "off-chip" memory.

As shown, the frame memory <NUM> can be implemented separate from the image processing unit <NUM> and can be a DRAM. For instance, in one embodiment, the frame memory <NUM> and image processing unit <NUM> are respectively an ASIC and FPGA implemented in separate packages and mounted on a common printed circuit board. The frame memory <NUM> can be used to concurrently store an entire image frame (for example, all or substantially all of the pixel data of one image frame) for processing purposes. For instance, the frame memory <NUM> can be used by the image processing system <NUM> for storing entire image frames during certain image processing steps, such as pixel defect correction or pixel pattern noise correction as a couple of examples. While the frame memory <NUM> may be used for some such steps, according to certain embodiments, the image capture device <NUM> implements an image processing pipeline in which compressed raw video image data is processed without utilizing the frame memory <NUM> for the purposes of compression. For instance, the compression system <NUM> in some embodiments implements a DCT-based compression scheme, which can be any of those described herein, such as with respect to <FIG>. Such a DCT-based compression scheme can be relatively lightweight in memory requirements, such that the compression system <NUM> can perform the compression utilizing the on-chip memory <NUM> and not the frame memory <NUM> or any other frame memory during compression.

Avoiding use of frame memory during compression can significantly reduce power consumption, and contrasts with certain other compression techniques which involve the use of a frame memory for motion vector calculations. For instance, according to certain DCT-based compression techniques described herein, the compression system <NUM> operates on a discrete section of a video image frame (for example, a section smaller than a full image frame) at any given time, discards the discrete section of the video image frame immediately after processing. For instance, in one embodiment, the compression system <NUM> operates on data for <NUM> horizontal lines of pixels at a time, and only utilizes an amount of storage in the on-chip memory <NUM> corresponding to <NUM> lines of pixel data for compression purposes (to hold image data for <NUM> lines of pixel data currently being compressed and to hold image data for the next <NUM> lines to be compressed). Depending on the embodiment, power consumption can be reduced such that, according to various embodiments the image capture device <NUM> consumes less than about <NUM> or <NUM> W during operation, and in some embodiments consumes between about <NUM> W to <NUM> W, between about <NUM> W to <NUM> W, or between about <NUM> W to <NUM> W. For instance, according to some embodiments the imaging componentry of the image processing device <NUM> (for example, the camera-related componentry of the image processing device <NUM>) consumes less than about <NUM> W or <NUM> W (for example, between about <NUM> W to <NUM> W or between about <NUM> W <NUM> W), whereas the remaining non-imaging componentry (for example, phone componentry, display componentry, etc.) consumes less than about 10W (for example, between about <NUM> W to <NUM> W or between about <NUM> W <NUM> W).

The compression techniques described herein can allow for enhanced decoding/decompression speeds. For instance, the DCT-based raw compression techniques can allow for enhanced decompression because DCT algorithms allow for use of highly parallelized mathematical operations during decompression, making efficient use of graphics processing units. Depending on the embodiment, the raw compression techniques described herein can allow for decompression of video image frames in less than or equal to about <NUM>/<NUM>, <NUM>/<NUM>, <NUM>/<NUM>, or <NUM>/<NUM> seconds, which can allow for real-time decompression, depending on the frame rate.

<FIG> is a flowchart <NUM> illustrating an example process for processing video image data that is performable by an image capture device, such as the phone <NUM>, the camera module <NUM>, the video camera <NUM>, or the image capture device <NUM>. The flowchart <NUM> can represent a control routine stored in a memory device, such as the memory device <NUM>, the ROM <NUM>, RAM <NUM>, or memory <NUM>. Additionally, a processor, such as the controller <NUM>, can be configured to execute the control routine. For convenience, the flowchart <NUM> is described in the context of the image capture device <NUM> but may instead be implemented by other systems described herein or other appropriate computing systems not shown. The flowchart <NUM> advantageously, in certain embodiments, depicts an example approach by which a relatively small or low-power handheld device like a cellphone can process video image data.

At block <NUM>, the image sensor <NUM> can generate video image data responsive to light incident on the image sensor <NUM>. For example, the image sensor <NUM> can generate the video image data as raw mosaiced image data at least at about <NUM> frames per second and with a resolution of at least <NUM>. Moreover, the output from the one or more image sensors <NUM> can in some implementations each be at least <NUM>-bit wide with <NUM>-bit outputs and <NUM> bit set for black sun effect. The image sensor <NUM> can, in some instances, be used to generate 3D video image data for processing and eventual presentation as 3D video images.

At block <NUM>, the image processing system <NUM> can pre-emphasize the video image data generated by the image sensor <NUM>. The generated video image data can be pre-emphasized by performing a lossy transform to raw pixels of the generated video image data. The pre-emphasis can desirably, in certain embodiments, reduce an amount of video image data to be processed at block <NUM> while nonetheless preserving video image data quality.

The image processing system <NUM> can, for example, perform a piecewise linear function to that transforms the raw pixels from <NUM>-bit or <NUM>-bit data to <NUM>-bit data. The slope of the piecewise linear function can follow a harmonic progression <NUM>, <NUM>/<NUM>, <NUM>/<NUM>,. , <NUM>/<NUM>, <NUM>/<NUM> and change every <NUM> counts. The shape of the piecewise linear function can be tailored to the image sensor <NUM> from sensor characterization data and thus vary from sensor to sensor or sensor manufacturer to sensor manufacturer. The input range of the piecewise linear function may, in some instances, go above a maximum value permitted to account for a black offset that may be applied.

<FIG> is a plot <NUM> that graphically illustrates one example piecewise linear function for transforming raw pixels from <NUM>-bit data to <NUM>-bit data. Table <NUM> below provides example points along the plot <NUM>.

The pre-emphasis can be performed by the image processing system <NUM> given the understanding that not all video image data values in a bit range (such as a <NUM>-bit range including <NUM>-<NUM>) carry the same information. Incoming light at each pixel can be governed by a Poisson process that results in a different photon shot noise (PSN) at each light level. The Poisson random distribution can have a unique characteristic where a variance of a distribution is equal to a mean of the distribution. Thereby, the standard deviation is equal to the square root of the mean. From this understanding, the uncertainty (such as indicated by the standard deviation) associated with each measured digital number output (DN), corresponding to incoming light for a particular pixel, can be proportional to <MAT>. To pre-emphasize, one or more digital values in an input domain can be lumped to a single digital value in an output domain. If Q adjacent DN values are lumped together (for instance, quantized) into one, the resulting noise can be proportional to <MAT>. The quantization noise can be minimized by choosing Q such that <MAT> (for example, <MAT>). The complexity of this function can be reduced by constructing a piecewise linear function from the function. Using this technique, additional noise added by the pre-emphasis can be reduced, such as to a small percentage (like <NUM>% of the photon shot noise in an example worst case scenario).

A conversion function may be used to convert pre-emphasized values after decoding. For example, the following function, which is expressed in pseudocode, can be used to convert <NUM>-bit data back to <NUM>-bit data after decoding. <MAT> <MAT> <MAT>.

In some instances, using a conversion function (sometimes referred to as a pre-emphasis function) that has a relatively simple inverse can helpful for decoding compressed image in hardware using parallel processing. For example, when an example conversion function has a relatively simple inverse, a Graphical Processing Unit (GPU) may be used to relatively quickly convert <NUM>-bit data back to its original <NUM>-bit data form after decompression.

Additional information regarding pre-emphasis techniques can be found in <CIT>.

At block <NUM>, the compression system <NUM> can compress the video image data pre-emphasized by the image processing system <NUM>. For example, the compression system <NUM> can compress the pre-emphasized video image data as described with respect to <FIG> or using another compression algorithm. The compression system <NUM> can, in some implementations, perform one or more of the following: (i) compress the video image data without using a frame memory that stores a full image frame, (ii) compress the video image data using one memory device and without using any memory positioned off-chip relative to the one memory device, (iii) compress the video image data using a static memory that may not be periodically refreshed rather than a dynamic memory that must be periodically refreshed, and (iv) operate according to the timing of a clock and correctly compress the video image data despite the clock stopping for a period of time such as a <NUM>, <NUM>, <NUM>, or <NUM> seconds or <NUM>, <NUM>, <NUM>, <NUM>, or <NUM> minutes. The compression system <NUM> moreover can be used to compress video image data that is presentable as 3D video images.

<FIG> is a flowchart <NUM> illustrating an example process for compressing video image data that is performable by an image capture device, such as the phone <NUM>, the camera module <NUM>, the video camera <NUM>, or the image capture device <NUM>. The flowchart <NUM> can represent a control routine stored in a memory device, such as the memory device <NUM>, the ROM <NUM>, RAM <NUM>, or memory <NUM>. Additionally, a processor, such as the controller <NUM>, can be configured to execute the control routine. For convenience, the flowchart <NUM> is described in the context of the image capture device <NUM> but may instead be implemented by other systems described herein or other appropriate computing systems not shown. The flowchart <NUM> advantageously, in certain embodiments, depicts an example approach by which a relatively small or low-power handheld device like a cellphone can compress video image data.

At block <NUM>, the compression system <NUM> can shift and divide video image data. Values of the video image data can be shifted by an amount equal to a central value for the video image data that depends on a number of bits of the data (for instance, the central value can be <NUM> · <NUM>n for n-bit data, which means <NUM> in the case of <NUM>-bit data). The shifting can shift the values around a value of <NUM> for further processing. The values can also be divided into slices and macroblocks. In one implementation, a maximum size of the slice is 256x32 pixels, and maximum size slices are packed from left to right. If some pixels are still left on the end of each line, a slice of size 256x32 pixels, 128x32 pixels, 64x32 pixels, 32x32 pixels, or another size can be made by packing pixels of value <NUM> at the end. In instances where the pixels follow a Bayer pattern, each slice can have 128x16 Green1, Green2, Red, and Blue pixels, and the pixels can be further divided into <NUM> macroblocks (16x16 pixels) of Green1, Green2, Red, and Blue pixels.

At block <NUM>, the compression system <NUM> can transform the shifted and divided video image data, such as using a discrete cosine transform (DCT) or another transform. In one example, the compression system <NUM> can transform each macroblock of the shifted and divided video image data using a 16x16 DCT. The 16x16 DCT notably can provide, in some instances, higher compression efficiency than an 8x8 DCT. The two dimensional 16x16 DCT can moreover be separable into <NUM> one dimensional 1x16 DCT calculations. This separability advantageously can, in certain embodiments, facilitate the use of memory having a capacity less than a frame memory (for example, multiple lines of on-chip memory <NUM>) when performing compression. The output from the transformation can be transform coefficients for the video image data.

At block <NUM>, the compression system <NUM> can quantize the transform coefficients. The quantization can include two components. The first component can be a quantization table value from one or more quantization tables. For example, one quantization table can be used for Green1 and Green2 channels, and another quantization table can be used for blue and red channels. The one or more quantization tables can be defined in a frame header. The second component can be a quantization scale factor. The quantization scale factor can be the same for each value within a slice, vary from a minimum value (for example, <NUM>) to a maximum value (for example, <NUM>), be defined in a slice header, and used for achieving a target slice size. The quantization scale factor can be determined based at least on a target frame size or a technique such as is described in <CIT>.

The quantization scale factor may be set constant in some instances to generate a compressed video of certain quality irrespective of the compressed image size. In one implementation, the quantized values for the transform coefficients can be determined using Equation <NUM> below.

At block <NUM>, the compression system <NUM> can arrange the quantized transform coefficients slice-by-slice for encoding and so that green, red, and blue components may be encoded separately within a slice. The DC coefficients of the macroblocks of one slice can be arranged left to right. The AC coefficients of the macroblocks of the one slice can arranged so that (i) all particular location AC coefficients in a 16x16 DCT table from different macroblocks in the slice are arranged one after the other and (ii) the different AC coefficients are arranged by the zig-zag scan order illustrated by Table <NUM> below where the index in Table <NUM> indicates a position in the sequence for the quantized transform coefficients.

At block <NUM>, the compression system <NUM> can divide the arranged transform coefficients into ranges and values within ranges. The ranges for the DC coefficients can be ranges of possible values of the DC coefficients, and the ranges for the AC coefficients can be ranges of possible values of the AC coefficients and counts of groupings of <NUM> values.

At block <NUM>, the compression system <NUM> can encode the ranges of the arranged coefficients as Huffman codes and at least some of the values within the ranges of the arranged coefficients as Golomb codes. If a range has no more than one unique value, the one unique value may be encoded with a Huffman code and not a Golomb code. If a range has more than one unique value, values can be encoded by a combination of a Huffman code for the range and a Golomb code for the unique value within the range. The ranges and the Golomb codes for the ranges may be fixed or predefined, such as set at manufacture. The Huffman codes for the ranges, however, can vary from frame to frame with one or more Huffman tables being defined in a frame header. An encoder can use the adaptability of Huffman coding and may compute one or more Huffman tables at the end of each frame to be used for a next frame to optimize compression efficiency for particular video image data. In one implementation, a maximum number of bits in a Huffman code can be <NUM>.

The value of a DC coefficient of a particular component in a slice may be encoded as a difference from the previous value of the DC coefficient. This difference can be termed a difference coefficient. An initial value for the DC coefficient for the particular component in the slice can be set to <NUM>. To encode the values of individual DC coefficients, the compression system <NUM>, for example, can (i) calculate the absolute value of the difference coefficient for the individual DC coefficient, (ii) append the Huffman code corresponding to the range of the individual DC coefficient to the bit stream, (iii) append the Golomb code corresponding to the value within the range of the individual DC coefficient to the bit stream, and (iv) append a sign bit (for example, <NUM> for positive and <NUM> for negative) to the bitstream if difference coefficient is nonzero.

Table <NUM> below provides an example DC encoding table. The Huffman code portion of the table can be used as a default table at the beginning of compression when compression statistics may be unknown.

For example, as can be seen from Table <NUM>, if the difference coefficient may be <NUM>, the Huffman code can be <NUM>, the Huffman bits can be <NUM>, the Golomb code can be Golomb-Rice(<NUM>, <NUM>), and the sign bit can be <NUM>. As another example, if the difference coefficient may be -<NUM>, the Huffman code can be <NUM>, the Huffman bits can be <NUM>, the Golomb code can be Golomb-Rice(<NUM>, <NUM>), and the sign bit can be <NUM>. As yet another example, if the difference coefficient may be <NUM>, the Huffman code can be <NUM>, the Huffman bits can be <NUM>, the Golomb code can be Golomb-Rice(<NUM>, <NUM>), and the sign bit can be <NUM>.

The values of AC coefficients can be represented by runs of zeros followed by a non-zero value. Different Huffman codes can denote the values of AC coefficients that are preceded by runs of zeros and those that are not preceded by runs of zeros. To encode the values of non-zero individual AC coefficients, the compression system <NUM>, for example, can (i) calculate EACV = IAC valuel - <NUM> for the individual AC coefficient, (ii) determine whether the individual AC coefficient is preceded by one or more zeros, (iii) append the Huffman code corresponding to the EACV for the individual DC coefficient to the bit stream, (iv) append the Golomb code corresponding to the EACV to the bit stream if EACV exceeds <NUM>, and (v) append a sign bit (for example, <NUM> for positive and <NUM> for negative) to the bitstream. Moreover, to encode the values of individual AC coefficients that have values of zero, the compression system <NUM>, for example, can (i) calculate EACR = AC runs of zeros - <NUM>, (ii) append the Huffman code corresponding to the EACR to the bit stream, and (iii) append the Golomb code corresponding to the EACR to the bit stream if EACR exceeds <NUM>.

Table <NUM> below provides an example AC encoding table. The Huffman code portion of the table can be used as a default table at the beginning of compression when compression statistics may be unknown.

To illustrate how Table <NUM> may be used for encoding, an example of encoding the eleven coefficient sequence of <NUM>, <NUM>, <NUM>, <NUM>, -<NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM> will be described. As can be seen from Table <NUM>, for the run of one zero, the "AC Run - <NUM>" can be <NUM>, the Huffman code can be <NUM>, the Huffman bits can be <NUM>, and there may be no Golomb code. Next, for the value of <NUM> which is preceded by the run of at least one zero, the "IAC Valuel - <NUM>" can be <NUM>, the Huffman code can be <NUM>, the Huffman bits can be <NUM>, there may be no Golomb code, and the sign bit can be <NUM>. Subsequently, for the run of two zeros, the "AC Run - <NUM>" can be <NUM>, the Huffman code can be <NUM>, the Huffman bits can be <NUM>, and there may be no Golomb code. Then next, for the value of -<NUM> which is preceded by the run of at least one zero, the "IAC Valuel - <NUM>" can be <NUM>, the Huffman code can be <NUM>, the Huffman bits can be <NUM>, the Golomb code can be Golomb-Rice(<NUM>, <NUM>), and the sign bit can be <NUM>. Then subsequently, for the value of <NUM> which is not preceded by a run of at least one zero, the "IAC Valuel - <NUM>" can be <NUM>, the Huffman code can be <NUM>, the Huffman bits can be <NUM>, the Golomb code can be Golomb-Rice(<NUM>, <NUM>), and the sign bit can be <NUM>. Finally, for the remaining run of five zeros, the "AC Run - <NUM>" can be <NUM>, the Huffman code can be <NUM>, the Huffman bits can be <NUM>, and the Golomb code can be Golomb-Rice(<NUM>, <NUM>).

As further part of the process of the flowchart <NUM>, adaptive compression may be performed in certain implementations. For example, a size of a compressed frame can be set close to a target number of bytes, such as using the technique described in <CIT>.

An entropy index for each slice can moreover be calculated, such as using a technique described in <CIT>.

The entropy index along with an entropy multiplier can be used to calculate the quantization scale factor. The range of DCT 16x16 may notably be higher than that of DCT 8x8 for the same <NUM>-bit input.

In some instances, because <NUM> lines of raw image data may be processed at a time, an image can be divided vertically (or otherwise) into <NUM> or more sections. After processing individual sections, a size of the compressed image thus far can be available. The size of the compressed image can then be used to update an entropy multiplier. At the end of frame compression, the size of the compressed image can be compared to a target size to further update the entropy multiplier.

Although some examples herein describe coding ranges or values within ranges using Huffman codes (or algorithms) and Golomb codes (or algorithms), other codes (or algorithms) can be used. For example, a lossless code, a lossy code, a variable length code, or a prefix code may be used.

In some embodiments, a first algorithm can be used for coding ranges and a second algorithm can be used for coding values within ranges. The first algorithm can, in some instances, be different from the second algorithm so that ranges and values within ranges may be coded differently. In other instances, the first algorithm can be the same as the second algorithm.

Video image data, which may be compressed using one or more approaches disclosed herein, can be organized according to a video stream specification. The video stream specification can, in some implementations, include one or more of the following features.

A frame structure in a compressed file can be divided into header and data portions. The header can be designed to be hardware friendly. In some instances, all values in the header other than the size of a compressed frame may be known before the compression begins. A header version may be used to decode the compressed file, such as for playback on-camera or off-camera, if revisions were made to the file format. The header can, for instance, contain <NUM> bytes. The header can be followed by slices ordered left to right and top to bottom. Each slice can contain an integer number of bytes. One example header structure is shown below in Table <NUM>.

Individual entries in a Huffman table can be <NUM> bytes (<NUM>-bits) wide. As illustrated by Table <NUM> below, the most significant bits (for example, first <NUM> bits) of a Huffman table structure can represent a size of the Huffman code, and the least significant bits (for example, last <NUM> bits) of the Huffman table structure can represent the Huffman code itself that may be aligned to the right and left padded with zeros.

Each slice can have a header (for example, <NUM> bytes) followed by Green1, Green2, Red, and Blue components. Each component can begin on a byte boundary. If a component may have fractional bytes, the component can be padded with zeros to form a complete byte. Table <NUM> below illustrates an example slice structure.

Table <NUM> below shows an example slice header structure. The number of bits of the slice header structure can be specified to avoid confusing padded bits with Huffman codes of value zero. If the number of bits in a component may not be a multiple of <NUM>, a next component can begin on a byte boundary.

The displays of or connected to the image capture devices described herein (for example, the display <NUM> of the device <NUM> of <FIG>) can, in some implementations, be or include 3D displays. A 3D display may be configured to produce light so that a 3D image (sometimes referred to as "multi-dimensional content") is observed by the user. Stereoscopic displays may, for instance, be used to form images that appear to a user to be 3D when viewed at the proper angle or using specifically designed eye wear. At least some embodiments are directed to a display that is configured to produce an image that appears to be in 3D space, such that a user may be able to view the 3D image from multiple directions without moving the display. The display may not need to be positioned within the user's field of view. In some embodiments, the 3D image may appear to be suspended or float above the display. Thus, a user may be able to "walk around" the 3D image to observe different views of the image as though the content in the image was a physical object.

Some embodiments of the 3D display may include a diffractive lightfield backlighting system. The diffractive lightfield backlighting system may include a multiview or 3D display and a light source configured for rear illumination of the 3D display. The multiview display may include a plurality of diffractive elements, each including a plurality of diffractive gratings, configured to direct light illuminated thereon into multiple directions. The direction that the light is directed may be based on the diffractive properties of the diffractive elements. In some embodiments, the multiple directions may correspond to a different view of the 3D image. Multiple light rays directed in the same or substantially similar direction may form and image corresponding to a particular view of the 3D content. Accordingly, multiple views of the 3D content may be displayed in multiple directions based on the plurality of diffractive elements. Some implementations of embodiments herein are described in more detail, for example, in <CIT> entitled "Multibeam Diffraction Grating-Based Backlighting" and <CIT> entitled "Directional Backlighting," the contents of which are each incorporated herein in their entirety. A 3D display may be separately operable from a <NUM> Dimensional (2D) display. The 3D display may, for instance, be disposed behind or in front of the 2D display. As such, the 3D display or 2D display can each be turned on and off without affecting the use of the other.

Other embodiments of the 3D display are possible for generating a 3D image. For example, the 3D display may be configured to display a 3D image based on a reconstruction of a holographic interference pattern associated with a hologram. The interference pattern may be reconstructed based on features stored in the fringe pattern, and the display may include pixels driven to duplicate the interference fringe pattern on a screen. The pixels may be illuminated by a light source, which may be transformed (e.g., varied in phase or transmittance) by the interference pattern of the pixels to generate a 3D holographic image. Some implementations may be found in, for example, <CIT>, entitled "Transparent Holographic Display with Dynamic Image Control"; <CIT>, entitled "Holographic Display," the contents of which are each incorporated herein in their entirety. In another embodiment, the display may include a plurality of holographic pixels that are illuminated modulated using an spatial light modulator, for example, as described in <CIT>, entitled "Enhanced Environment Visualization Using Holographic Sterograms," the contents of which is incorporated herein in its entirety.

Advantageously, the 3D display may, in certain embodiments, not need to utilize lenticular lenses or eye tracking technology. Without subscribing to a particular scientific theory, embodiments herein can provide for higher resolution as compared to displays using lenticular lenses, the 3D display may be separately operable from a standard 2D display, and the 3D display provides for multi-directional content having multiple views.

Moreover, the image capture devices described herein can, in some implementations, capture 3D images for reproduction by a 3D display. For instance, the first cameras <NUM>, the second cameras <NUM>, images sensors of the camera module <NUM>, or image sensors of the video camera can be used to capture 3D images. In one example, the first cameras <NUM>, the second cameras <NUM>, or the images sensors of the camera module <NUM> can be used to capture 3D images, and the phone <NUM> can in turn store the 3D images and playback the 3D images using the display <NUM>. Such a design can facilitate live or simultaneous capture and display of 3D images.

The 3D content, holographic content, or other content displayed on the 3D display can be compressed according to any of the techniques described herein, such as for example according to the techniques for compressing raw image data described with respect to <FIG>. For instance, the phone <NUM> may capture compressed raw image data using two or more of the first cameras <NUM>, using the second cameras <NUM>, or one or more of the image sensors of the camera module <NUM> (or using a different camera module attached to the phone <NUM>). The phone <NUM> can then record the compressed image data in one or more files on a memory device of the phone <NUM>, or in a memory device in a module attached to the phone <NUM>. The phone <NUM> can then access the image data, decompress it, and prepare it for playback on the display <NUM> as 3D, holographic content, or the like, as appropriate. The phone <NUM> can additionally according to some embodiments play the 3D, holographic, or other content back in real-time without first compressing and storing the content, while the phone <NUM> is recording.

<FIG> illustrates the image capture device <NUM> in communication with a phone <NUM>. The image capture device <NUM> can, for example, be an embodiment of the camera module <NUM>, and the phone <NUM> can, for example, be an embodiment of the phone <NUM>. The phone <NUM> can be modular and couple to one or more modules as described herein. For example, the phone can mechanically or electrically connect to a power source <NUM>, a memory device <NUM>, or an input/output (I/O) device <NUM>, as well as the image capture device <NUM> or one or more other modules <NUM>. In addition, the phone <NUM> can electrically communicate with one or more other modules <NUM>, <NUM>, <NUM>, <NUM> respectively through the power source <NUM>, the memory device <NUM>, the input/output (I/O) device <NUM>, and the image capture device <NUM>, and the one or more other modules <NUM>, <NUM>, <NUM>, <NUM> can respectively couple to the power source <NUM>, the memory device <NUM>, the input/output (I/O) device <NUM>, and the image capture device <NUM>. Embodiments and features of modular phones and camera modules are further described in <CIT>.

<FIG> illustrates components of the phone <NUM>. The phone <NUM> may be connected to an external device by using an external connection device, such as a sub-communication module <NUM>, a connector <NUM>, and an earphone connecting jack <NUM>. The "external device" may include a variety of devices, such as earphones, external speakers, Universal Serial Bus (USB) memories, chargers, cradles/docks, Digital Multimedia Broadcasting (DMB) antennas, electronic payment related devices, health care devices (for example, blood sugar testers), game consoles, vehicle navigations, a cellphone, a smart phone, a tablet PC, a desktop PC, a server, and the like, which are removable from the electronic device and connected thereto via a cable.

The phone <NUM> includes a touch screen display <NUM> and a touch screen controller <NUM>. The phone <NUM> also includes a controller <NUM>, a mobile communication module <NUM>, the sub-communication module <NUM>, a multimedia module <NUM>, a camera module <NUM>, a Global Positioning System (GPS) module <NUM>, an input/output module <NUM>, a sensor module <NUM>, a memory <NUM>, and a power supply <NUM>. The sub-communication module <NUM> includes at least one of Wireless Local Area Network (WLAN) <NUM> and a short-range communication module <NUM>, and the multimedia module <NUM> includes at least one of a broadcast communication module <NUM>, an audio play module <NUM>, and a video play module <NUM>. The input/output module <NUM> includes at least one of buttons <NUM>, a microphone <NUM>, a speaker <NUM>, a vibration motor <NUM>, the connector <NUM>, and a keypad <NUM>. Additionally, the electronic device <NUM> can include one or more lights including a first light <NUM> that faces one direction and a second light <NUM> that faces another direction.

The controller <NUM> may include a Central Processing Unit (CPU) <NUM>, a Read Only Memory (ROM) <NUM> for storing a control program, such as an Operating System (OS), to control the phone <NUM>, and a Random Access Memory (RAM) <NUM> for storing signals or data input from an external source or for being used as a memory space for working results in the phone <NUM>. The CPU <NUM> may include a single core, dual cores, triple cores, or quad cores. The CPU <NUM>, ROM <NUM>, and RAM <NUM> may be connected to each other via an internal bus.

The controller <NUM> may control the mobile communication module <NUM>, the sub-communication module <NUM>, the multimedia module <NUM>, the camera module <NUM>, the GPS module <NUM>, the input/output module <NUM>, the sensor module <NUM>, the memory <NUM>, the power supply <NUM>, the touch screen display <NUM>, and the touch screen controller <NUM>.

The mobile communication module <NUM> connects the electronic device <NUM> to an external device through mobile communication using at least a one-to-one antenna or a one-to-many antenna under the control of the controller <NUM>. The mobile communication module <NUM> transmits/receives wireless signals for voice calls, video conference calls, Short Message Service (SMS) messages, or Multimedia Message Service (MMS) messages to/from a cell phone, a smart phone, a tablet PC, or another device, with the phones having phone numbers entered into the phone <NUM>.

The sub-communication module <NUM> may include at least one of the WLAN module <NUM> and the short-range communication module <NUM>. For example, the sub-communication module <NUM> may include either the WLAN module <NUM> or the-short range communication module <NUM>, or both.

The WLAN module <NUM> may be connected to the Internet in a place where there is a wireless Access Point (AP), under the control of the controller <NUM>. The WLAN module <NUM> supports the WLAN Institute of Electrical and Electronic Engineers (IEEE)<NUM>. 11x standard. The short-range communication module <NUM> may conduct short-range communication between the phone <NUM> and an image rendering device under the control of the controller <NUM>. The short-range communication may include communications compatible with BLUETOOTH™, a short range wireless communications technology at the <NUM> band, commercially available from the BLUETOOTH SPECIAL INTEREST GROUP, INC. , Infrared Data Association (IrDA), WI-FI™ DIRECT, a wireless technology for data exchange over a computer network, commercially available from the WI-FI ALLIANCE, NFC, and the like.

The phone <NUM> may include at least one of the mobile communication module <NUM>, the WLAN module <NUM>, and the short-range communication module <NUM> based on the performance requirements of the phone <NUM>. For example, the phone <NUM> may include a combination of the mobile communication module <NUM>, the WLAN module <NUM>, and the short-range communication module <NUM> based on the performance requirements of the phone <NUM>.

The multimedia module <NUM> may include the broadcast communication module <NUM>, the audio play module <NUM>, or the video play module <NUM>. The broadcast communication module <NUM> may receive broadcast signals (for example, television broadcast signals, radio broadcast signals, or data broadcast signals) and additional broadcast information (for example, an Electric Program Guide (EPG) or an Electric Service Guide (ESG)) transmitted from a broadcasting station through a broadcast communication antenna under the control of the controller <NUM>. The audio play module <NUM> may play digital audio files (for example, files having extensions, such as mp3, wma, ogg, or way) stored or received under the control of the controller <NUM>. The video play module <NUM> may play digital video files (for example, files having extensions, such as mpeg, mpg, mp4, avi, move, or mkv) stored or received under the control of the controller <NUM>. The video play module <NUM> may also play digital audio files.

The multimedia module <NUM> may include the audio play module <NUM> and the video play module <NUM> except for the broadcast communication module <NUM>. The audio play module <NUM> or video play module <NUM> of the multimedia module <NUM> may be included in the controller <NUM>.

The camera module <NUM> may include one or more cameras for capturing still images or video images under the control of the controller <NUM>. Furthermore, the one or more cameras may include an auxiliary light source (for example, a flash) for providing an amount of light for capturing an image. In one example, one or more cameras may be placed on the front of the phone <NUM>, and one or more other cameras may be placed on the back of phone <NUM>. Two or more cameras may be arranged, in some implementations, adjacent to each other (for example, the distance between the two or more cameras, respectively, may be in the range of <NUM>. ), capturing <NUM> Dimensional (3D) still images or 3D video images.

The GPS module <NUM> receives radio signals from a plurality of GPS satellites in orbit around the Earth and may calculate the position of the phone <NUM> by using time of arrival from the GPS satellites to the phone <NUM>.

The input/output module <NUM> may include at least one of the plurality of buttons <NUM>, the microphone <NUM>, the speaker <NUM>, the vibrating motor <NUM>, the connector <NUM>, and the keypad <NUM>.

The at least one of the buttons <NUM> may be arranged on the front, side or back of the housing of the phone <NUM>, and may include at least one of a power/lock button, a volume button, a menu button, a home button, a back button, and a search button.

The microphone <NUM> generates electric signals by receiving voice or sound under the control of the controller <NUM>.

The speaker <NUM> may output sounds externally corresponding to various signals (for example, radio signals, broadcast signals, digital audio files, digital video files or photography signals) from the mobile communication module <NUM>, sub-communication module <NUM>, multimedia module <NUM>, or camera module <NUM> under the control of the controller <NUM>. The speaker <NUM> may output sounds (for example, button-press sounds or ringback tones) that correspond to functions performed by the electronic device <NUM>. There may be one or multiple speakers <NUM> arranged in at least one position on or in the housing of the phone <NUM>.

The vibrating motor <NUM> may convert an electric signal to a mechanical vibration under the control of the controller <NUM>. For example, the phone <NUM> in a vibrating mode operates the vibrating motor <NUM> when receiving a voice call from another device. There may be at least one vibration motor <NUM> inside the housing of the phone <NUM>. The vibration motor <NUM> may operate in response to a touch activity or continuous touches of a user over the touch screen display <NUM>.

The connector <NUM> may be used as an interface for connecting the phone <NUM> to the external device or a power source. Under the control of the controller <NUM>, the phone <NUM> may transmit data stored in the memory <NUM> of the electronic device <NUM> to the external device via a cable connected to the connector <NUM>, or receive data from the external device. Furthermore, the phone <NUM> may be powered by the power source via a cable connected to the connector <NUM> or may charge the battery using the power source.

The keypad <NUM> may receive key inputs from the user to control the phone <NUM>. The keypad <NUM> includes a mechanical keypad formed in the phone <NUM>, or a virtual keypad displayed on the touch screen display <NUM>. The mechanical keypad formed in the phone <NUM> may optionally be omitted from the implementation of the phone <NUM>, depending on the performance requirements or structure of the phone <NUM>.

An earphone may be inserted into the earphone connecting jack <NUM> and thus, may be connected to the phone <NUM>.

A stylus pen <NUM> may be inserted and removably retained in the phone <NUM> and may be drawn out and detached from the phone <NUM>.

A pen-removable recognition switch <NUM> that operates in response to attachment and detachment of the stylus pen <NUM> is equipped in an area inside the phone <NUM> where the stylus pen <NUM> is removably retained, and sends a signal that corresponds to the attachment or the detachment of the stylus pen <NUM> to the controller <NUM>. The pen-removable recognition switch <NUM> may have a direct or indirect contact with the stylus pen <NUM> when the stylus pen <NUM> is inserted into the area. The pen-removable recognition switch <NUM> generates the signal that corresponds to the attachment or detachment of the stylus pen <NUM> based on the direct or indirect contact and provides the signal to the controller <NUM>.

The sensor module <NUM> includes at least one sensor for detecting a status of the phone <NUM>. For example, the sensor module <NUM> may include a proximity sensor for detecting proximity of a user to the phone <NUM>, an illumination sensor for detecting an amount of ambient light of the electronic device <NUM>, a motion sensor for detecting the motion of the phone <NUM> (for example, rotation of the phone <NUM>, acceleration or vibration applied to the phone <NUM>), a geomagnetic sensor for detecting a point of the compass using the geomagnetic field, a gravity sensor for detecting a direction of gravity, and an altimeter for detecting an altitude by measuring atmospheric pressure. At least one sensor may detect the status and generate a corresponding signal to transmit to the controller <NUM>. The sensor of the sensor module <NUM> may be added or removed depending on the performance requirements of the phone <NUM>.

The memory <NUM> may store signals or data input/output according to operations of the mobile communication module <NUM>, the sub-communication module <NUM>, the multimedia module <NUM>, the camera module <NUM>, the GPS module, the input/output module <NUM>, the sensor module <NUM>, the touch screen display <NUM> under the control of the controller <NUM>. The memory <NUM> may store the control programs and applications for controlling the phone <NUM> or the controller <NUM>.

The term "storage" can refer to the memory <NUM>, and also to the ROM <NUM>, RAM <NUM> in the controller <NUM>, or a memory card (for example, a Secure Digital (SD) card, a memory stick, and the like) installed in the phone <NUM>. The storage may also include a nonvolatile memory, a volatile memory, a Hard Disc Drive (HDD), a Solid State Drive (SSD), and the like.

The power supply <NUM> may supply power from at least one battery placed inside the housing of the phone <NUM> under the control of the controller <NUM>. The at least one battery can thus power the phone <NUM>. The power supply <NUM> may supply the phone <NUM> with the power input from the external power source via a cable connected to the connector <NUM>. The power supply <NUM> may also supply the phone <NUM> with wireless power from an external power source using a wireless charging technology.

The touch screen controller <NUM> receives information (for example, information to be generated for making calls, data transmission, broadcast, or photography) that is processed by the controller <NUM>, converts the information to data to be displayed on the touch screen display <NUM>, and provides the data to the touch screen display <NUM>. The touch screen display <NUM> displays the data received from the touch screen controller <NUM>. For example, in a call mode, the touch screen display <NUM> may display a User Interface (UI) or a Graphic User Interface (GUI) with respect to a call. The touch screen display <NUM> may include at least one of liquid crystal displays, thin film transistor-liquid crystal displays, organic light-emitting diodes, flexible displays, 3D displays (for instance, for presenting 3D images as described herein), multiview displays, electrophoretic displays, or combinations of the same and the like. The touch screen display <NUM> moreover can be used to present video images as described herein, such as including 2D video images, 3D video images, and 2D/3D virtual reality (VR), augmented reality (AR), and mixed reality (MR). In some implementations, the phone <NUM> further includes a holographic module that processes and outputs holographic video images for presentation, such as on the touch screen display <NUM> or another display of the phone <NUM>.

The touch screen display <NUM> may be used as an output device and also as an input device, and for the latter case, may have a touchscreen panel to operate as a touch screen. The touch screen display <NUM> may send to the touch screen controller <NUM> an analog signal that corresponds to at least one touch to the UI or GUI. The touch screen display <NUM> may detect the at least one touch by a user's physical contact (for example, by fingers including a thumb) or by a touchable input device (for example, the stylus pen). The touch screen display <NUM> may also receive a dragging movement of a touch among at least one touch and transmit an analog signal that corresponds to the dragging movement to the touch screen controller <NUM>. The touch screen display <NUM> may be implemented to detect at least one touch in, for example, a resistive method, a capacitive method, an infrared method, an acoustic wave method, and the like.

The term "touches" is not limited to physical touches by a physical contact of the user or contacts with the touchable input device, but may also include touchless proximity (for example, maintaining a detectable distance less than <NUM>. between the touch screen display <NUM> and the user's body or touchable input device). The detectable distance from the touch screen display <NUM> may vary depending on the performance requirements of the phone <NUM> or structure of the phone <NUM>, and more particularly, the touch screen display <NUM> may output different values (for example, current values) for touch detection and hovering detection to distinguishably detect that a touch event occurred by a contact with the user's body or the touchable input device and a contactless input (for example, a hovering event). Furthermore, the touch screen display <NUM> may output different values (for example, current values) for hovering detection over distance from where the hovering event occurs.

The touch screen controller <NUM> converts the analog signal received from the touch screen display <NUM> to a digital signal (for example, in XY coordinates on the touch panel or display screen) and transmits the digital signal to the controller <NUM>. The controller <NUM> may control the touch screen display <NUM> by using the digital signal received from the touch screen controller <NUM>. For example, in response to the touch event or the hovering event, the controller <NUM> may enable a shortcut icon displayed on the touch screen display <NUM> to be selected or to be executed. The touch screen controller <NUM> may also be incorporated in the controller <NUM>.

Further, the touch screen controller <NUM> may determine the distance between where the hovering event occurs and the touch screen display <NUM> by detecting a value (for example, a current value) output through the touch screen display <NUM>, convert the determined distance to a digital signal (for example, with a Z coordinate), and provide the digital signal to the controller <NUM>.

One of more of the components or modules of the phone <NUM> can be removably coupled to a housing of the phone <NUM>. To help illustrate this coupling, the housing of the phone <NUM> may be understood to be the phone <NUM>, while the one of more of the components or modules can be removably coupled to the phone <NUM> via the module connector <NUM> to add or remove functionality for the phone <NUM>. As one example, a portion or all of the camera module <NUM> can be removably coupled to the phone <NUM> to provide the phone <NUM> with the functionality of part or all the camera module <NUM>.

While certain electronic devices shown and described herein are cellphones, other handheld electronic device embodiments are not cellphones, and do not include telephonic capability. For instance, some embodiments have the same or similar exterior as the electronic devices described herein, but do not include telephonic capability, such as in the case of a tablet computing device or digital camera. Such embodiments may nonetheless include any combination of the non-telephone components and functionality described herein, such as one or more of the following or portions thereof: controller <NUM>, touch screen display <NUM> and touch screen controller <NUM>, camera module <NUM>, multi-media module <NUM>, sub-communication module <NUM>, first light <NUM>, second light <NUM>, GPS module <NUM>, I/O module <NUM>, and memory <NUM>.

<FIG> illustrates a perspective view of the phone <NUM> positioned for attachment to an expander module <NUM> and the camera module <NUM>, and <FIG> illustrates a perspective view of the phone <NUM>, the expander module <NUM>, and the camera module <NUM> when attached. The expander module <NUM> can include a memory device, a battery, or other component for enhancing the capacity of the phone <NUM>. The expander module <NUM> can include a housing that supports magnets, which can be similar in structure and function to those of the camera module <NUM> in <FIG>. The magnets can facilitate coupling of the housing to the phone <NUM> on one side and the camera module <NUM> on the other side. Additionally or alternatively, coupling can be achieved at least via a friction fit, interlocking structures, fasteners, mechanical snap surface structures, mechanical latch surface structures, mechanical interference fit surface structures, or the like.

The expander module <NUM> can also include module connectors (for example, two module connectors with one expander module connector <NUM> for coupling to a corresponding connector (now shown) on the camera module <NUM> and another expander module connector (not shown) for coupling to the module connector <NUM>), similar to or the same as the module connector <NUM>, that can interchangeably couple with a module and receive power or data from or transmit power or data to the module or one or more other devices coupled to the module.

Although Green1 and Green2 may be described as processed separately or differently in some instances herein, Green1 and Green2 may or may not be processed separately or differently. For example, Green1 and Green2 pixels can be separated into separate DCT macroblocks or may not be separated into separate DCT macroblocks. As another example, Green1 and Green2 pixels can be separated into separate scans or may not be separated into separate scans. In yet another example, a slice structure can have separate portions for Green1 and Green2 or may not have separate portions for Green1 and Green2. In a further example, Green1 and Green2 can have separate sizes in a slice header structure or may not have separate sizes in the slice header structure.

The various image capture devices (or certain components of the devices) may be described herein as being "configured to" perform one or more functions. As used herein this means that the device is capable of being placed in at least one mode (for example, user selectable modes) in which the device performs the specified functions. For example, the device may not necessarily perform the specified functions in all of the operational modes. Along these lines, use of the phrase "configured to" does not imply that the device has to actually be currently placed in the operational mode to be "configured to" perform the function, but only that the device is capable of being (for example, programmed to be) selectively placed into that mode.

The various illustrative logics, logical blocks, modules, circuits and algorithm steps described in connection with the implementations disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. The interchangeability of hardware and software has been described generally, in terms of functionality, and illustrated in the various illustrative components, blocks, modules, circuits and steps described above.

The hardware and data processing apparatus used to implement the various illustrative logics, logical blocks, modules and circuits described in connection with the aspects disclosed herein may be implemented or performed with a single- or multi-chip processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A processor may be a microprocessor, or, any processor, controller, microcontroller, or state machine. A processor also may be implemented as a combination of electronic devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In some implementations, particular steps and methods may be performed by circuitry that is specific to a given function.

Implementations of the subject matter described in this specification also can be implemented as one or more computer programs, for example, one or more modules of computer program instructions, encoded on a computer storage media for execution by, or to control the operation of, data processing apparatus.

The steps of a method or algorithm disclosed herein may be implemented in a processor-executable software module which may reside on a computer-readable medium. Storage media may be any available media that may be accessed by a computer. Combinations of the above also may be included within the scope of computer-readable media.

Certain features that are described in this specification in the context of separate implementations also can be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation also can be implemented in multiple implementations separately or in any suitable subcombination.

Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise," "comprising," and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to. " The word "coupled", as generally used herein, refers to two or more elements that may be either directly connected, or connected by way of one or more intermediate elements. Likewise, the word "connected", as generally used herein, refers to two or more elements that may be either directly connected, or connected by way of one or more intermediate elements. Additionally, the words "herein," "above," "below," and words of similar import, when used in this application, shall refer to this application as a whole and not to any particular portions of this application. Where the context permits, words in the above Detailed Description using the singular or plural number may also include the plural or singular number respectively. The word "or" in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.

Moreover, conditional language used herein, such as, among others, "can," "could," "might," "can," "for example," "for example," "such as" and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements or states. Thus, such conditional language is not generally intended to imply that features, elements or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements or states are included or are to be performed in any particular embodiment.

For example, while processes or blocks are presented in a given order, alternative embodiments may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, or modified. Each of these processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed in parallel, or may be performed at different times.

Claim 1:
An electronic device (<NUM>) comprising:
a housing;
an image sensor (<NUM>) configured to generate image data from light incident on the image sensor;
a memory device (<NUM>); and
one or more processors (<NUM>) configured to:
transform the image data using a discrete cosine transform_to obtain transform coefficients,
quantize the transform coefficients to obtain quantized transform coefficients including a first quantized transform coefficient and a second quantized transform coefficient different from the first quantized transform coefficient,
encode the quantized transform coefficients to obtain encoded coefficients, the quantized transform coefficients being encoded at least by:
determining a first range of a plurality of ranges in which the first quantized transform coefficient is included,
determining a second range of the plurality of ranges in which the second quantized transform coefficient is included,
determining a first value within the first range to which the first quantized transform coefficient corresponds,
determining a second value within the second range to which the second quantized transform coefficient corresponds,
encoding, using a first algorithm, the first range as a first range code and the second range as a second range code,
encoding, using a second algorithm different from the first algorithm, the first value as a first value code and the second value as a second value code,
wherein the one or more processors (<NUM>) is configured to vary the first algorithm from processing a first frame of the image data to processing a second frame of the image data, during processing of the image data,
wherein the second algorithm remains constant during processing of the image data by the one or more processors, and
store the encoded coefficients to the memory device, the encoded coefficients comprising the first range code, the second range code, the first value code, and the second value code.