Inconsistent Flicker-free Dimming Behavior

[Velgus]

Rules

• I made myself familiar with the Readme, FAQ and Troubleshooting.
• I understand that, if insufficient information or no app logs will be provided, my issue will be closed without an answer.

What's wrong?

Visual Modes seem to have inconsistent application combined with Flicker-free Dimming. For example, if switching from one mode to another with Flicker-free Dimming at 50%, it will be substantially brighter, but then if you click 50% in Flicker-free dimming, it will be appropriately dimmed.

This also happens when opening the Windows "System > Display" settings menu.

This doesn't seem to apply to all modes, but I found one where I could reproduce it consistently (see "How to reproduce the bug").

How to reproduce the bug?

1. Set Flicker-free Dimming to 50% on "Gamut: Native".
2. Switch to "Gamut: DCIP3" - notice that it seems overly bright for 50%.
3. Click 50% in Flicker-free Dimming again (exactly where the slider is) - notice it gets dark again.
4. Switch back to "Gamut: Native" - notice that this switch seems to be appropriately dark, and doesn't change if you click 50% in Flicker-free Dimming.

Logs

log.txt

Device and Model

Asus Zephyrus G14 GA403

Additional information.

I looked for the "Automatically manage color for apps" setting, in case it was interfering, but that setting doesn't exist on my model.

Note that the incorrect/brighter colors upon switching modes are not the same as a higher Flicker-free Dimming setting. For example, if I made the bug take effect at 50%, then set the Flicker-free Dimming slider to 100%, it would be a very different color.

It seems like maybe the Flicker-free Dimming is based off the "Gamut: Native" mode, but if that's the case, maybe it should automatically re-select that Visual Mode when changing Flicker-free Dimming, to avoid confusion.

As an aside, the bottom 20% of the Flicker-free Dimming slider have no affect whatsoever on my model (no changes between 20% and 0%).

Armoury Crate

Uninstalled

Asus Services

None

Version

0.170

OS

Windows 11 23H2

[seerge]

@Velgus hello, G-Helper just runs AsusSplendid.exe with appropriate params to set both dimming and gamuts, same as AC does.

How does this work if you would repeat same steps using AC ?

AsusSplendid.exe 200 0 [50] <- native gamut (200 is command for gamut)
AsusSplendid.exe 200 0 [53] <- dcip3 gamut
AsusSplendid.exe 19 0 [61] <- dimming level (19 is command for dimming)

[seerge]

@Velgus hello, any updates here? Did you try same thing in AC ?

[Velgus]

Sorry, I'll get back to you soon.

[Velgus]

Okay, so after testing, the main issue is more to do with the settings UI being confusing, than a bug with switching the flicker-free dimming. The issue exists in AC as well, but if you want, you could make a slight adjustment to make it a bit clearer for G-Helper users.

Basically, flicker-free dimming only works with with "Gamut: Native" mode. If you are in any other mode, adjusting flicker-free dimming switches to "Gamut: Native" mode and adjusts the dimming. However, the UI doesn't update (in G-Helper or AC), so it will still say it is in another mode (eg. "Gamut: DCIP3" or whatever), even though it is not actually using that mode.

It could be clarified by simply automatically switching to the "Gamut: Native" mode in the drop-down when you change flicker-free dimming. Honestly, the clearest solution may be just hiding the Flicker-free Dimming slider entirely when in non-"Gamut: Native" modes, as this also makes it clear that it's not being dimmed when in said modes.

Two other tangentially related issues:

1. Entering the Windows Display settings exhibits weird behavior as mentioned before. As far as I can tell what seems to happen is, if you are in "Gamut: Native" mode, it switches you to the last non-"Gamut: Native" mode you were in (though again, no UI update in G-Helper or AC).
2. Flicker-free Dimming is not applied on Startup. It should either be applied, or the slider should be set to 100% on Startup so it's clearer that it's not currently active.

[seerge]

@Velgus hello, thanks for checking

Basically, flicker-free dimming only works with with "Gamut: Native" mode. If you are in any other mode, adjusting flicker-free dimming switches to "Gamut: Native" mode and adjusts the dimming.

That's an interesting find. I don't have G14 2024 anymore to double check tho

It could be clarified by simply automatically switching to the "Gamut: Native" mode in the drop-down when you change flicker-free dimming.

I think this can be an option. I'm not a fan of hiding dimming from the UI. As it's also accessible via hotkeys. It's easier to update Gamut dropdown.

But I would like to double check if it indeed resets gamut to default (de-facto) from someone else with same device

[Velgus]

I'm not a fan of hiding dimming from the UI. As it's also accessible via hotkeys.

Do you know which hotkeys it's supposed to be? The FN+F7/F8 adjusts the regular display brightness, not Flicker-free Dimming.

[seerge]

@Velgus Ctrl + FN + F7/F8

[Velgus]

Ah, found it, thanks. It's Ctrl, not Shift though. Shift + FN + F7/F8 is Slash Lighting Brightness.

[seerge]

@Velgus right :) sorry. I have also added this to the readme.

[lgarlati]

G16 2024 here, and yeah. but I don't know if it's a bug or just the calibration affecting brightness.
Native = DisplayP3 = sRGB > DCIP3

Basically, flicker-free dimming only works with with "Gamut: Native" mode. If you are in any other mode, adjusting flicker-free dimming switches to "Gamut: Native" mode and adjusts the dimming.

I don't know if this is true. I've been using DisplayP3 for as long as I can remember, and the flicker free dimming has worked just fine. I can also guarantee it's not switching to native, as switching between DisplayP3 and Native while at 50% does yield a noticeable difference.

[seerge]

@lgarlati ok, so dimming does not reset (actual) gamut on your device ?

[lgarlati]

@seerge This is even weirder than I thought.

I ran the following test with each other three color modes, but DCIP3 was the most obvious:
Set to any mode other than native, dim 10% via hotkey, brighten 10% via hotkey, switch to native to see difference.

Some notes at each step:

• At 100% brightness, all the gamut modes work as expected.
• upon dimming, the gamut visually changes, a lot. This new gamut resembles native.
• upon brightening, there is no gamut change compared to dimmer, just a brighter screen.
• Upon switching back to native, there IS a change, albeit slight. This is most obvious from DCIP3, but present from the others as well.
• Lastly, once back at 100% switching between modes works again as intended.

Not sure what to make of this, but it seems that dimming is messing with the gamuts themselves.

[seerge]

@Velgus @lgarlati great, thanks for explanation of your observations :)

Dimming is definitely "messing" with gamuts. And it is supposed to be so.

What dimming effectively does - it compresses dynamic range of the actual image, by just reducing it's brightness.
It's pretty much if you would take a screenshot and then adjust it's brightness in photoshop to make darker.

Given that it seem to return back to original state when you return brightness, I think it doesn't make sense to change anything in app UI. And just keep currently selected gamut as it was before (also to be consistent with how AC shows this)

[lgarlati]

@seerge

Given that it seem to return back to original state when you return brightness, I think it doesn't make sense to change anything in app UI.

I must have made my previous post unclear. It does NOT recover once you return to 100%. It remains as a weird near-native gamut. You need to manually reselect the desired gamut for it to take effect.

[seerge]

@Velgus @lgarlati

Ok, then I can reset Gamut dropdown to default value every time you adjust dimming

Try this build
GHelper.zip

[lgarlati]

@seerge

Ok, then I can reset Gamut dropdown to default value every time you adjust dimming

Can confirm that it does reset, only problem is it resets to native, not the previous choice. Also, I think resetting every time the dimming is changed it unnecessary and adds even more latency while sliding the slider. May be better to make it reset whenever the dimming returns to 100% (not dimmed)

[seerge]

@lgarlati

Can confirm that it does reset, only problem is it resets to native, not the previous choice.

It resets UI to Native intentionally. Cause as I have understood you both correctly - any Dimming levels reset gamut back to Native (and don't recover after) ? Change is purely cosmetic. I can't change actual dimming behavior anyhow.

Also, I think resetting every time the dimming is changed it unnecessary and adds even more latency while sliding the slider. May be better to make it reset whenever the dimming returns to 100% (not dimmed)

It resets dropdown only when it's not native currently. So it should happen only once :)

[lgarlati]

@seerge

any Dimming levels reset gamut back to Native (and don't recover after) ?

Sorry I wasn't clearer. Once dimmed, the gamuts change and resemble native. But they are NOT the same and native. There is a distinct difference, between the "new" gamut and native. Effectively, an entirely new set of gamuts.

[seerge]

@lgarlati the only thing i can change in the app - is either reset UI or keep it as it is now w/o any changes.

Rest is outside if app control :)

From what I understand AC doesn't bother with that at all.

[lgarlati]

@seerge Understood. I just meant keep what you added in the zip above, just set it to the last gamut instead of native.

Otherwise keeping it as is in the zip above is fine in my opinion.

[seerge]

@lgarlati

I just meant keep what you added in the zip above, just set it to the last gamut instead of native.

But that would be a behavior of current (regular) release. I.e. no changes at all ?

[lgarlati]

But that would be a behavior of current (regular) release. I.e. no changes at all ?

Yes, but reapplying the same gamut once back to 100% fixes the issue.

If you can point me to where in the codebase this is implemented, I can try playing around with it to see what works.

[seerge]

@lgarlati yeah, but whole discussion here is only about adjusting UI to reflect actual state of the things with dimming / gamuts under the hood (they are controlled by Asus Utility not by G-Helper).

So if adjusting Dimming does not reset custom gamuts (like DCI-P3 or so) to Native. I think it's better to keep old gamut selected in UI.

I just thought that Dimming always resets any Gamut to Native (which is not the case).

So the changes i did in the build here are probably not needed.

Anyway, this is where everything is handled in a code
https://github.com/seerge/g-helper/blob/main/app/Display/VisualControl.cs

Dimming

g-helper/app/Display/VisualControl.cs

Line 272 in a7d5b38

private static void BrightnessTimerTimer_Elapsed(object? sender, System.Timers.ElapsedEventArgs e)

Gamut

g-helper/app/Display/VisualControl.cs

Line 172 in a7d5b38

public static void SetGamut(int mode = -1)

[lgarlati]

@seerge

I'll take a look after work and see what I can do. I'll report back either tonight or tomorrow.

[lgarlati]

@seerge

First, it turns out that my previous assumption that there was a "second set" of gamuts while dimmed is false. By reapplying a gamut, dimmed or otherwise, the correct gamut is shown, dimmed. As such, I found a janky fix. Simply calling Setgamut again after a delay fixes the problem. While my delayed reapply works, the true cause I'm unsure of. I suspect somewhere in the brightness setting pipeline another erroneous call is made to set gamut which is resetting away from user preference. However, changing SetGamut to use the AppConfig setting as default doesn't fix the issue.

Here is the changes I made. First adding this function:

        private static void SetGamutDelayed(int mode, int delay)
        {
            static void GamutDelayElapsed(object? sender, System.Timers.ElapsedEventArgs e, int mode)
            {
                Logger.WriteLine("Gamut Delay Timer Elapsed, setting gamut to "+mode);
                GamutDelayTimer.Stop();
                GamutDelayTimer.Dispose();
                GamutDelayTimer = default!;
                SetGamut(mode);
            }
            if (GamutDelayTimer is null)
            {
                Logger.WriteLine("Delayed Gamut set to"+mode+" with delay "+delay+"ms");
                GamutDelayTimer = new System.Timers.Timer(delay);
                GamutDelayTimer.Elapsed += (sender, e) => GamutDelayElapsed(sender, e, mode);
                GamutDelayTimer.AutoReset = false;
                GamutDelayTimer.Start();
            }
            else
            {
                Logger.WriteLine("Gamut Delay Timer already running");
            }
        }

with a corresponding timer at the top. Then adding a callback to it on the last line of SetBrightness

SetGamutDelayed(AppConfig.Get("gamut", -1), 1000);

I used a delay of 1 second as it shows the switch back fixing the issue, but a smaller value, say 500, likely also works.