Open jxlarrea opened 1 year ago
Has there been any update on this? This application is kind of vital for my work and if Nvidia drivers borked it it's sort of a major issue
This error seem to pop up if Windows goes into HDR mode. When back in SDR mode the clamping seems to work again, at least for my Acer XV272U. I'm using Game Ready Driver 536.23 with RTX 3080.
This error seem to pop up if Windows goes into HDR mode. When back in SDR mode the clamping seems to work again, at least for my Acer XV272U. I'm using Game Ready Driver 536.23 with RTX 3080.
Yeah same here.
Is this fixable?
I would be nice with an option for error messages to be silent
I have created a build on my fork to suppress this error: https://github.com/weili-jiang/novideo_srgb/releases/tag/suppress-disable-error
I have created a build on my fork to suppress this error: https://github.com/weili-jiang/novideo_srgb/releases/tag/suppress-disable-error
Seems to be working, thanks buddy! 😃👌
@weili-jiang Thank you for creating the fork and getting rid of the error. I'm having an issue with your version though. If the clamp is active, when I enable HDR the colors are very washed out. If the clamp is disabled, the HDR colors are normal.
I have to manually disable the clamp every time before I enable HDR
I don't think it's fixable - the API no longer works when HDR is enabled (hence the error message). The whole API is unofficial anyway so I doubt we can expect NVIDIA support on it.
I'm curious why it seems to work for some people though. What OS / monitor combinations have washed out colors and what ones don't?
@weili-jiang I've tested this on AW3423DW, and it seems to affect both, the original and the fork. Before 531.79, when the clamp is enabled and I activate HDR, the clamp gets automatically disabled and the HDR colors are accurate.
After 531.79 I have to disable the clamp manually, otherwise the colors are washed out in HDR. Is it possible that the clamp remains applied even in HDR?
Is it possible that the clamp remains applied even in HDR?
@antonp92 that's exactly what's going on. The newer drivers no longer have the API function to remove the clamp in HDR mode. The fork from the guy above is useless as the only thing it does is suppress an error message box.
I never said my fork fixes the real issue. I don't experience the washed out colors on my set up so suppressing the error is fine by me. The API to disable clamp now fails while in HDR so this cannot be truly fixed.
I never said my fork fixes the real issue. I don't experience the washed out colors on my set up so suppressing the error is fine by me. The API to disable clamp now fails while in HDR so this cannot be truly fixed.
I am not 100% certain but I believe that the washed out colors happens when there is an ICC profile added to the clamp. Hope someone else can confirm if they are also seeing this behavior.
@jxlarrea I do not have an ICC profile added to the clamp.
I have a calibrated sRGB ICC profile (made using DisplayCAL and Spyder) applied to my clamp. Maybe my setup is unusual - if I have the clamp enabled and simply turn on Windows HDR, with my monitor in SDR mode, it does indeed look awful:
Clamp enabled, Windows HDR, monitor SDR
If I switch my monitor to HDR mode, it looks better:
Clamp enabled, Windows HDR, monitor HDR
For comparison, here's clamped SDR with a calibrated ICC profile:
Clamp enabled, Windows SDR, monitor SDR
Okay I see the difference now, if both my monitor and Windows are in HDR mode and I have clamp on versus off, there is a difference in saturation. Not super obvious until I compared side by side.
How difficult would it be to implement a hotkey feature to disable the clamp. If we bind it to Win + Alt + B the clamp will disable at the same time we enable HDR.
How difficult would it be to implement a hotkey feature to disable the clamp. If we bind it to Win + Alt + B the clamp will disable at the same time we enable HDR.
I don't think that would work well as it would be a race condition as to which happens first, it will randomly fail.
I can see it working as an integration with AutoActions, however. I already use AutoActions to automatically put Windows and my monitor into HDR mode when launching Cyberpunk 2077 (since that game doesn't trigger HDR mode - you have to put Windows in HDR mode first).
Using AutoActions, it would be possible to sequence it to ensure that the clamp is disabled before HDR is enabled, and vice-versa. You would just have to explicitly whitelist any applications you want to enable HDR and add it to the action profile.
There would be some work to allow running novideo_srgb as a command line one-shot to set clamp, and have the two instances (the one-shot, and the persistent daemon) synchronize with each other correctly.
@ledoge sorry for the direct ping, is there anything in the works resolve this? I would be eternally grateful :)
Not currently interested in working on this, sorry. IMO the fact that the API cannot be used in HDR while the GPU still uses the values set in SDR is a driver bug that should be fixed by NVIDIA.
Weird, I never had this issue until I installed drivers 537.34.......
So just to confirm, if I manually UNCLAMP the gamut and THEN switch Windows into HDR mode, everything is fine?
Not currently interested in working on this, sorry. IMO the fact that the API cannot be used in HDR while the GPU still uses the values set in SDR is a driver bug that should be fixed by NVIDIA.
Are you sure there is nothing you can do to see if you can fix it on your side? This tool you made is seriously one of the most useful and best-working tools for gamut clamping. It would be a shame to lose functionality. Having to manually uncheck the clamp box every time you want to turn on HDR is a major pain in the ass. Can you please look into it? If you don't mind?
Not currently interested in working on this, sorry. IMO the fact that the API cannot be used in HDR while the GPU still uses the values set in SDR is a driver bug that should be fixed by NVIDIA.
Following up on my last comment thank you!
Reading the 4.1 changes, does it relate to this issue?
Reading the 4.1 changes, does it relate to this issue?
That change is just for easier adjustment of dither settings when you don't have an active color space conversion in the first place. I.e. if you have the clamp disabled in SDR, and then switch to HDR, you'd get this error message sometimes despite there not being anything to disable in the first place. Still can't do anything about the case where you have a color space conversion active in SDR and then switch to HDR, unfortunately :/
No worries, I know you don't have a way of solve this , I just hoped Christmas came early. Maybe someday Nvidia will make some adjustments so this can be worth using, but for now it's easier to push the buttons on the monitor to switch back and forth to the sRGB mode.
Since NVIDIA doesn't care, here's a makeshift solution for anyone still annoyed by this.
I wrote a small AutoHotKey script that allows automatically toggling both the Novideo sRGB clamp and HDR by simply pressing Ctrl + Win + H.
To use it:
⚠️ Important:
Code for the script:
Rolling back to previous drivers fixes the issue.