Open Velgus opened 4 months ago
@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)
@Velgus hello, any updates here? Did you try same thing in AC ?
Sorry, I'll get back to you soon.
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:
@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
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.
@Velgus Ctrl + FN + F7/F8
Ah, found it, thanks. It's Ctrl, not Shift though. Shift + FN + F7/F8 is Slash Lighting Brightness.
@Velgus right :) sorry. I have also added this to the readme.
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.
@lgarlati ok, so dimming does not reset (actual) gamut on your device ?
@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:
Not sure what to make of this, but it seems that dimming is messing with the gamuts themselves.
@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)
@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.
@Velgus @lgarlati
Ok, then I can reset Gamut dropdown to default value every time you adjust dimming
Try this build GHelper.zip
@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)
@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 :)
@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.
@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.
@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.
@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 ?
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.
@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
@seerge
I'll take a look after work and see what I can do. I'll report back either tonight or tomorrow.
@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.
@lgarlati ok, i see.
How does it work when you do dimming in AC ? (i was asking @Velgus here already) But I wonder if it even tries to handle this ?
Sorry, I lost track of this thread (for some reason I wasn't getting notified by mentions and such), but Igarlati's observations are likely more accurate than my own.
I just thought that Dimming always resets any Gamut to Native (which is not the case).
I originally thought that, but I actually could have been wrong. It's what it looked like visually to me, but Igarlati's findings seem more valid.
That said, when I tested with AC it exhibited the exact same behaviors that G-Helper currently does. So basically AC "doesn't" handle the issue as far as I could tell, and any handling added here would be an improvement over the way AC works.
@Velgus you can check build i posted above. It resets UI (i.e. gamma dropdown) to Native every time you change Dimming. But obviously it does not change actual behavior.
The custom build still exhibits the same strange behavior that Igarlati and I both experienced. While it switches back to Native, it still has a weird unknown Gamut setting, and it only corrects when you click a value in the slider again (even the same value).
As such, yeah, I think my initial observation about it defaulting to Native was incorrect and Igarlati's solution would be better.
While my solution definitely works it also is very, very janky and not robust.
The correct solution would be to find wherever the code that's incorrectly resetting the gamut is, and place the correct setting code right after it. However, that sounds like a lot of work.
As for what delay to use, I'd say somewhere between 500 and 1000ms.
@lgarlati
The correct solution would be to find wherever the code that's incorrectly resetting the gamut is, and place the correct setting code right after it. However, that sounds like a lot of work.
There is no access to the "code" responsible for that, cause as you see it's just AsusSplendid.exe that does it inside :)
Honestly looking at all this, I'm not a big fan of manually calling AsusSplendid and setting gamut every single time Dimming is changed. Especially considering that AC doesn't do that neither.
@seerge
I'm not a big fan of manually calling AsusSplendid and setting gamut every single time Dimming is changed. Especially considering that AC doesn't do that neither.
I personally lean in favor of having a delayed re-application of the gamut. It's really annoying to have to switch it back twice every day when I use dimming at night. But, I would make it opt-in via "extra" menu, and would make the 1 second timer reset every time the brightness is adjusted so it doesn't get reset multiple times ie
if(timer already running){
timer.stop()
timer.start()
}
instead of the
else
{
Logger.WriteLine("Gamut Delay Timer already running");
}
Regardless of what you decide, I'm definitely keeping those few lines of code in my version of the app XD
Rules
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?
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