Asus XG27AQDMG Discussion

[Shifroval]

What I want to ask now is how to better mitigate black crush in sdr? Right now I use novideo with rtings icc profile and can see only the second row in lagom test. To be precise, it's the second row minus the first square. Is it the best solution at the moment?

You can load the ICC profile in novideo_srgb and it in that mode, which also allows for gamma calibration adjustment. See the first post for instructions on where to get the profile and how to set up novideo_srgb.

Well, I did exactly this and got no results with the asus profile, but got acceptable results with rtings calibrated profile: I can see the two lower rows almost 100%. Before that I could only see the last 2 squares, maybe 3. Someone on reddit was also getting zero improvements and tried calibrating to edid primaries instead. For me that also changed nothing.
So I'm asking what result did you get after calibrating using asus provided profile. Also, do you use user mode? I switched to it immediately, but if you're using e.g racing, you may be getting different results.

[RealNC]

Well, I did exactly this and got no results with the asus profile, but got acceptable results with rtings calibrated profile: I can see the two lower rows almost 100%. Before that I could only see the last 2 squares, maybe 3. Someone on reddit was also getting zero improvements and tried calibrating to edid primaries instead. For me that also changed nothing.
So I'm asking what result did you get after calibrating using asus provided profile. Also, do you use user mode? I switched to it immediately, but if you're using e.g racing, you may be getting different results.

User mode. Racing mode has a dimmer red (look like lower luminance for red, not desaturation.) Other than that they look pretty much identical. I would say user mode seems to be the native output of the display.

In EDID mode with novideo_srgb, I can see all squares in the black level test at 120Hz. The first square is hard to tell, but it's still barely distinguishable. At 240Hz, square 5 becomes the first that I can distinguish. The lower the refresh rate gets, the lower the gamma gets as well (it's the cause of VRR flicker.)

It's important to not have an ICC profile in Windows when using novideo_srgb. Otherwise, you're getting double-clamped in browsers and image viewers (since they're color-managed applications) and possibly gamma adjustment applied twice. In the Color Management settings in Windows, make sure the list of profiles for the monitor ("profiles associated with this device") is empty.

Other than that, the relevant settings I'm using in the monitor OSD are:

Game Visual: User Mode
Shadow Boost: OFF
Brightness: 35 (desktop) / 45 (games)
Uniform Brightness: On
Contrast: 80
Display Color Space: Wide Gamut
Color Temp: User (100, 100, 100)
Saturation: 50
Six-axis Saturation: All 50
Gamma: 2.2 (sometimes 2.0, depending on content)
Screen Saver: off
Auto Logo Brightness: off

Note that if you can start distinguishing the 4th square in the black level test, that's a pretty good result already.

[Shifroval]

User mode. Racing mode has a dimmer red (look like lower luminance for red, not desaturation.) Other than that they look pretty much identical. I would say user mode seems to be the native output of the display.

In EDID mode with novideo_srgb, I can see all squares in the black level test at 120Hz. The first square is hard to tell, but it's still barely distinguishable. At 240Hz, square 5 becomes the first that I can distinguish. The lower the refresh rate gets, the lower the gamma gets as well (it's the cause of VRR flicker.)

Ah, yeah, I completely forgot about oled gamma changes. True, in 120hz mode I can see all squares without touching anything in color settings. Square 1 is more like a faint frame, but if I look at it for some time, it becomes a bit easier to distinguish. Moreover, I tried upping contrast to 80 (had it at 50), as it was default when I first turned on the monitor, and now I can easily see square 3 at 240hz, that is a huge improvement.
As I said, I'm using rtings calibrated profile and it was already mitigating most of the crush, but now it became a non-issue and I can just enjoy the monitor. Thank you for reminding me about gamma and about contrast setting.

Do I need to unclamp before switching to hdr? I saw somewhere that novideo can affect hdr mode, not sure if true, at least I don't see any difference.

[RealNC]

I tried upping contrast to 80 (had it at 50), as it was default when I first turned on the monitor, and now I can easily see square 3 at 240hz, that is a huge improvement.

80 is the default though, not 50.

Do I need to unclamp before switching to hdr? I saw somewhere that novideo can affect hdr mode, not sure if true, at least I don't see any difference.

It used to not be needed, but now I'm not sure anymore. The Nvidia driver is what does the clamp to begin with, and it might have changed to not automatically disable it. So I think it's best to manually disable it just to be sure.

[Shifroval]

I tried upping contrast to 80 (had it at 50), as it was default when I first turned on the monitor, and now I can easily see square 3 at 240hz, that is a huge improvement.

80 is the default though, not 50.

Do I need to unclamp before switching to hdr? I saw somewhere that novideo can affect hdr mode, not sure if true, at least I don't see any difference.

It used to not be needed, but now I'm not sure anymore. The Nvidia driver is what does the clamp to begin with, and it might have changed to not automatically disable it. So I think it's best to manually disable it just to be sure.

It was 80 by default for me too, I worded it poorly, I guess.

Ok, so far I found only one side effect of clamping. When it's enabled, all dsr/dldsr resolutions are deleted until I manually disable clamp and add them again. If I add them with clamp enabled, they're just not saved.
I was able to save them only after I tried applying clamp with nvcp open, then it stayed there no matter what I do.
Maybe related to some nvapi limitations or just a bug in novideo itself.

[RealNC]

Ok, so far I found only one side effect of clamping. When it's enabled, all dsr/dldsr resolutions are deleted until I manually disable clamp and add them again. If I add them with clamp enabled, they're just not saved.
I was able to save them only after I tried applying clamp with nvcp open, then it stayed there no matter what I do.
Maybe related to some nvapi limitations or just a bug in novideo itself.

Weird. Works fine for me.

[RealNC]

Do you happen to know what this brightness variability means when observing the stroboscopic effect? It only happens in the 180Hz mode, and only when g-sync is enabled. Every other mode is fine:



VRR does not need to be active for this problem to show up. As long as g-sync is enabled in NVCP, then this effect can be observed even on the desktop.

G-sync is broken in that mode. FPS/Hz mismatch judder appears and disappears every few seconds.

I don't use that mode at all (I use 240Hz for g-sync,) so it doesn't matter to me. But I still wonder how this got past Asus QA and what actually causes it.

[Chief Blur Buster]

Do you happen to know what this brightness variability means when observing the stroboscopic effect? It only happens in the 180Hz mode, and only when g-sync is enabled. Every other mode is fine:



VRR does not need to be active for this problem to show up. As long as g-sync is enabled in NVCP, then this effect can be observed even on the desktop.

G-sync is broken in that mode. FPS/Hz mismatch judder appears and disappears every few seconds.

I don't use that mode at all (I use 240Hz for g-sync,) so it doesn't matter to me. But I still wonder how this got past Asus QA and what actually causes it.

2nd and 5th cursor had twice as many refresh cycles (repeats) as the others.

First, check if your display or operating system is frameskipping:
www.testufo.com/frameskipping

Next, view the color-configurable version of:
beta.testufo.com/mousearrow

If you see the same behaviours there, then it's not your mouse. View the more configurable mousearrow (black background, white cursor) to see if it's doing the same thing. If it is, then it's not your mouse fault but something else (e.g. monitor behavior, operating system behavior)

____

NOTE:
Now, if TestUFO mousearrow looks normal unlike your cursor, then it's time to begin blaming the mouse.

This causes brightenings instead of gappings.

Usually caused by:
- Frameskipping behaviours in screen
- Mouse Hz versus display Hz
- USB timing jitter (try USB port roulette or PCIe USB card)
- Operating system jitter (mouse drivers not getting enoguh priority)
- Compositor jitter (Windows is repeating refresh cycles)

If you trace it to your mouse -- make sure your mouse Hz is at least 4-6x higher than your display Hz, to prevent this type of quirk (both gapping and repeats). I get this quirk with some of my mice, but not with my 8KHz mice (configured to 2Khz). A good 1KHz mouse shouldn't do this at 240Hz, modern 8KHz mice configured to 1Khz performs better than much older 1KHz mice too. In this case, there can be USB jitter, but it generally jitters too little to create this artifact. Brute oversample for the win!

[RealNC]

(I posted in the wrong thread. I now moved the posts to the XG27AQDMG thread.)

First, check if your display or operating system is frameskipping:
www.testufo.com/frameskipping

No frame skipping.

View the more configurable beta.testufo.com/mousearrow (black background, white cursor) to see if it's doing the same thing. If it is, then it's not your mouse fault but something else (e.g. monitor behavior, operating system behavior)

The effect is there on that test. 180FPS and 90FPS. The 45FPS cursor does not exhibit that issue.

Also, note that VRR does not work correctly in the 180Hz mode. There is no VRR flicker (there should be if VRR is working), and there's FPS/Hz mismatch judder which goes away when switching to 240/144/120/60.

Also, I get the exact same behavior in the 240Hz mode if I edit it with CRU and reduce VT or the pixel clock. I would guess Asus ships the monitor with 180Hz timings that are not compatible with g-sync? The problem completely disappears if I disable g-sync in NVCP.

[Chief Blur Buster]

No frame skipping.

You might see bright squares (frame duplicating).

The effect is there on that test. 180FPS and 90FPS. The 45FPS cursor does not exhibit that issue.

Ignore the 45fps cursor, focus on the 180fps. There's a bigger difference between [1/180 vs 2/180] than there is for [4/180 vs 5/180] for single refresh cycle duplication.

Also, I get the exact same behavior in the 240Hz mode if I edit it with CRU and reduce VT or the pixel clock. I would guess Asus ships the monitor with 180Hz timings that are not compatible with g-sync? The problem completely disappears if I disable g-sync in NVCP.

That's some quite interesting buggy behavior.
Perhaps I should relay this to ASUS themselves.
Have you tried upgrading to the latest firmware?