Windows 10 version 1903: banding on gradients issue

[Guest]

Just a FYI, can't say I've noticed any issues

Windows 10 version 1903: banding on gradients issue - gHacks Tech News

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

[D Fosse]

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).

[Yume-chan]

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.

[stevemyers]

Yes totally agree with you there is bug in windows 10.

[D Fosse]

I'm on a trip now with just a laptop, so I can't test anything now. But as I said I was unable to produce anything other than the normal 0-255 steps. So unequivocally stating that "there is a bug" may be jumping to the guns too fast. There may be something that hits some people under some circumstances, but it's not universal.

Colornavigator's default LUT profiles is a real problem, however, especially in combination with ProPhoto data. And clearly there is a bug somewhere that prevents 30 bits from working.

Banding is a very common complaint here, caused by a standard 8 bit display pipeline, and often an irregular calibration curve to correct for inferior display panels. A defective monitor profile can exaggerate it. And of course working in 8 bit depth will cause banding on its own, as well as jpeg compression artifacts.

Put all these together, and you often get very ugly and irregular banding, often with colored bands. I'm sure a lot of people with these problems will jump on this thread and say "it's the Windows bug".

Can anyone share a screenshot that actually shows this banding caused by a Windows bug?

[Yume-chan]

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_disp...

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.

[Yume-chan]

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.

[D Fosse]

I know it's not related to 10 bit display. What I'd like to know is - what does it look like?

[Yume-chan]

I wrote it, just like that:

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

It happens in MS Edge, MS Paint...they are sending raw RGB contents from image to screen and they get corrupted with those dark vertical stripes somehow when a LUT loading event happens with "some call to some operation in Windows" API.
It this call does not happen... you get smooth gradients if they were smooth before 1903 (8bit smooth gradient + MS paint): HW cal, GPU cal with Radeons & displaycal... etc

-We can avoid "that thing" to be called on user login (disable scheduled task WindowsColorSystem), this is the trick/workarround.
-We do not know (as users) how to prevent this call to happen when you switch default display profile for a screen (directly in control panel or through a 3rd party app like DisplayCAL). I would like to know if there is a way to skip this other that logoff and login again.

That's all we know until MS fixes this.

[D Fosse]

Sorry if I'm nagging, but what exactly do these "dark vertical stripes" look like? Does anyone have a screenshot? What is it that people are supposed to look for?

Yume-chan  wrote

That's all we know until MS fixes this.

And, if you're not representing Eizo, who are "we"? Who are you representing?

[Yume-chan]

Do you see this link? It looks like that:

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

Maybe forum antispam measures prevent this link to be shown.

"We" = users that have profiles with VCGT tags. If the 3 conditions I've explained are met, bug happens.

[Trevor.Dennis]

Dag, all I can see is the example images on the Eizo page

The link in post #11 appears to be broken.  Breaking the link down, I can get as far as

Compatibility | EIZO CORPORATION

Using the single word 'Windows' as a search parameter from that page brings up the following. all of which are too old to be related.

Sorry, this is just a screen shot.  Folk will need to go to the Compatibility page and search for themselves to get the live links.

[D Fosse]

Well, if that Eizo site example is representative, I have certainly never seen anything like that. If that happens in some circumstances, it's certainly not universal.

I'll be back at my workstation in a couple of days, so I'll have a closer look then.

Note that 1903 does seem to require a video driver update. No idea if it's related, just rule that out first.

[Yume-chan]

Updated to latest radeon drivers. It is still there if I change default profile for my display and reload its VCGT tag contents into GPU.

MS broke something and it is not new.

About 3-4 mayor W10 updates ago if display goes to standby, when it awakens MS is limiting/truncating LUT calibration correction to 8bit, even if GPU and its driver allows 10 or 12bit data in LUTs (if GPU has dithered outputs gradients are smooth as in a HW calibration). A truncated LUT in GPU to 8bit in a linear lut is still linear, so people with HW cal did not noticed it.

Also MS own LUT loader (& third party like Basiccolor or XRgamma) truncates to 8bit VCGT contents since I cannot remember when, so people with GPU calibration needed a 3rd party loader to get smooth bandless non color managed gradients. The same as above, linear calibration truncated to 8bit is still linear so Eizo CG owners never noticed it, others did.

The "funny" part is that MS never broke a linear LUT calibration before this 1903 issue... so now all monitor owners which use profiles with VCGT tags that get loaded into GPU suffer the issue. All of them, even those who paid a high end monitor with HW cal that generates ICM profiles with VCGT tags.
So this is a SEVERE issue.

[D Fosse]

Yume-chan  wrote

all monitor owners which use profiles with VCGT tags that get loaded into GPU suffer the issue. All of them, even those who paid a high end monitor with HW cal that generates ICM profiles with VCGT tags.

You keep saying that, but it's still unsubstantiated. I have a CG2730 and I don't see it.

I can't check it now, but it's also new to me that Colornavigator loads a linear VCGT tag. What I do know is that there's an optional warning in Colornavigator for any changes in calibration LUTs (in other words, if some software tries to load one). That would be moot if there was an automatic loading of a linear table.

[Yume-chan]

Take a look on your current default display profile, check status of troublesome scheduled task, check that your GPU is able to load contents to its LUT... and we can talk about that.

Having a CG2730 means nothing, that why I wrote the chain of events that leads to this issue almost every time I named the issue. Without data your claim "it does not happen" does not hold.

Regarding your complain, HW cal solutions that generate ICM profiles should write a linear VCGT tag in them ... otherwise any existing GPU LUT modifications will broke the matching between profile and current display behavior. It's a failsafe, a good one untill MS broke it in 1903.

A "clean LUT contents" order in ColorNavigator tray will only work as long as this app is active. Linear VCGT tag ensures that monitor & display profile match whatever software you use. As I said, a failsafe.

[D Fosse]

Having a CG2730 means nothing

I never said it did, but you're the one pointing to Eizo's website as the only verification.

Without data your claim "it does not happen" does not hold.

Right. So I do have a problem, I just don't realize it? I do have this banding, I just don't see it? 

otherwise any existing GPU LUT modifications will broke the matching between profile and current display behavior

I haven't had a GPU LUT on any system for probably ten years, and certainly never on this one. I suspect that's true for most Eizo (or NEC Spectraview) users. So that point is moot.

This is a strange discussion indeed. "Rabbits have stripes." "No they don't, I have one and it's not striped". "Yes it is, and here's why".

I'll just leave this for now. When I get back to my workstation in a couple of days, I'll take a closer look. I promise. In the meantime, let's take a poll:

Does anyone else see these dark vertical stripes? Remember, you all qualify. This is supposed to happen everywhere.

[Yume-chan]

a) I have not said that. The error has been tracked in almost every respectable calibration forum, not only by Eizo. I've mentioned DisplayCAL several times and the efforts of ist developer & community to find the trigger conditions that causes MS WINDOWS 10 r1903 (who is the culprit) to cause that banding.

b) Again...you say no truth, I've not said that. I've put a list of conditions that trigger a well know bug (by several respectable sources). AFAIK you did not check if that set of conditions apply to you, hence you cannot say if you suffer it or not. I said: check your current display profile (contents, VCGT tag, program that genertaed it... you may be running default vendor profile), check status of scheduler task (maybe it is disabled), check if your GPU is able to load contents to LUT (there was an error after 1903 that prevented LUT loading, now corrected AFAIK, conditions described in DisplayCAL forum). Once you have checked this we can talk about if this happens to you or if I'm talking about a "ghost bug" that a lot of people are suffering.

Until you do that... you have no data.

c) You HAVE a GPU LUT. If you did not know how things work it's your problem. You have it ("them", actually, one per output) because you own a computer with a intel iGPU, AMD (common or pro), nvidia (common or pro) or maybe one of these now uncommon Matrox and these cards have GPU LUTs... unless you plug your CG2730 into a Raspberry Pi or one of those SoC that gives user/OS no acces to GPU. So first of all I would suggest to to learn this basics before blaimg people who is explaing the trigger conditions of a (well known & severe) issue in W10 1903.
Second, most HW calibration solutions (including those of "lesser" bands like Dell or Benq in their HW cal solutions), write linear VCGT data into their profiles. This data is meant to be loaded into GPU LUT. With linear data I mean output is equal to input, which means "no GPU calibration". This is done to ensure that current output used for that screen is not modified by a previous profile (that can or cannot be produced by HW cal).

People reding this may check it by themselves: ICC profile inspector, DisplayCAL-profile-info.exe and other tools. My list is a small example.

[D Fosse]

Right. I'm back at my workstation, and...it's true. There is banding.

What can I say? I humbly bow down and eat up every word I said.

[D Fosse]

When this first came up, I looked for traditional banding, i.e. irregular representation of 0-255, which I didn't find (and still don't). But that's not what this is. What it is, I just can't make any sense of.

Yume-chan, my apologies (that's my second in just one week ). You were right, and I was wrong. In all fairness, I couldn't check this until today. But why couldn't you just have posted a screenshot right away? Then I would immediately have seen that something else was up.

How, exactly, do you "disable WindowsColorSystem scheduled task"? Is it this one?

[Yume-chan]

I put a link to Eizo "official" JPG showing the issue several times, but as other users have said they see the link as broken. IDNK why.

Also please check the most disturbing part of this bug:

-If you disbale te trigger conditions of WindowsColosSystem scheduler task and reboot, al looks fine. No banding. That's fine, our old Windows behavior.

-But if you change display default profile to something else (even with linear LUT in VCGT), banding is back unless you logout & login
We can live with patches like disabling that scheduled task... but be forced to log out and log in every time you change display profile... this is a big drawback.
It is not the same as we do with Adobe suite right now (if you cange display profile you need to close that app and start it again to notice it), since we are now forced to close all our apps, like documents, text editors, and even a lot of tabs in our browsers just for a 5 minute check how things look in other colorspace in a browser (for web designers for example)

Another example would be that Multiprofiler tool from NEC is "broken" for its common & intented use (extremely fast colorspace emulations bases on some factory native display behavior profiling data stored in firmware, like emulating other displays, changing between several of them for fast appraisal of some work) because AFAIK it builds on the fly a profile and assign it to display, so... we have our bug again.

In practice we are limited now to use 1 "display profile"-"calibration" per Windows session. A lot of people do not need more... but this is not what you pay when you buy one of these advanced displays.

[D Fosse]

I've now disabled Calibration Loader triggers, and yes, it works. It's a relief to know that there is at least a workaround for now.

But as Yume-chan points out it's a serious drawback that you are now restricted to a single profile per session, without logging out and back in. I have several calibration targets for different paper stock and output, and switching between them on the fly has always been a huge time-saver. Yes, it was necessary to relaunch the application, so there was always a small interruption - but still. A full logout is much more disruptive since you also have to close out everything else you were doing.

Let's hope Microsoft is on the ball.

(as a side note I'm now back on my work system, just like my home system Win10 1903 and Eizo Colornavigator. The interesting thing is that while there is banding here too, it looks different from my home system, and not quite as pronounced. So there is some sort of random component in this).

[davescm]

How does loading multiple monitor LUTs fair i.e. 3 monitors , 3 LUTs on one GPU card

Dave

[D Fosse]

davescm  wrote

How does loading multiple monitor LUTs fair i.e. 3 monitors , 3 LUTs on one GPU card

Dave

Seems to work fine with two, at least. Both Eizos on this system now behave nicely - they both showed identical banding before disabling the triggers.

Which in itself is interesting, because the banding patterns on the two monitors seemed absolutely identical - even though they of course have separate profiles. So that definitely points to video card output or perhaps even before the video card (I'm not technically competent enough to pinpoint it to "framebuffers" or anything like that ). In other words - it doesn't seem to matter how many.

[davescm]

Thanks Dag. I'll follow this and hopefully see a OS solution before I update. If not it is good to know there is an workaround.

Dave