AVIF Encoding Presets: File Size vs Quality Trade-Offs

AVIF encoding presets dictate the balance between computational effort, compression efficiency, and visual fidelity. Lower or slower presets enable the encoder to analyze the image thoroughly, producing the smallest possible file sizes while preserving fine details, but at the cost of prolonged processing times. Conversely, faster presets reduce CPU usage and encoding latency by skipping complex optimization algorithms, which either increases file size or degrades image quality. Understanding this relationship is critical for choosing the right configuration for static assets, dynamic workflows, and bandwidth-constrained delivery.

How AVIF Encoders Use Presets

AVIF is derived from the AV1 video codec, primarily utilizing encoders such as libaom, rav1e, or SVT-AV1. In these engines, presets are typically denoted numerically—such as cpu-used (ranging from 0 to 8 or 9 in libaom) or speed/preset values in SVT-AV1.

A preset determines how many algorithmic tools the encoder activates during compression, specifically:

• Block Partitioning: Deciding whether to divide an image into large blocks or microscopic segments (from 128x128 down to 4x4 pixels) to match complex visual patterns.
• Directional Intra-Prediction: Evaluating multiple spatial prediction angles to approximate pixel values before storing residual data.
• Transform Types: Choosing between discrete cosine transforms (DCT) and asymmetric discrete sine transforms (ADST) to capture different texture types.
• Rate-Distortion Optimization (RDO): Testing multiple encoding permutations to mathematically determine the best quality-per-bit ratio.

The Trade-Off: File Size vs. Processing Time

The primary effect of adjusting presets lies in the compression density achieved per unit of time.

Slower Presets (e.g., cpu-used 0–3)

• Compression Efficiency: Slower presets perform exhaustive searches across all partitioning shapes and transform modes. This allows the encoder to eliminate redundancy almost entirely, yielding the lowest possible file size for a given quality level.
• Compute Penalty: The processing time increases exponentially. Moving from a mid-tier preset down to preset 0 can increase encoding duration by hundreds or thousands of percent, often yielding diminishing returns of only 1% to 5% additional size reduction.

Balanced Presets (e.g., cpu-used 4–6)

• Compression Efficiency: These presets use heuristics to prune improbable partitioning combinations. File sizes remain within 5% to 10% of the slowest presets while cutting processing times drastically.
• Compute Benefit: These levels provide the most practical throughput for automated pipelines and production builds, striking an optimal balance between server costs and bandwidth savings.

Faster Presets (e.g., cpu-used 7–9)

• Compression Efficiency: Fast presets disable deep iterative testing, opting for larger, uniform block sizes and standard transform types. To reach the same target visual quality, the encoder must spend significantly more bits, producing files that are often 15% to 30% larger.
• Compute Benefit: Encoding latency drops to milliseconds per image, making these presets suitable for on-the-fly transformations and live generation.

Impact on Visual Fidelity

The relationship between presets and fidelity depends heavily on whether encoding is performed using a fixed target quality (Constant Rate Factor / CRF) or a constrained file size (target bitrate).

In Constant Quality Mode (CRF)

When an encoder is set to a fixed CRF value, it attempts to maintain a uniform visual threshold. At faster presets, the encoder's reduced mathematical precision causes it to miscalculate complexity, leading to subtle banding in smooth gradients or blurring in high-frequency textures (such as hair or foliage). To compensate and maintain fidelity, the encoder is forced to output a larger file. Slower presets maintain sharper edges, smoother gradients, and consistent micro-textures at smaller footprints.

In Constrained Size Mode (Target Bitrate)

If the file size is strictly capped, changing the preset directly alters visible fidelity. A fast preset forced into a small file size produces noticeable artifacts, including blocking, color bleeding, and ringing around high-contrast edges. A slow preset operating under the exact same size constraint allocates bits intelligently, keeping artifacts imperceptible to the human eye.

Recommended Preset Implementations

• Static Web Optimization (Pre-builds): Use slower settings (such as cpu-used 4 in libaom or preset 4/5 in SVT-AV1). Because the image is compressed once and served millions of times, the extra compute time pays permanent bandwidth dividends.
• Dynamic / Just-in-Time APIs: Use fast-to-medium settings (such as cpu-used 6–8). This prevents excessive server load and ensures fast response times for end-users, accepting slightly larger file sizes in exchange for speed.
• Archival Storage: Avoid preset 0 due to extreme processing overhead without proportional quality gains; preset 2 or 3 provides near-maximum AVIF compression efficiency for long-term storage needs.