TinyEXR

texpipe — resize-aware texture compression

texpipe is a tool that integrates two standalone libraries—tir (content-aware image resizing) and texcomp (block compression)—to build content-aware mip chains and serialize them into multi-mip GPU texture containers like DDS and KTX2.

It is written in pure C11. While the library (libtexpipe) is designed for integration, the texpipe_cli provides a command-line interface for file I/O and batch processing.

nanozlib is a nanoscale, secure zlib decoding and encoding library written in portable C/C++. It is designed for embedding zlib support into C/C++ applications where security and robustness are priorities.

Key characteristics:

• Decoding: Uses Wuffs std/zlib for highly secure decoding. It is designed to be resistant to corrupted or malicious zlib data, avoiding asserts, C++ exceptions, and segmentation faults.
• Encoding: Uses stb_zlib for somewhat secure compression.
• Limitations: Supports up to 2GB and adds approximately 50 KB or more to the compiled binary size (even with -Os).

The TinyEXR texcomp texture-compression suite (located under tools/texcomp/) is licensed under the Apache License, Version 2.0.

Note that this is a specific licensing choice for the texcomp subcomponent; the rest of the TinyEXR project uses the BSD-3-Clause license. The Apache-2.0 license is compatible with BSD-3-Clause for combined or redistributed works.

tocio is a pure-C11 OpenColorIO (OCIO) configuration engine and code generator. It parses OCIO YAML subsets and resolves color transforms into CPU (SSE2/AVX2, NEON) or GPU (GLSL, Metal) execution paths.

Key Features

• ACES 2.0 Support: Includes SDR, HDR, and D60-simulation variants, along with various input/output encodings (ACEScg, sRGB, PQ, etc.).
• Execution Modes: CPU interpreter, AOT C source generation, GLSL/Metal shader generation, and JIT (x86-64/AArch64).
• Supported Formats: OCIO YAML, Iridas .cube, Sony .spi1d/.spi3d, and ACES CLF LUT files.

Build Commands

make tocio-lib         # Build build/libtocio.a
make tocio-test        # Run unit tests
make tocio-validate    # Numerical validation against PyOpenColorIO

Miniz provides several high-performance data compression and archive capabilities:

• zlib/Deflate Compatibility: Acts as a drop-in replacement for the most commonly used zlib APIs. It is a completely independent implementation, so zlib licensing does not apply.
• Streaming/Coroutine API: Supports stream-based processing. The low-level tdefl (compressor) and tinfl (decompressor) APIs use simple state structs that can be saved/restored via memcpy. These low-level APIs do not use the heap.
• Archive Manipulation: Includes a set of APIs for reading, writing, and appending .ZIP format archives, designed for embedded, mobile, or game development.
• PNG Support: Contains simple functions for writing .PNG format image files.
• Portability: Written in plain C, tested with GCC, clang, and Visual Studio, and can be easily tuned or trimmed using preprocessor defines.

As of the current documentation, SIMD acceleration for the HTJ2K cleanup-pass entropy decoder (specifically the MagSgn magnitude/sign reconstruction step) is not yet implemented and is currently in the scoping phase.

While research into AVX2 implementations (1-quad and 2-quad batching) was conducted, they were found to be either break-even or slower than the optimized scalar implementation (JphQuadMs) due to the overhead of window fetches and the efficiency of the scalar lazy-loading approach.

Current Status: The project has decided to stick with the optimized scalar JphQuadMs (commit a4cb990) as the primary implementation for the entropy decode workload, as it minimizes bitstream fetches and provides the best performance-to-complexity ratio on current hardware.

TinyEXR V3 provides detailed error reporting with context (including byte positions).

C++ API

Errors are returned via Result<T>. You can iterate over result.errors to get descriptive strings.

C API

Use exr_context_get_last_error to retrieve an ExrErrorInfo struct containing the error message and the byte position where the error occurred.

// C++ API
auto result = decoder.parse_header();
if (!result) {
    for (const auto& err : result.errors) {
        std::cerr << err.to_string() << "\n";
    }
}

// C API
ExrErrorInfo error;
if (exr_context_get_last_error(ctx, &error) == EXR_SUCCESS) {
    printf("Error: %s at byte %llu\n", error.message, error.byte_position);
}

The xbc7 format is a texcomp-native implementation of the XBC7 concept (windowed RDO + entropy coding of BC7).

• It is not bitstream-compatible with Basis XBC7.
• It uses zstd for entropy coding the BC7 stream.
• It transcodes directly to standard BC7.

The HTJ2K decoding process distinguishes between two paths for MagSgn (magnitude/sign) reconstruction:

• int32 path (jph_decode_block): This is the high-value, common case where missing_msbs < 30 and kmax <= 30. In this path, a quad's 4 samples consume $\le 124$ bits, meaning a single 128-bit fetch per quad is sufficient. This is the primary target for potential future SIMD optimization.
• int64 path (jph_decode_block64_cleanup): Used for float/32-bit data where samples can be up to 62 bits. Because a quad can exceed 128 bits in this mode, the decoder remains scalar to match the behavior of OpenJPH and ensure correctness.