vibranceGUI 2.10.0

vibranceGUI v2.10.0

Two downloads. Take x64 unless you are on 32-bit Windows. Each zip is two files, no installer — unzip anywhere and run vibrance.GUI.exe. The title bar names which build you are on: vibranceGUI (NVIDIA, x64, 2.10.0).

Your display gets put back after a crash

Until now, vibranceGUI only undid what it had done if you closed it properly. A Task Manager kill, a crash, or a logoff reached none of its cleanup — so a game's vibrance level, and its resolution if you use per-game resolutions, simply stayed on the display.

Most of that quietly repaired itself on the next launch, which is why this was never as visible as it sounds. One case did not: a level left on a display that is not your primary monitor, with the default "affect primary monitor only" setting on. Nothing ever named that display again. It stayed saturated indefinitely. That is the shape of upstream juv#95 — alt-tab to another monitor, and it never comes back.

vibranceGUI now writes down which displays it has taken away from their normal state, and restores them the next time it starts.

It will not overwrite a change you made yourself. Before touching anything it checks whether the display is still sitting at the exact level or mode it set. If you have since changed that monitor by hand — in the NVIDIA control panel, or anywhere else — it is left alone and the record is thrown away. A display already back to normal is also left alone. Only a display still holding the value vibranceGUI itself wrote gets restored.

Which vendor gets what:

• Resolution restore works on both NVIDIA and AMD.
• Vibrance restore is NVIDIA-only. The AMD driver gives no way to read a display's current saturation back, so there is no way to tell your change from ours — and a restore that cannot check first is a restore that overwrites deliberate choices. AMD is left exactly as it was rather than made worse.
• Gamma and colour settings are not covered yet.

Please read this before trusting it

Nobody has yet killed vibranceGUI with a game running and watched a display come back.

The machinery is thoroughly tested — when the record is written, when a display is left alone, what happens to a half-written file, what happens when a monitor is unplugged between sessions. 732 automated checks across fifteen fixtures, on both architectures, none failing. But every one of them drives fake devices. The one thing that would really prove this feature — the full kill-and-relaunch cycle on a real monitor — has not been seen working by anyone.

So this release is worth trying precisely because it needs trying. If you want to exercise it deliberately:

1. Put a game profile on a non-primary monitor and let it apply. That is the case that was permanently broken; the primary always healed itself.
2. Kill vibranceGUI from Task Manager — a clean exit already worked.
3. Start it again. That monitor should go back.

And the counter-test, which matters just as much: change that monitor's vibrance yourself while vibranceGUI is closed, then start it. It should leave your change alone.

It writes two small files under %APPDATA%\vibranceGUI\ — vibranceRestore.xml and resolutionRestore.xml. Deleting them is always safe; it just forgets any restore that was pending.

Also in this release

• The record is keyed on a monitor's durable device path rather than \.\DISPLAY1. That numbering lives in a registry hive with no file behind it, rebuilt from scratch on every boot and ordered by however the adapters happen to enumerate — so a record keyed on it could restore the wrong monitor after a reboot. Two identical monitors of the same model are also told apart correctly, which an EDID-based key would not manage.
• A display whose level cannot be read, or whose restore does not land, keeps its entry for the next launch instead of being forgotten.

Still unexercised outside automated checks, unchanged from v2.9.0: the colour settings (off by default), the HDR vibrance level, and apply-on-startup. The core path — vibrance on when a game takes focus, back to normal when it exits — has been watched working on real hardware across several Counter-Strike 2 sessions, on an x86 build.

These are fork builds and they are unsigned. If something regresses, naming the version and architecture from the title bar is the fastest way to find the change at fault.

Full comparison: v2.9.0...v2.10.0