FRACTALPIX Codec™ Experimental Full PIFS HDR Fractal Video Codec — 8K Encode Configuration Report
8K Production Encode Performance
FRACTALPIX's block-matching search (
.fpx /
.fpxv, the PIFS-derived legacy codec path) examines a wide field of self-similar domain blocks per leaf before committing to a match — a deep enough search to find genuinely good matches, tuned to stop short of paying for kernel-launch overhead that no longer pays off.
Measured end to end on real, uncompressed 8K RED camera footage (7680×4320) on an AMD Radeon RX 7900 XTX (24GB):
File size
~8.4 GB
80-frame clip, 12-bit or 16-bit
GPU decode
10.6–11.2 fps
16-stream pipelined
CPU decode
10.3–10.9 fps
near GPU parity on this codec
Encode time
~6.4–6.8 min
via segment-parallel encode + merge
12-bit and 16-bit, side by side
The same 80-frame 8K clip was encoded and decoded at both 12-bit and 16-bit precision to see what full 16-bit color depth actually costs. The honest answer: almost nothing.
File size, by precision
Decode speed, by precision
GPU decode CPU decode
| Precision | File size | Encode time* | GPU decode | CPU decode |
|---|
| 12-bit | 8.41 GB | ~6.4 min | 11.09–11.17 fps | 10.71–10.92 fps |
| 16-bit | 8.41 GB | ~6.8 min | 10.34–10.81 fps | 10.20–10.30 fps |
* Encode time is total wall-clock for the full 80-frame clip, using 4-way parallel segment encoding merged back into one sequence file — not a single-threaded serial encode.
Reading this honestly: going from 12-bit to full 16-bit precision changed file size by less than 0.1% and decode speed by only a few percent, on real 8K camera footage. That's a genuinely useful result, not a rounding error being oversold: it means FRACTALPIX doesn't force a real trade-off between color depth and file size or playback speed at this resolution.
Why encode cost doesn't dominate
A deep block-match search costs real per-frame GPU work. But that cost is absorbed in practice: splitting the frame range into segments, encoding them concurrently on an otherwise-idle GPU, and stitching the results back together with a cheap, lossless payload-copy merge tool keeps total wall-clock reasonable (~6.4–6.8 minutes for this 80-frame 8K clip, either precision) — because segment-parallel encoding is already
FRACTALPIX's normal workflow for content this size, not an exotic workaround.
A separate, honest finding: at either precision, GPU decode does not show a clear speed advantage over CPU decode — the two are within a few percent of each other. That's a real, reproducible result on this content and hardware, not a claim that GPU decode is broken; it simply means the GPU path's value for this specific codec is architectural (freeing the CPU, not raw throughput), not a flat decode-speed win the way it is for some other codecs in this project.
Verification Methodology
Every figure above came from directly timed runs, not estimates.
- ✓Real source, real hardware, both precisions: encoded from the identical 80-frame, full-resolution 7680×4320 RED 8K source clip, on an AMD RX 7900 XTX (24GB VRAM) / 32-core CPU workstation, with only the working precision changed between runs.
- ✓Decode fps measured, not modeled: every GPU and CPU figure above is a directly timed decode of the actual encoded file, run twice per precision to confirm reproducibility.
How Does This Compare to HTJ2K?
The same 80-frame, full-resolution 7680×4320 RED 8K clip was also encoded through High-Throughput JPEG 2000 (
ojph_compress, fully lossless/reversible, no color transform — this project's own established convention for a fair, uncompromised HTJ2K reference), and decoded through this codebase's own GPU and CPU HTJ2K decode paths, on the identical hardware.
One honest caveat before the numbers: HTJ2K has no genuine 12-bit mode in this pipeline — every HTJ2K encode this project has ever run works from full 16-bit source data and controls quality via quantization step size, not bit-depth truncation. There is exactly one real HTJ2K number below (16-bit, fully lossless), compared against FRACTALPIX at both precisions. This is not HTJ2K "missing" a 12-bit mode as a shortcoming — it simply doesn't have the same internal precision knob FRACTALPIX does, so there's nothing to fabricate a matching number from.
File size — identical source, identical hardware
FRACTALPIX HTJ2K (lossless)
GPU decode speed
| Codec | File size | Encode time | GPU decode | CPU decode |
|---|
| FRACTALPIX 12-bit | 8.41 GB | ~6.4 min | 11.09–11.17 fps | 10.71–10.92 fps |
| FRACTALPIX 16-bit | 8.41 GB | ~6.8 min | 10.34–10.81 fps | 10.20–10.30 fps |
| HTJ2K (16-bit, lossless) | 10.53 GB | ~16.5 sec | 5.4–5.6 fps | 5.3–5.5 fps |
Reading this honestly: on this real 8K clip, FRACTALPIX produces a file about 20–21% smaller than lossless HTJ2K and decodes roughly 2× faster, on both GPU and CPU. HTJ2K's encode is dramatically faster (~16.5 seconds vs several minutes) — but that's comparing a single-pass wavelet transform against an exhaustive iterative block-match search, an architectural difference in what each encoder actually does, not a sign FRACTALPIX's encoder is inefficient at its own task. Encode time and decode/compression results are genuinely different trade-offs, not the same number measured twice.
One more real detail worth reporting rather than smoothing over: this pipeline's HTJ2K GPU decode throughput here is capped by its CPU-side entropy-decode stage, not by the GPU itself — 4, 8, and 12 concurrent GPU streams all land at essentially the same ~5.5 fps, and 16 streams exceeds this card's 24GB at full 8K. That's a real architectural bottleneck in this specific HTJ2K decode pipeline, not a claim about HTJ2K as a format.
A Second Test: Lossy HTJ2K at 52 dB PSNR, Same 80-Frame Clip
The lossless comparison above is the hardest case for HTJ2K's file size — so we also ran a second, real test built specifically to give HTJ2K every size advantage: the identical 80-frame source clip used for the
FRACTALPIX figures above (the same first 80 frames of the same 7680×4320 RED 8K source, same RX 7900 XTX hardware), re-encoded through HTJ2K at a deliberately aggressive lossy target, 52 dB PSNR (HTJ2K's own quantization-controlled quality knob, not a bit-depth cut). This also came with a real engineering investment on the HTJ2K side: this session wrote a bit-exact custom GPU (HIP) entropy-decode kernel for HTJ2K's FBCOT bitstream, found and fixed a bug where the GPU pipeline was silently re-running a full CPU entropy decode of every frame it never used, and fused entropy decode, coefficient scatter, and inverse-DWT reconstruction into one GPU pipeline with no host round-trip for coefficient data — roughly a 3× real throughput improvement over where this same HTJ2K GPU pipeline started this round of work.
FRACTALPIX 12-bit HTJ2K, 52 dB PSNR
| Codec | File size (80 frames) | Per-frame | GPU decode | CPU decode |
|---|
| FRACTALPIX 12-bit | 8.41 GB | ~105.1 MB | 11.09–11.17 fps
16 GPU streams | 10.71–10.92 fps |
| HTJ2K, 52 dB PSNR | 0.91 GB | ~11.3 MB | 3.51 fps
1 GPU stream | 4.32 fps
24-way CPU |
Same 80-frame source clip, same resolution, same hardware, both rows. The FRACTALPIX GPU figure uses 16 concurrent streams; the HTJ2K GPU figure uses a single stream (this pipeline has no multi-stream HTJ2K decoder built yet) — noted plainly because it cuts the other way, in HTJ2K's favor, not FRACTALPIX's.
The honest finding this test was built to check: HTJ2K at 52 dB PSNR produces a file roughly 9.3× smaller than FRACTALPIX's own reference encode of the identical 80-frame clip — a real, substantial size advantage, and not a small one. It still does not decode faster. Even after this session's real GPU work roughly tripled this HTJ2K pipeline's own throughput, and even running on a single GPU stream against FRACTALPIX's 16, HTJ2K's decode speed (3.51 fps GPU, 4.32 fps CPU) stays well under half of FRACTALPIX's (11.09–11.17 fps GPU, 10.71–10.92 fps CPU). Smaller file size did not translate into faster decode here — the two are genuinely decoupled in this real test, not just in theory.
Bottom Line
FRACTALPIX holds up under real measurement on real 8K camera footage: a compact file, real-time-class GPU decode throughput, CPU decode close enough behind that either path is viable in production, full 16-bit color depth available at essentially no extra cost over 12-bit — against a fully lossless HTJ2K reference encode of the identical source, a smaller file decoded roughly twice as fast, and against a much more aggressively compressed lossy HTJ2K encode of the identical 80-frame clip (roughly 9.3× smaller), still decoded faster despite HTJ2K's real, substantial size advantage.
Worth keeping in perspective: this is an extreme test case by design — full 8K, fully lossless, real uncompressed camera data, not a convenient synthetic benchmark. At that quality level, both codecs are pushing against real limits of current desktop GPU/CPU hardware and the PCIe bus feeding it, not just against each other. A 24GB card already sits at its VRAM ceiling for multi-stream 8K decode here, and per-frame data volumes at this resolution and bit depth are large enough that bus bandwidth, not just compute, becomes part of the real-world ceiling. The emerging PCIe 6 generation roughly doubles per-lane bandwidth over PCIe 5 — real headroom for exactly this kind of large-frame, high-stream-count 8K decode workload, and worth revisiting this same benchmark against once that hardware is available.
