Skip to main content
This topic has been closed for replies.

1 reply

D Fosse
Community Expert
D FosseCommunity Expert
Community Expert
July 4, 2019

Huh. That sounds crazy. I've done everything I can think of to test on my Eizo CG2730, but don't see any abnormal banding.

No, I can't get 30 bits to work now, but that's nothing new. That's been on and off forever. So I do see the individual 0-255 steps. But nothing special beyond that. I'd still trust this monitor absolutely for any critical work.

It's also very curious that Eizo firmly place the blame on 1903, but without anything to support the claim. If this happens on a hardware calibrated unit that doesn't rely on calibration LUTs, and the profiles are healthy - the prime suspect would naturally be a buggy video driver, not the OS. I'm not saying it couldn't happen, it's just unlikely enough that other factors need to be ruled out first.

My private suspicion is that someone at Eizo finally discovered the ProPhoto banding bug in OpenGL code. As it happens, this tends to get worse with table-based monitor profiles, which ColorNavigator makes at default settings. Switch to matrix, and most of it is gone. Switch to Adobe RGB instead of ProPhoto, and the issue vanishes completely.

(BTW, the gHacks piece seems to mix up two unrelated issues. Failure to load the calibration LUTs has nothing to do with banding, and it's not what Eizo is concerned about. They wouldn't be, it doesn't apply on Eizo ColorEdges).

    Y
    Yume-chan
    Participating Frequently
    July 24, 2019

    ColorNavigator profiles, like other ICC profiles generated by other HW calibration solutions after calibration, stores a linear calibration (no calibration) in profile's VCGT tag in order to clean any existing graphics card calibration.
    It's like other ICC profiles generated by GPU calibration suites like DIsplayCAL, but with a linear calibration.

    There is a bug in Windows 10 1903 that once you reload into GPU a calibration (load ICC profile VCGT tag contents into GPU LUTs) it shows this distinctive banding  with borad bands or steps.
    Suggested workarrounds include disable MS loader for GPU LUT on startup: if you assign an old ICC profile generated with ColorNavigator nd reboot/lonoff-logon there is no banding issue. It you change default display profile at OS level while in a Windows session it is going to reload whatever VCGT content it has to GPU LUTs... and suffer this kind of banding related to 1903.

    As some user reports with no GPU drivers (no vendor specific drivers) there is no bug because there is no access to GPU LUT.

    This bug is everywhere: AMD GPUs, nvidia GPUs, Dells, Eizos, HW cal, software CAL... try to load VCGT contents of a profile in GPU LUT result in banding unless you reboot or logout&login.
    Miscrosoft broke something related to GPU LUT loading.

    This bug also applies to traditional GPU calibration like DisplayCAL with GPUs that produce no banding in this setup (like AMD radeons with their 10+bit LUTs + dithering at output, among others). BUT, and this is important, if you do the workarround trick and disable scheduled task WindowsColorSystem on computer boot VCGT calibration contents of a ICC profile are loaded properly into GPU LUT, with no banding (DisplayCAL LUT loader des the job). But if you change display profile (so you load another calibration, even if it is linar) the bug is back. Hence when user changes default display profile in OS (control panel / color management) there is something triggered that acts like this scheduled task. If we or MS find a way to disable it we can make our calibration work as intended.

      Y
      Yume-chan
      Participating Frequently
      July 25, 2019

      With all respects I think that you are mixing unrelated things, or maybe I didn't understand your words properly.

      OpenGL 10bit surface drawing and table/XYZLUT/LUT profiles issues are unrelated to this thread. 1st one is related to apps that support 10bit and we have thiss issue even on MS Paint. 2nd one is related to color management & display measured behavoir captured in an ICM profile and we have thiss issue even on MS Paint which does not color manage at all.

      The issue is caused when Windows (or other applications through its API) calls for an operation that loads "something" into graphic card 3 x 1D LUT calibration tables. "Something" could be common GPU calibration for monitors without HW calibration (i1Profiler, DisplayCAL)... or can be just linear table with output=input, like in profiles generated with vendor software or 3rd party for monitors with HW calibration (ColorNavigator from Eizo or equivalent apps from other vendors like Dell, Benq...)

      It is not related AT ALL with banding caused by 8bit gradients or GPU calibration issues or some color management rounding errors.

      The issue is "broad" alternating dark bands in gradients even in non color managed applications like MS Paint. MS Paint sends raw RGB colors to screen without color management or colorspace transformations.

      Abnormal Display Issue on Microsoft Windows 10 May 2019 Update (1903) | EIZO

      Like this image:

      https://www.eizoglobal.com/support/compatibility/software/problem_windows10_may_2019_update/not_displayed_correctry.jpg

      The other kind of "banding" caused by GPU calibration that you name have a very distinct visual pattern that do not match this issue when you inspect a gradient in a non color managed enviroment: from tiny vertical lines to green-magenta color bands. Also NOT ALL graphics cards cause this kind of banding when you do a GPU calibration (Radeons & DisplayCAL for example). Same for banding caused by color management rounding errors, the pattern is different and it is limited to those color managed applications.

      Also "W10 1903" issue happens in monitors with HW calibration like Eizos & Dells and their ICM profiles obtained with HW calibration packages do store linear LUT for GPU... so there cannot be banding asociated to GPU calibration because ther is no calibration other that linear values in GPU LUT.

      Most people do not have a display profile asociated to their screens in Windows OS, or if they have one, it's very common that it's driver ICM profile and may not have VCGT tables, hence they do not suffer it.

      This issue hapens when Windows calls to a "load calibration" operation in GPU when user log in Windows, user has a displayprofile attached to his screen and that display profile has VCGT calibration for graphics card (even if it is a "no calibration" like in HW calibration generated profiles). At least 3 conditions are required...why? because this issues is related to GPU 1D-LUT calibration loading.

      The suggested workarround is to prevent that "trigger" to happen: disable WindowsColorSystem scheduled task & triggers and reboot.

      This way, with this trick, if you attach a profile (HW cal or GPU cal) after you did the trick and reboot there is no bug, even you loaded a GPU calibration with DisplayCAL calibration loader. Windows does not call "whatever it calls" on user logon. Next time you power on your computer it will be OK, Windows do not call this scheduled task with whatever broken API it has.

      BUT even if you did this trick, if you change default display profile in OS settings while in your Windows session, even if you have a 3rd party GPU calibration loader like DisplayCAL, Windows calls "whatever is broken" and you get those bands again unless you reboot, or unless logoff and login.

      -----

      c.pfaffenbichler  , I'm not affiliated with Eizo.


      Sorry I'm seeing some typos in my text, I wrote it very fast because explanation was very long. I hope you do not mind. Thanks in advance.

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices