opencodecs 0.1.6__tar.gz → 0.1.8__tar.gz

{opencodecs-0.1.6 → opencodecs-0.1.8}/CHANGES.rst

@@ -10,6 +10,104 @@ Versions follow the same ``YYYY.M.D`` cadence as upstream when we
 publish; the entries below cluster work by date rather than by
 release because most of it has shipped continuously to ``main``.
 
+0.1.8 (2026-06-02)
+------------------
+
+**DCT-domain decode-time scale on JPEG + decode_native**
+
+``opencodecs.codecs._jpeg.decode`` now exposes libjpeg-turbo's
+``tj3SetScalingFactor`` knob via a new ``scale=`` kwarg (plus
+explicit ``scale_num`` / ``scale_denom`` for advanced callers). The
+decoder skips the inverse-DCT work for high-frequency coefficients
+when the caller requests a downsampled output, so a 1/8 decode runs
+~2× faster than a full decode and produces a 64× smaller raster.
+
+Supported factors are libjpeg-turbo's full set of 16 ratios N/8 for
+N ∈ {1, 2, …, 16} — i.e. anywhere between 1/8 and 2/1. The new
+``opencodecs.codecs._jpeg.supported_scaling_factors()`` returns them
+as ``(num, denom)`` pairs. ``scale=`` accepts:
+
+* an integer N (interpreted as ``1/N``)
+* a float (snapped to the closest supported ratio)
+* a tuple ``(num, denom)`` verbatim
+
+``opencodecs.uhdr.decode_native(..., scale=...)`` threads the same
+knob through both the SDR base and the gain-map JPEG decodes. The
+gain-application kernel runs on the smaller rasters, so the whole
+pipeline scales — a 2k² Ultra-HDR decode at ``scale=8`` returns a
+``(250, 250, 3)`` fp16 raster in ~25 ms vs ~53 ms for the full
+decode. Useful for thumbnail / preview pipelines that want real
+HDR pixels off cloud-stored Ultra-HDR without paying the megapixel
+JPEG decode cost. Lossless source not required — the JPEG file is
+unchanged on disk; the savings come from skipping IDCT work.
+
+(libuhdr lossless support is unchanged: ISO 21496-1's SDR base layer
+is required to be baseline DCT JPEG, so lossless-mode JPEG would
+not be a conforming Ultra-HDR file.)
+
+0.1.7 (2026-06-02)
+------------------
+
+**Patched libultrahdr bundle**
+
+Since v0.1.6 we build libuhdr ourselves; v0.1.7 starts carrying
+local patches via ``patches/libultrahdr/*.patch``, applied by
+``bench/build_codec_libs.sh::build_libultrahdr`` after the source
+fetch. Five upstream post-v1.4.0 cherry-picks land first:
+
+* ``5ed39d6`` — fix ``CLIP3`` parameter order in libuhdr's own
+  ``applyGainMap``. The bug clamped a constant ``0.0f`` instead of
+  the gainmap weight whenever ``display_boost ≠ hdr_capacity_max``,
+  silently producing wrong HDR output on libuhdr's wrapped
+  ``decode()`` path. ``opencodecs.uhdr.decode_native`` is unaffected
+  (it uses our own Cython gain-application kernel).
+* ``7088ca7`` — error-message typo in ``jpegr.cpp``.
+* ``13a058f`` — ``icc.h`` Endian_Swap macros now respect actual
+  host endianness instead of an unconditionally-true ``USE_BIG_ENDIAN_IN_ICC``.
+  No effect on x86_64/aarch64 (little-endian); fixes PowerPC/s390x.
+* ``5fa99b5`` — add missing ``<cstdint>`` include for GCC 15.
+* ``8cbc983`` — same ``CLIP3`` fix as ``5ed39d6`` in the GPU path
+  (we don't link the GPU path; carried for hygiene).
+
+**New API: ``opencodecs.uhdr.probe(data) -> dict``**
+
+Parse an Ultra-HDR container's MPF metadata without any pixel
+decode. Returns base + gainmap dimensions plus the gainmap
+metadata block (``max_content_boost`` / ``min_content_boost`` /
+``gamma`` / capacity). Wraps libuhdr's existing ``uhdr_dec_probe``
++ accessors. ~180× faster than ``decode()`` for any HDR-aware
+flow that only needs dimensions or capacity — image indexing,
+thumbnail generation, HTTP HEAD-style inspection, routing batches
+by content-boost.
+
+**Gain-map tunables on ``encode_native``: ``gain_quality`` + ``gain_scale``**
+
+Two new kwargs let callers shrink the gain-map layer
+independently of the SDR base:
+
+* ``gain_quality`` — JPEG quality for the gain-map layer only
+  (defaults to track ``quality``). The gain map is heavily
+  band-limited so ``gain_quality=70`` is visually equivalent to
+  ``q95`` and cuts ~30% off the gain-map bytes.
+* ``gain_scale`` — integer power-of-2 downsample factor for the
+  gain-map raster (``1`` keeps full resolution, ``2`` halves both
+  axes for quarter-area, etc.). Stride decimation; ~5 ms on a 2k²
+  uint8 gain map. Round-trips through ``probe`` / ``decode_native``
+  cleanly — the container records the actual gain-map dimensions
+  and the decoder upscales on apply.
+
+**True streaming encode: ``encode_native(..., out=fp)``**
+
+The old ``encode_to(fp, hdr, ...)`` was a forward-compatible
+``fp.write(encode_native(hdr, **kw))`` wrapper. v0.1.7 makes both
+genuinely streaming: ``encode_assembled`` (and by extension
+``encode_native`` / ``encode_to``) now accept an ``out=`` file-
+like, and when given they hand a zero-copy ``memoryview`` over
+libuhdr's internal output buffer to ``out.write()``. Skips the
+final ``PyBytes_FromStringAndSize`` allocation + memcpy. Saves
+~1× output-size peak memory and ~3 ms wall-clock on a 5 MB encode.
+``encode_to`` now returns ``None`` instead of the byte count.
+
 0.1.6 (2026-06-01)
 ------------------
 
@@ -69,12 +167,16 @@ streaming write-out without changing their code.
 
 **CI / build robustness**
 
-* ``_uhdr`` extension now links ``-lmvec -lm`` on Linux. GCC at
-  ``-O3 -ffast-math`` auto-vectorises the sRGB LUT-init ``pow()``
-  calls into ``_ZGV*`` symbols from glibc's libmvec. AlmaLinux 8's
-  manylinux toolchain auto-links libmvec so the issue was masked
-  in CI, but Ubuntu's GCC doesn't — caught when verifying on a
-  threadripper Ubuntu 25.04 box.
+* ``_uhdr`` extension's ``-ffast-math`` is now narrowed to
+  ``-ffast-math -fno-finite-math-only
+  -fno-unsafe-math-optimizations -fno-math-errno
+  -fno-trapping-math``. The ``-funsafe-math-optimizations``
+  sub-flag is what tells GCC to replace libm calls with libmvec's
+  vectorised ``_ZGV*`` variants, which link-fail on Ubuntu (Ubuntu's
+  default gcc doesn't auto-link libmvec like manylinux_2_28 does)
+  and aren't available at all on aarch64. Same flag set the edt
+  extension uses for the same reason. Keeps FMA + reordering
+  perf; eliminates the libmvec dependency entirely.
 * The libaec source URL moved from ``gitlab.dkrz.de`` (now
   auth-gated; anonymous requests redirect to ``/users/sign_in``)
   to DKRZ's GitHub mirror at

{opencodecs-0.1.6/src/opencodecs.egg-info → opencodecs-0.1.8}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: opencodecs
-Version: 0.1.6
+Version: 0.1.8
 Summary: Streaming, network-aware image codecs for scientific imaging (prototype: JPEG XL)
 Author: Kevin Cutler
 License: BSD-3-Clause

{opencodecs-0.1.6 → opencodecs-0.1.8}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "opencodecs"
-version = "0.1.6"
+version = "0.1.8"
 description = "Streaming, network-aware image codecs for scientific imaging (prototype: JPEG XL)"
 readme = "README.md"
 requires-python = ">=3.10"

{opencodecs-0.1.6 → opencodecs-0.1.8}/src/opencodecs/__init__.py

@@ -191,4 +191,4 @@ __all__ = [
     "CziWriter", "CziPyramidWriter",
 ]
 
-__version__ = "0.1.6"
+__version__ = "0.1.8"