Skip to content

fix(feature): float_psnr, ciede and picture_copy take every depth from 8 to 16 bits (RC4 WP13) - #2378

Draft
lusoris wants to merge 6 commits into
rc4/api-wp13-input-formatsfrom
rc4/api-wp13-odd-depths
Draft

lusoris wants to merge 6 commits into
rc4/api-wp13-input-formatsfrom
rc4/api-wp13-odd-depths

Conversation

@lusoris

@lusoris lusoris commented Oct 6, 2026

Copy link
Copy Markdown
Contributor

BLUF: RC4 WP13 follow-up (draft, stacked on #2376). float_psnr and ciede score 9, 11, 13, 14 and 15 bits with their exact twins changed in the same PR (CUDA, HIP, SYCL; Metal refuses the new depths by name until run on a device). psnr_hvs above 12 bits stays refused. ADR-2164.

Also found and fixed: picture_copy() (behind every float_* extractor) divided by 4, 16, 256 for 10, 12, 16 bits only and read any other high depth as 8-bit bytes, so float_ssim, float_ms_ssim, float_adm, float_vif, float_motion returned wrong scores for 9, 11, 13, 14, 15 bit input without an error (9 bits: float_psnr 19.97 dB against 34.59 dB for the same samples at 16 bits).

Failing first: test_odd_depths_float_psnr_ciede (CPU, independent oracle: same samples at 16 bits, peak written out) fails on the old code (-EINVAL; and with only picture_copy reverted, the 15 dB difference). The twin parity tests fail without the twin changes (CUDA -22, HIP -22 on gfx1036). Measured with the fix: test_{cuda,hip,sycl}_float_psnr_parity bit-identical at 9, 11, 13, 14, 15 bits (noise and identical frames) and test_{cuda,hip,sycl}_ciede_parity within 1e-9, on the RTX 4090, gfx1036 in the ROCm 10.1 image, and the Arc A380. Fast suite 367 ok, 0 fail. Golden gate 280 passed, 3 skipped. tidy: cpu, cuda, hip, sycl on the touched files, 0 findings.

Open: Metal (WP13-5, T-METAL-FLOAT-PSNR-ODD-DEPTHS-2026-10-07); the other float_* twins at odd depths are not measured (T-FLOAT-EXTRACTORS-ODD-DEPTH-TWINS-UNMEASURED-2026-10-07).

Reproduce: python3 scripts/ci/run_meson_test.py -- -C build-cpu --suite=fast; vmaf -r a.yuv -d b.yuv -w 576 -h 324 -p 420 -b 9 -n --feature float_psnr.

  • Research digest: no digest needed: the ADR carries the measurements
  • Decision matrix: in ADR-2164 ## Alternatives considered
  • AGENTS.md invariant note: no rebase-sensitive invariants beyond docs/rebase-notes.md (the HIP constant table note is in core/src/feature/hip/AGENTS.d/ciede.md)
  • Reproducer / smoke-test command: above
  • CHANGELOG fragment: changelog.d/fixed/float-extractors-odd-bit-depths.md
  • Rebase notes: docs/rebase-notes.md

…ith a stated matrix, CLI layouts (RC4 WP13, ADR-2145, ADR-2146)

Work in progress: device runs, SYCL and Metal requests, docs and gates follow.
…pth, docs and state (RC4 WP13, ADR-2145, ADR-2146)
…m 8 to 16 bits, twins in step (RC4 WP13, ADR-2164)
@lusoris lusoris added the rc4 RC4: the vmaf_v1.0.16_3d0h path in Rust; lands after the v1.0.0-rc.3 tag label Oct 6, 2026
@github-actions github-actions Bot added the type:bug Something isn't working label Oct 6, 2026
lusoris added a commit that referenced this pull request Oct 7, 2026
…instead of scoring them wrongly (#2379)

float_ssim, float_ms_ssim, float_adm, float_vif and float_motion normalise samples with picture_copy() on the CPU, and their GPU twins mirror it: both scale 10, 12 and 16-bit samples only and read every other depth above 8 as 8-bit bytes, so 9, 11, 13, 14 and 15-bit pictures fed through the C API got wrong scores without an error. vmaf_feature_extractor_context_init() now refuses those depths for the five families on every backend, with -EINVAL and a log line naming the extractor and the depth; psnr_hvs keeps its 9 and 11-bit support. test_read_pictures_bpc covers every family and depth and fails with the guard disabled. Full support for every depth lands in RC4 with #2378.
@lusoris
lusoris force-pushed the rc4/api-wp13-input-formats branch from c7d73cb to 6be0935 Compare October 7, 2026 06:17

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

rc4 RC4: the vmaf_v1.0.16_3d0h path in Rust; lands after the v1.0.0-rc.3 tag type:bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant