How MIAF Restricts AVIF for Interoperability
The Multi-Image Application Format (MIAF) provides a standardized set of constraints that limits the vast optional features of the High Efficiency Image File Format (HEIF) and the AV1 codec. Because AVIF is fundamentally built on top of MIAF, it inherits these constraints to prevent fragmentation across operating systems, browsers, and hardware decoders. By establishing strict boundaries for codecs, color representations, structural transformations, and container layouts, MIAF ensures that any compliant AVIF image decodes consistently and reliably everywhere.
Codec Profiles and Level Constraints
The raw AV1 video specification supports a wide range of decoding parameters, many of which exceed the capabilities of consumer hardware decoders. MIAF, together with the AVIF profile definitions, maps image decoding to specific AV1 profiles and operating levels.
- Baseline Profile: Limits the AV1 configuration to the Main Profile, Level 5.1. This restricts image sizes to a maximum of approximately 8K resolution (or 8,912,896 pixels per frame) and restricts bit depth to 8-bit or 10-bit color.
- Advanced Profile: Extends capability up to AV1 Level 6.0, permitting resolutions up to roughly 16K (35,651,584 pixels) and allowing 12-bit color paths.
By bounding resolutions, tile allocations, and bit depths to established hardware decoder levels, MIAF prevents scenarios where an encoder creates an arbitrary format that software fallbacks must decode inefficiently.
Strict Color and Subsampling Rules
Color handling across the web often suffers from ambiguous or contradictory metadata. MIAF standardizes color signaling to avoid color rendering mismatches:
- Chroma Subsampling: MIAF primarily permits 4:2:0 and 4:4:4 subsampling formats. It requires explicit signaling of chroma sample positioning, eliminating alignment artifacts around high-contrast edges.
- Color Profiles: Ambiguities between generic ICC profiles and standard video transfer functions are resolved by strictly defining priority. If an image uses standard color spaces (such as sRGB, Display P3, or BT.2100 HDR), it must favor standard NCLX (Colour Information) property boxes. When an ICC profile is used, it must be restricted to standard color spaces to avoid computationally expensive transforms.
- HDR Metadata: Mastering Display Color Volume (MDCV) and Content Light Level Information (CLLI) boxes are strictly standardized, ensuring consistent tonemapping across different displays.
Transformation and Derivation Limits
HEIF theoretically permits arbitrary mathematical transformations and deeply nested item combinations. MIAF significantly streamlines these capabilities to keep decoders lightweight:
- Restricted Transforms: Only three basic
transformations are permitted: rotation (
irot) in 90-degree increments, horizontal mirroring (imir), and pixel cropping using clean aperture (clap). Arbitrary matrix transforms are forbidden. - Grid Assemblies: For large images split into
smaller tiles (using the
gridderived image item), MIAF requires identical tile dimensions (except possibly the rightmost and bottommost edges) and restricts the grid to rectangular arrangements. This prevents complex or asynchronous tile assembly. - Alpha Channels: Transparency must be handled
through auxiliary image items (
auxl) linked via specific reference types (auxv). MIAF dictates that auxiliary alpha planes must share identical dimensions with the primary color image, preventing the need for complex scaling pipelines during composition.
Standardized Container Structure
To optimize parsing speed and reduce memory consumption on resource-constrained devices, MIAF imposes rules on the underlying ISOBMFF container:
- Box Placement: Essential metadata boxes (such as
the
metabox and the item locationilocbox) must appear near the start of the file, allowing decoders to understand the image structure before the entire payload is downloaded. - Brand Signaling: Files must declare the
miafstructural brand alongside the AVIF-specific brand (aviforavis) in the file type (ftyp) box. This allows decoders to verify compatibility before allocating decoding memory.