The thumbnail strip learned HDR last time; now the Quality tab’s analysis graphs do too. On an HDR display they finally light up in true wide gamut instead of sitting there in pale SDR.
Chromaster v2.8.4 α
Wide-gamut Quality graphs
Every layer of the Quality graph now renders in linear-light HDR on an HDR display, instead of being clamped to washed-out SDR.
All metric traces in HDR — VMAF, SSIM, PSNR, Y-PSNR, VDP-2, VDP-3 and ICtCp curves render in FP16 wide gamut, brighter and more saturated per value.
Spread bands in HDR — the min / max / average “smoke” spread is composited in linear light, richer against a wide-gamut backdrop.
Waterfall heatmap in HDR — the cascade mode gets the same treatment, grid still readable under the curtains.
SDR left untouched — on an SDR display it’s pixel-for-pixel identical to before, proven byte-for-byte by identity harnesses.
No-flicker transitions
Clean threshold drag — dragging the waterfall threshold drops to SDR for the live adjust, then snaps back to HDR the instant it settles. No flicker, no half-rendered frames.
Seamless mode switch — flipping between curve and cascade transitions through SDR, then re-lights the new mode in HDR.
Correct layer selection — the spread / curve / both selector now shows exactly what you picked; the spread “smoke” no longer bleeds through in curve-only mode.
Also fixed
Sub-tab restoration — closing the app on the Luminance or Chroma tab now brings you right back to that sub-tab on launch, instead of the collapsed parent.
Continued cleanup — another audit pass collapsed more duplicated plumbing into single sources of truth and tightened buffer handling, all behavior-neutral and harness-proven.
Teaser — New CPU support incoming: Threadripper branch
Full topology awareness for high-core-count AMD chips — per-die layout, per-CCX cache, NUMA-aware core mapping. Tested on a 32-core / 4-die 2990WX.
Modern codecs rarely scale a single encode past ~12-16 threads — that’s a structural limit, not a bug. So instead of fighting it, the Threadripper branch explores feeding all those cores by running work in parallel, each job pinned to its own die to dodge the NUMA memory penalty:
NUMA-pinned batch parallelism — multiple encodes / QA passes at once, one per die, near-memory only
Chunked encoding(exploratory) — scene-aware splitting across dies for single-file throughput
Chromaster — Threadripper support, and a QA reckoning
Big one. The CPU widget learned high-core-count AMD chips from the ground up, the GPU die got its real board layout, and a deep dive into the Quality tab turned up a few uncomfortable truths that are now fixed.
Chromaster v2.9.0 α
GPU widget Threadripper / AMD quad-die CPU support
Built and tested on a 32-core / 4-die Threadripper 2990WX (Zen+), alongside the usual 9950X (Zen 5).
Three-level topology detection — die → CCX → cores, built from NUMA nodes instead of assuming one L3 domain equals one die. A 2990WX now reports 4 dies / 8 CCX / 32 cores / 64 threads instead of losing two thirds of the chip.
2×2 die grid ▦ — four dies lay out across two rows at full size; the group grows to fit rather than shrinking the artwork.
Dual-CCX die rendering — Zen+ splits every die into two CCX with their own private L3, and the widget now draws it that way. Zen 5’s unified single-CCX die is untouched.
Per-core temps across all nodes — HWiNFO exposes CPU sensors per NUMA node on multi-die chips. The matching now reads the die suffix, so all 32 cores get their real temperature instead of the first eight overwriting each other.
Frequency remapping — Windows enumerates NUMA nodes in a different order than the physical dies, so clocks were landing on the wrong die. Now remapped: temps and frequencies finally tell the same story under load.
Contextual core legend — the blue-core legend always claimed “used by SVT-AV1 encoder”. It now names the codec actually running, or the HDR / quality analysis phase.
QA parallelism
HDR-VDP worker cap lifted — was hard-coded to 16, a leftover from a 16-core machine. It now derives from the real core count: 31 workers on a 32-core box, FIFO scaled to match.
Some of these were wrong for a while. They’re right now.
PSNR was actually Y-PSNR — the parser read the luma-only field and labelled it “PSNR”. It now reads the true three-plane average, so PSNR and Y-PSNR are finally two different curves.
VDP metrics on resized encodes — the HDR-VDP reader compared raw streams with no spatial normalization, so any resized trial produced garbage (frames read at the wrong byte size). The reference now goes through the exact crop+resize chain that produced the encode, matching the VMAF graph’s semantics.
Resize chain persisted per trial — that chain used to live in a volatile session snapshot, lost on restart. It’s now written into each trial’s sidecar and restored on load, so reloaded trials stay analysable.
Dimension guard — when a trial’s chain genuinely can’t be reconstructed, analysis is refused with a clear message instead of collapsing inside FFmpeg with a cryptic error.
Curve overshoot clamped — VDP and ICtCp splines could overshoot past 0 and 100 between samples. Control points are now clamped to the plot bounds.
Real die layout — VRAM chips follow the actual board plan (3 top / 4 left / 4 right / 1 bottom on a 384-bit card) instead of a symmetric fiction, derived from the detected chip count.
Separate GPU and VRAM gradients — two bars, two scales. Memory tolerates far more heat than the die, so a single shared scale was misleading.
Dynamic quality labels — CRF, QP and QVBR sliders now describe what the value actually means, on a 10-tier scale from “Lossless-grade” down to “Heavy loss”, calibrated per codec since each has its own range. QP floor/ceiling read as “Best case: …” / “Worst case: …”.
External audit applied — a full-codebase audit pass: private globals actually made private, buffer capacities derived from their declarations instead of repeated literals, and a dozen duplicated code paths collapsed into single sources of truth. All behaviour-neutral, harness-proven.
Update check fixed — SVT-AV1 update detection compared against the upstream GitLab release, but the Windows binaries come from MSYS2, which lags. It now checks the source it actually installs from: no more phantom updates you can’t get.
No new tab this time. Chromaster now builds, ships and updates its own SVT-AV1 binary, stopped trusting version numbers to decide what an encoder can do, and caught two settings that had been quietly lying.
Encoder embedded in the exe — a self-built static SVT-AV1 ships as a compressed resource, extracted by the wizard. No download on first run, no companion DLL, no waiting on a packager.
Updates from our own releases — the check now reads this repo’s GitHub releases. Detection and download hit the same source by construction: impossible to announce one version and install another. The MSYS2 path is gone — it dragged a generic package and an orphan DLL on top of an optimised build.
Commit suffix in Settings — SVT-AV1 and AV2 show their full git identity (4.2.0-13), not a bare tag.
Feature gates: ask the binary, not the version
A slider gated on “SVT-AV1 ≥ 4.2.0” refuses to work on a mainline build from three weeks earlier that supports the option perfectly well — 4.1.0-347-g… parses as {4,1,0}. Version numbers say how far past a tag you are, not what the binary can do. Chromaster now probes --help and gates on what the encoder actually documents. Works on tags, mainline, forks.
HBD-MDS slider — on a 10-bit source, the encoder can run its mode decisions on 8-bit-truncated samples (faster, poorer choices) or full 10-bit (slower, truer). Output stays 10-bit either way — only the decision quality changes. Fast presets default to 8-bit, so that’s where the win is. Steps ordered by precision, not by raw option values.
Screen content mode toggle — --scm 3, anti-alias-aware detection. Aimed at animation: it’s the treatment drawn lines actually get.
Two settings that were lying
Both found by reading SVT-AV1’s source, not its docs.
CRF could silently become CQP — SVT has no field distinguishing the two: str_to_crf and str_to_cqp are the same code with one line different (aq_mode 2 vs 0). So --rc 0 --crf 22 --aq-mode 0 builds a byte-identical config to a CQP encode — TPL off, encoder banner reading “CQP” — while the UI still says CRF. AQ=0 is now forbidden everywhere except CQP, where it’s legitimate.
A slider that looked alive and wasn’t — the Adaptive Quantization slider was drawn at full opacity in CRF but frozen at 2, unreachable by mouse. A leftover from when AQ=0 was reachable and dangerous, kept long after the guard closed that hole. Both valid values are now selectable.
Benchmarking
Encode duration logged — Finished successfully in 770.2 s (00:12:50), measured on the encoder alone: no remux, no merge, no metadata. Comparable numbers, which is the point.
-march=znver5 measured 0.36% faster than the generic build. That’s noise: SVT dispatches its SIMD kernels at runtime, so -march only touches the scalar glue. The portable build stays.
Test harnesses: a reckoning
All 28 standalone harnesses compiled and run. No production defect found — but the nets themselves were rotting.
Two were dead — including the one covering QA sidecar persistence, broken for weeks at link stage. Invisible because these files are never in the main build.
The silent trap — a table sized [N][ENUM_COUNT] whose enum grew: the last column zero-fills. No error, no warning. The harness stays green over ground it no longer tests.
Eight immunised — tables now locked to their enum by a compile-time assertion. Growing an enum breaks the build instead of quietly zero-filling.
Under the hood
Project mode: the codec wins — switching codec left the trial selected, so an AV2 session could point at an AV1 trial. Changing codec now clears it; stale selections are purged on load.
FFV1 lands in Chromaster: the open, royalty-free, IETF-standard lossless codec the archival world runs on. Two encoding paths, a bit-exact guarantee, and — for those who want the bleeding edge — an experimental Level 4.
Sixth codec, alphabetical slot — FFV1 sits between AV2 and H.266 in the picker, without shifting any existing codec’s identity. Your old projects and templates are untouched — a trial tagged AV2 stays AV2.
Two encoding paths — a Software path (default) that encodes any subsampling at any resolution in frozen, standardized Level 3, and a Vulkan path built on FFmpeg 8’s compute-shader encoder for machines where the GPU beats the CPU. One toggle, and the format constraints adapt honestly to what each path can actually do.
Bit-exact, verified — lossless means lossless: round-trips are byte-identical, proven at the bench frame by frame. Per-slice CRC is on by default, so an archive can self-verify its own integrity.
Not a machine-vendor codec — the Vulkan path is compute shaders, not the fixed-function media block. Cross-vendor, hardware-agnostic — it runs on any Vulkan 1.3 implementation.
The Level control is a slider showing the real value handed to the encoder — 3 or 4, exactly what ships in the command line, never a disguised index.
Level 3 is the frozen, standardized bitstream (RFC 9043) — readable by every future decoder, the reference choice for long-term archival.
Level 4 is cutting edge — the newest, not-yet-frozen FFV1 revision, straight off FFmpeg’s Vulkan path. It’s my favourite toy in this release, and the UI is honest about the trade: a warning panel spells out that the bitstream may still change and future decoders may fail to read it. Bleeding edge for those who want it, clearly labelled for those who don’t.
The Dependencies panel now probes for Vulkan, the way it already checks everything else. No more silent spinner-of-death when a Vulkan-only path is picked on a machine without a driver — you see availability at a glance, and the Vulkan encoding path greys out cleanly when it’s missing.
The project registry grew a sixth column for FFV1. The dead space to the right of the metric dots was reclaimed first, so the container+codec group keeps its width — the cells didn’t shrink, the wasted margin did.
No new feature this time — this one’s a deep cleanup. Two independent code audits, worked through top to bottom, plus a handful of fixes you’ll actually feel.
What you’ll notice
HDR previews behave — switching source no longer leaves the previous clip’s HDR thumbnails hanging around, and stops leaking video memory in the background.
Controls that are honest — the CRF adaptive-quantization slider is now usable where it makes sense, instead of looking active but frozen. And a leftover value from one codec can no longer block an encode on a completely different one.
No more phantom warnings — an unconfigured dependency used to fire a scary “security” alert at startup for no reason. Gone. When a path really is rejected, it now tells you the actual reason.
A trash icon worth looking at — the delete button is a proper graphic now, in a red that actually stands out.
The Template block (display / content / priority) has been substantially expanded: it now configures four encoders — AV1 (SVT-AV1), AV2, AV1 NVENC and H.266/VVC — rate control mode included, so what you pick genuinely lands in the encode.
Pick three things, get a full setup — display type, content type, priority. The encoder configures itself, whichever of the four you’re on.
Bitrate worked out for you — derived from your real output resolution (after crop and resize) and the source frame rate, then adjusted for content. Animation needs far fewer bits than grainy film, and the estimate knows it.
Archive always wins — set content to Archive and you get maximum fidelity and the slowest preset, whatever the priority says.
Film grain synthesis — proper level slider on SVT-AV1, switched on automatically for film grain content.
A score grid that means something — every bar is derived from the values actually being set. Where an encoder has no equivalent control, the column stays flat rather than animating for show.
ProRes and FFV1 stay out of it — FFV1 is lossless and ProRes is profile-driven; neither has enough quality levers for a template to be meaningful, so their grid stays dimmed on purpose.
Also fixed
Bitrate fields floored at 100 kb/s across all four bitrate-capable encoders (an empty field could produce an invalid command line).
Template positions are now per-codec instead of shared.
Score grid palette recalibrated.
Nothing here is set in stone: the values come from theory and will be fine-tuned after long API-driven batches with QA metrics behind them. If a template picks something that looks off for your footage, say so — that’s exactly the kind of feedback that moves the numbers.
The lack of a code signing certificate, as it’s way too expensive—around $250.
Nowadays, all antivirus scanners use AI to detect patterns, which leads to a ton of false positives.
Trust me, I put a lot of effort into the security of my app. I just ran a full, deep audit using Kimi K3 (costing me $30) to weed out even the tiniest issues, and every single vulnerability has been fixed. Honestly, if this program were actually a virus, I certainly wouldn’t risk posting it here.
Regardless, I’m taking your feedback on board and will try to smooth things over, though I can’t guarantee anything.
Full core count on Threadripper — 16 cores shown out of 32 on Zen 2. Same truncated topology fed the affinity masks: every encode ran on half the machine, silently. Fixed.
The schematic derives itself from the hardware — rows, columns, cache blocks and SMT bands, all from what the system reports. 24-core Intel, 8-die Threadripper, EPYC in NPS2: correct drawing, not a partial one.
Hybrid CPUs read properly — performance and efficiency cores detected. SMT bands per core, from the real mask. No more phantom hyperthreading on E-cores.
Real cache sizes — Zen 2 has one L3 per 4-core complex, not one per die. “8×16MB” instead of “4×32MB”.
CPU topologies now handled
AMD desktop (Zen 2 → Zen 5)
Single or dual die, unified or split L3, asymmetric cache sizes across dies.
Threadripper / Threadripper PRO
4 to 8 dies, single or multi NUMA node. Split L3 per 4-core complex on Zen 2, unified per die from Zen 3. Asymmetric complexes, harvested dies. Up to 64 cores, SMT on or off.
EPYC
High cache-domain counts, small complexes, NPS1 through NPS4 node partitioning.
Intel
Monolithic dies with many cores under a single L3. Hybrid topologies — performance and efficiency cores, per-core SMT.
Unknown hardware
Layout derived from what the system reports. Grouping applied only where unprovable, and flagged as inferred.
2.44 MB instead of 10.9 — encoders no longer compressed inside the binary. Downloaded like every other dependency, through the same verified path.
Nothing extracted, nothing phoned home — no executable ships inside. No network call at startup.
ChromAV2 Player as a dependency — own line in the wizard and in Settings, optional, never blocks an encode. Rebuilt against latest dav2d: 7.8 MB → 2.7 MB.
Security audit — nine passes, all shipped
Full external static audit (Kimi K3), then nine correction passes.
Memory safety — several bounds and lifetime issues closed across project handling, thumbnail cache and quality analysis.
Thread lifetime — shared state no longer released while worker threads may still touch it. Handles owned by a single thread, closed at one place.
Untrusted input budgeted — every file read from disk now validated against its real size before allocation, with hard ceilings.
Integrity checks that actually check — crypto failures propagated instead of reported as success. A corrupt file is rejected, never parsed.
No more silent failures — failed allocations no longer returned as valid results. Failed operations report instead of guessing.
Dependency install hardened end to end — redirection blocked, truncated downloads rejected, publisher signature verified, previous binary recoverable.
Local control surface locked down — pipe and script commands validated server-side, restricted when elevated.
Every pass proven by dedicated test harnesses, kept in the repo and replayed on each subsequent change.
Also fixed
AV2 encoder updates itself now, like SVT-AV1. Previously frozen until the whole app was rebuilt.
Dependencies sitting next to the executable are picked up automatically.
Long security pass: integrity checks on cache and analysis sidecars, publisher signature verification on installed binaries, silent failure paths made loud.
Package is two files now: Chromaster.exe and ChrMonitor.exe. Everything else downloads. Existing installs untouched.
A word on antivirus: unsigned, low-prevalence binaries get flagged on heuristics alone. Nothing bundled, nothing persistent, nothing injected — smaller and cleaner than it has ever been.
This doesn’t appear to be a HWMonitor Pro feature itself. HWMonitor Pro is a paid application, and I’m not encouraging anyone to purchase it just for this.
The interesting part is that NVIDIA’s Blackwell GPUs seem to expose more individual thermal sensors (or sensor groups) through the driver/firmware than previous generations.
We don’t have any official documentation, so there’s no certainty about what these channels actually represent or where they’re physically located on the die—they’re simply additional thermal readings that appear to be exposed on Blackwell.
— VMAF, SSIM, PSNR, Y-PSNR, VDP-2, VDP-3 and ICtCp curves render in FP16 wide gamut, brighter and more saturated per value.
— the min / max / average “smoke” spread is composited in linear light, richer against a wide-gamut backdrop.
— the cascade mode gets the same treatment, grid still readable under the curtains.
— on an SDR display it’s pixel-for-pixel identical to before, proven byte-for-byte by identity harnesses.
— dragging the waterfall threshold drops to SDR for the live adjust, then snaps back to HDR the instant it settles. No flicker, no half-rendered frames.
— flipping between curve and cascade transitions through SDR, then re-lights the new mode in HDR.
— the spread / curve / both selector now shows exactly what you picked; the spread “smoke” no longer bleeds through in curve-only mode.
— closing the app on the Luminance or Chroma tab now brings you right back to that sub-tab on launch, instead of the collapsed parent.
— another audit pass collapsed more duplicated plumbing into single sources of truth and tightened buffer handling, all behavior-neutral and harness-proven.
Teaser — New CPU support incoming: Threadripper branch 
— die → CCX → cores, built from NUMA nodes instead of assuming one L3 domain equals one die. A 2990WX now reports 4 dies / 8 CCX / 32 cores / 64 threads instead of losing two thirds of the chip.
— Zen+ splits every die into two CCX with their own private L3, and the widget now draws it that way. Zen 5’s unified single-CCX die is untouched.
— HWiNFO exposes CPU sensors per NUMA node on multi-die chips. The matching now reads the die suffix, so all 32 cores get their real temperature instead of the first eight overwriting each other.
— the blue-core legend always claimed “used by SVT-AV1 encoder”. It now names the codec actually running, or the HDR / quality analysis phase.
QA parallelism 
HDR-VDP worker cap lifted 
Quality metrics: correctness fixes 
— the parser read the luma-only field and labelled it “PSNR”. It now reads the true three-plane average, so PSNR and Y-PSNR are finally two different curves.
— the HDR-VDP reader compared raw streams with no spatial normalization, so any resized trial produced garbage (frames read at the wrong byte size). The reference now goes through the exact crop+resize chain that produced the encode, matching the VMAF graph’s semantics.
Dimension guard 
— VDP and ICtCp splines could overshoot past 0 and 100 between samples. Control points are now clamped to the plot bounds.
Real die layout 
— “NVEncC” → “AV1 Hardware encoder”, “cuFFT” → “CUDA Fast Fourier Transform”.
SVT-AV1 supply chain, in-house 
— a self-built static SVT-AV1 ships as a compressed resource, extracted by the wizard. No download on first run, no companion DLL, no waiting on a packager.
— SVT-AV1 and AV2 show their full git identity (
New SVT-AV1 4.2.0 controls 
— 
Two settings that were lying 
— the Adaptive Quantization slider was drawn at full opacity in CRF but frozen at 2, unreachable by mouse. A leftover from when AQ=0 was reachable and dangerous, kept long after the guard closed that hole. Both valid values are now selectable.
Benchmarking 
than the generic build. That’s noise: SVT dispatches its SIMD kernels at runtime, so 
— including the one covering QA sidecar persistence, broken for weeks at link stage. Invisible because these files are never in the main build.
— a table sized 
— FFV1 sits between AV2 and H.266 in the picker, without shifting any existing codec’s identity. Your old projects and templates are untouched — a trial tagged AV2 stays AV2.
— the Vulkan path is compute shaders, not the fixed-function media block. Cross-vendor, hardware-agnostic — it runs on any Vulkan 1.3 implementation.
— switching source no longer leaves the previous clip’s HDR thumbnails hanging around, and stops leaking video memory in the background.
— an unconfigured dependency used to fire a scary “security” alert at startup for no reason. Gone. When a path really is rejected, it now tells you the actual reason.
— the delete button is a proper graphic now, in a red that actually stands out. 
— display type, content type, priority. The encoder configures itself, whichever of the four you’re on.
— set content to Archive and you get maximum fidelity and the slowest preset, whatever the priority says.
— FFV1 is lossless and ProRes is profile-driven; neither has enough quality levers for a template to be meaningful, so their grid stays dimmed on purpose.
— no executable ships inside. No network call at startup.
— own line in the wizard and in Settings, optional, never blocks an encode. Rebuilt against latest dav2d: 7.8 MB → 2.7 MB.
— several bounds and lifetime issues closed across project handling, thumbnail cache and quality analysis.
— shared state no longer released while worker threads may still touch it. Handles owned by a single thread, closed at one place.
— redirection blocked, truncated downloads rejected, publisher signature verified, previous binary recoverable.
Just kidding.
