microsoft / PowerToys

Windows system utilities to maximize productivity

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Improved subpixel text rendering for OLED (WRGB stripe, RGB triangular) -- Unfixable by ClearType Tuner (Over 100 upvotes in Feedback Hub)

mdrejhon opened this issue · comments

Description of the new feature / enhancement

NOTE: I do paid work with display manufacturers.

Repost of incorrectly-closed github item that someone else posted:

ClearType alters anti-aliasing assuming an RGB stripe subpixel configuration. More WOLED (WRGB stripe) and QD-OLED (RGB triangular) monitors are coming to market and have noticeable chromatic aberration/color fringing on edges of text. It would be nice if Windows had a built-in option to alter text rendering based on subpixel configuration of the monitor.

Scenario when this would be used?

When using a WOLED or QD-OLED monitor with WRGB stripe or RGB triangular subpixel configuration to improve text clarity.

Supporting information

https://www.youtube.com/watch?v=52eiLP3Zy-s

https://youtu.be/k-6yc1dA--0?t=602

https://youtu.be/PR-1tMih0fM?t=442

It is definitely a real problem caused by unresolvable ClearType limitations. The earlier github item (#25568) was incorrectly closed by someone who thought it was a feature already built into windows; so creating new GitHub issue.

As founder of Blur Busters / TestUFO, I work with computer monitor manufacturers; so I will explain

GOOD: What ClearType Is Compatible With:

ClearType is only compatible with vertical-stripe RGB and BGR pixel structure.

RGB: image

...and...

BGR: image

BAD: What ClearType definitely NOT Compatible With:

No, ClearType tuner doesn't fix this properly. It is unable to 100% unable to fix this.

LG WOLED, all televisions and monitors

image

It is not possible to control the white sub pixel in software, but ClearType can still at least go into a special "RBG" mode where the blue subpixel is in the middle, and the green subpixel is at the right edge. I did some PhotoShop tests and it actually makes text better on an LG WOLED. It looks much better, here are some example PhotoShop images that works fine on an OLED at 1:1 pixel mapping:

One possible solution: Use an RBG ClearType mode where B is middle subpixel

I photoshopped this special sample that looks absolutely fantastic on LG WOLEDs.

image
(...Note: I know contrast is a bit extreme so there's a bit of excess sharpening-effect; it should be adjustable...)

So, dear Microsoft, here's definitive proof that ClearType modifications are required to look better than anything that ClearType Tuner can do. Winky-wink. 😉 😉 😉

Samsung QD-OLED, all televisions and monitors

They use a triangular structure as follows:

image

Actual macro photograph of a Samsung QD-OLED:

image

Which produces a text fringing problem at top/bottom of texts:

image

ClearType Tuner is 100% completely unable to remove this fringing. Even alternative utilities such as Better ClearType Tuner can't fix this artifact.

  • Greyscale mode still has green/purple fringing (at all adjustment settings)
  • RGB mode still has green/purple fringing (at all adjustment settings)
  • BGR mode still has green/purple fringing (at all adjustment settings)

This is because the green sub pixel is at the top edge, and red/blue subpixel is at bottom edge. ClearType is unaware of this subpixel layout.

Monitor reviewers such as RTINGS complain about this.

https://www.rtings.com/tv/reviews/samsung/s95b-oled#test_178:~:text=LEARN%20ABOUT%20REFLECTIONS-,Pixels,-Subpixel%20Layout

The Samsung S95B uses a unique subpixel structure. Instead of having all three subpixels in a row, each pixel forms a triangle, with the larger green subpixel at the top. This isn't really noticeable with most video content, but it's an issue if you're using the TV as a PC monitor. Text has just okay clarity from a PC, as WINDOWS CLEARTYPE SETTINGS AREN'T DESIGNED FOR THIS subpixel structure, and CAN'T CORRECT FOR IT. You can see a few examples below:

Possible Method of Implementations

Short term implementation

A future "Enhanced ClearType Tuner" utility would accept a bitmask PNG file (square shaped) that shows where the red, green, blue subpixels are within one single pixel (ignoring any white subpixels, if any)

An enhanced ClearType would automatically use this than the old-assumption of RGB stripe. This proposed bitmask file (to define structure of one pixel) can be small, e.g. 32x32 or 64x64, and only be Red, Green and Blue pixels with the rest of pixels black or transparent.

Long term implementation: Plug-and-Play!

Since monitor manufacturers are continually coming out with custom subpixel structures, monitor drivers (.INF) can provide an optional pixel structure (possibly as a bitmask, or a base64 data: PNG bitmask, 32x32 or 64x64), or even multiple string rows such as "0111022203330" per pixel row (where 1=red, 2=green, 3=blue) for human readability.

The ClearType renderer would automatically use this known subpixel structure to provide accurate subpixel rendering. Monitor manufacturers can provide custom monitor-specific INF files that automatically inform Windows of the special subpixel structure.

Precedent

Many smartphones already supports custom subpixel renderers (e.g. Pentile), though proprietary to the specific-display Android manufacturer (e.g. not visible in AOSP source code that is coded to a generic display).

Known Issue

Sometime not too long ago, Microsoft made a mistake of simplifying ClearType rendering to only use one format for all multimonitors. This created problems for people using mixed RGB and BGR setups, which wasn't a problem during Windows XP days but is now a problem today with Windows 11.

Instead of per-monitor ClearType tunings, Microsoft made the ClearType tuning global -- facepalm for many use cases. The LCD RGB-stripe hegemony is diminished because of the giant boom of mixed-monitor use cases, and new OLED computer monitors.

So the originally well-intentioned simplification shot itself in its feet;

Display rotation of tablet PCs also affects ClearType; Microsoft had to make adjustments to ClearType to keep it looking correct at all screen rotations. It is possible the affects-all-monitors simplification occured around this time (approximately Windows 8, not sure), when the ClearType engine was possibly refactored by Microsoft.

Thus, Microsoft needs to undo this feature regression (now becoming increasingly visible in a multimonitor era), which was only because of the hegemony of RGB-stripe LCDs.

One massively common use case is some people connect an RGB laptop to a BGR television set (more than half of TVs made today are BGR!). This accidental Microsoft regression made many years ago, needs to be undone.

TL;DR Summary of feature regression

BEFORE: In some past versions of Windows, you could configure multimonitor -- e.g. RGB on laptop/monitor and BGR on TV.
AFTER: Right now you can't. It's either RGB or BGR globally for all displays in your multimonitor.

This Could Be Marketed As "ClearType 2"

  • Supports custom subpixel structures (new)
  • Supports per-monitor subpixel structures (reintroduced)

Thanks for bringing more attention to this issue. I originally linked the wrong LTT YouTube review. Here is the correct link where he discusses insufficiencies of ClearType with OLED:

https://youtu.be/PR-1tMih0fM?t=442

Thanks for bringing more attention to this issue.

You're welcome!

As I currently am on paid contract work with LG Korea regarding their brand new 240Hz WOLED panels that are supplied to multiple manufacturers (ASUS, Corsair, etc), I can assure you that several end-users are now complaining about this.

Please feel free to share the permalink to other experienced/advanced/programmer computer users who just purchased the new 2023-model OLED computer monitors, to bring more attention to this item.

Permalink: https://github.com/microsoft/PowerToys/issues/25595

To Microsoft Employees:

Perhaps forward the permalink to the ClearType renderer contacts for further thought?

commented

@crutkas this guy should be working for Microsoft

commented

I do think this is an issue between hardware and OS developers, though. Have you contacted Microsoft in a more direct manner?

Yes, thought about forwarding @Jason-GitH suggestion too.

But this is a known difficult communicate (even via business channels, easily-dismissable, the original github was closed) with an unclear incubate venue. I think you understand that I am desparate enough to have to go through this channel, now, too.

ClearType was developed in 1998 as an application-based feature (Microsoft Reader) and then ported into the OS. It's been a very stagnant feature that doesn't even have an assigned maintainer at Microsoft anymore, I think. However, it went into a Microsoft Research paper (I think) and perhaps the original researchers are still at Microsoft 25 years later.

ClearType can be done without the initial involvement of hardware developers, as it can be done application based and as demonstration PhotoShop images. So, it may be easier to incubate application-side first. After all, the 1998 version of ClearType was just a book/text/doc reader application...

The use of OLEDs in computer monitor has woken up this otherwise old mature feature.

Later this year, I may publish an article/whitepaper (better rewrite-copy of this image-illustrated GitHub item) at Blur Busters later and post a link on the Feedback Hub. Links are also unclickable in it too. If only Feedback Hub was also github that I can post illustrated embeds in (not file attachments), y'know?

Still, it seems technically possible to incubate this first as a third party application (aka PowerToy) -- there are third party font renderer utilities, such as MacType for Windows - www.mactype.net

Plus, the ClearType Tuner app was also originally a PowerToy too.

So, still relevant here. 😄

Starter Generic Subpixel-Aware Supersampling Algorithm

For every time one font glyph is rendered onscreen:

  1. Check if the glyph is already in the subpixel-scaled glyph cache (for a specific glyph at a size with all combining marks etc)
    If yes, skip to step 5.
  2. Render a single character (font glyph) in-memory at high scaling factor (e.g. 16x size).
    Example: If it's a 16point character of Arial, draw it at 256point size within GPU memory
  3. Downscale the supersized font letter through the subpixel-structure bitmask
    Example: Use a GPU shader to push the large font letter through the subpixel-structure bitmask during downsample
  4. Cache the resulting downsampled bitmap (for faster run at step 1)
  5. Draw the glyph onto the screen
    The bitmaps should be transparent with an alpha channel, to be compatible with overwritten text / overlay on complex background / linked letters like Arabic / etc).

Basically, pushing a supersized version of the glyph through the subpixel mask during downsample. This is very simple ultra-fast GPU shader code.

Or you could use layering of existing DirectWrite/Direct2D APIs instead (e.g. bitmap scaling and bitmap-combining mathematics similar to ADD, SUBTRACT, AND, OR, XOR, alpha-blend operations etc) instead of GPU shader code. (And many of these APIs compile as shaders anyway when GPU acceleration is enabled). Various settings can be done to adjust.

ClearType Contrast can be simply an alphablend/math between a non-subpixel-compensated glyph and a subpixel-compensated glyph. And configurable supersample size (6x, 8x, 10x, 12x, 14x, 16x, [...]) for quality experiments.

One consideration; there will be loss of OpenType/TrueType "hinting" for small-size fonts (due the large-glyph rendering step) but the resulting correct subpixel render (up to ~3x more resolution possible) without hinting, will look superior to hinted-but-incorrect/blurrier. In other words, the nonstandard-subpixel-structure sharpness improvement outweighs the loss of "hinting" support for the vast majority of fonts -- even for complex fonts such as Mandarin, etc, that goes very soft/blurry on WOLEDs.

Either way, while it sounds difficult at first -- the generic algorithm is actually absurdly simple to a shader programmer or bitmap-mathematics programmer, once they're trained to understand ClearType better (e.g. treat the subpixels like additional pixels spatially)

There can be optimizations later to speed things up, and hinting support re-added later. But the algorithm is very simple.

Technically, first step could be done as an open source Reader application, even a rudimentary TXT viewer (font and size configurable in menus). Not too different from a simplified version of 1998's Microsoft Reader.

So the first step is a simple font renderer library for applications, using this algorithm, maybe? Though I have no time to start the project, I can code-review it, and I can tweak the code's algorithm to the correctness needed, or add other features (like adjustable alphablend between subpixel-scaled vs nonsubpixel-scaled, as a Contrast setting).

Possible Path of Introduction?

There might be many other workflows to incubate this at the open source level. But I'd propose to break it down to simple steps. Slowly introducing "ClearType 2":

  1. Awareness-raising as font-renderer library for applications (incubate as separate github project) like 1998's Microsoft Reader
  2. Then as OS-wide PowerToy (this github item) uses that library;
  3. Then native OS feature (become part of ClearType)

This may not be the best path, but gives the gist of steps-breakdown for a simpler path of introduction of "ClearType 2".

EDIT APRIL 2022

There's precedent and existing open source code of a font subpixel renderer: FreeType documentation is rather interesting about a possible subpixel-structure-flexible algorithm:
https://freetype.org/freetype2/docs/reference/ft2-lcd_rendering.html

Related discussion, since the proposed ClearType 2 PowerToy would need to fix this;

More Information About ClearType Tuning Problem with Multimonitor

Some people argue it isn't a feature regression, but a do-nothing bug, or some intentional change -- but I wanted to add some context of the ClearType multimonitor issue (global vs per-monitor):

Research (by the author of Better ClearType Tuner) about this multimonitor pboelm:
https://github.com/bp2008/BetterClearTypeTuner/wiki/ClearType-Investigations

Also, tons of reddit complaints, especially when multimonitoring with televisions (which uses BGR)
https://www.google.com/search?q=ClearType+Tuner+multimonitor

It's one of those hard-communicate bugs that will probably easily get overlooked in Feedback Hub;


I reference bp2008/BetterClearTypeTuner#11 -- the person @bp2008 who wrote "Better ClearType Tuner" -- because he had to close the multimonitor-ability because of the Microsoft bug/regression involving multimonitor ClearType.

I'm pulling him in to see if he's got any interest commenting about the bug/regression here.

Let me see if there's a Feedback Hub for this Microsoft ClearType bug/regression, if not, I will create one within the month. It's obscure-but-frustrating. But I will publicly mirror here for relevancy (until Feedback Hub is replaced with a public-facing GitHub Issues system)

Over 100 Upvotes in Feedback Hub for "ClearType 2"

Okay, I have audited Feedback Hub, and whoo-boy, this is a popular complaint by OLED owners.

This issue is so obscure (that the duplicate-item judges do not even understand these are duplicates). I will flag by copy and pasting some of this comment in Feedback Hub.

Search Terms: "cleartype OLED", "cleartype WOLED", "cleartype QDOLED"

Duplicate Feedback Hub List

Related ClearType Bug Reports For Gaming/Multimonitor

  • https://aka.ms/AAkjw7z -- "ClearType setting for different subpixel layouts for different screens (for second monitor rotated to portrait/vertical position)" (6 upvote)
  • https://aka.ms/AAkcebe -- "ClearType text tuner incorrectly warns about non-native resolution"
  • https://aka.ms/AAb5v10 -- "Blurry text on my portait orientation monitor after updating to build 21313" (8 upvotes)

Let's consider many users don't understand how to bug report this

Especially considering many experienced programmers don't even understand the algorithm behind ClearType (including, possibly, also the person that closed the original PowerToy item).

End users just see text being much blurrier than OLED, compared to Apple's subpixel optimizations for their OLED iPhone and iPad, and wonder why Microsoft Windows is very bad;

Adebisi T (Microsoft Engineer) seems currently confused by this report in one of the items, maybe forward this GitHub permalink (Can anyone tag his github username?)

Since github allows me to quickly type at 140wpm with easy photo-pasting (screenshots, etc), I shall continue to use this GitHub as the control-room item to communicate ClearType problems to Microsoft. As a line-item exception, Feedback Hub which is nigh impossible to correctly communicate the fairly complicated ClearType multimonitor bug/regression, combined with feature request for QD-OLED compatible ClearType.

It looks like MacType might be able to work on this: snowie2000/mactype#720

We'll push that front, too.

It looks like MacType might be able to work on this: snowie2000/mactype#720

We'll push that front, too.

That's good to know. Their findings will be useful. I wish MacType had broader applicability but its effects don't get applied throughout several areas of Windows UI, UWP apps, and Chromium.

That's good to know. Their findings will be useful. I wosh MacType had broader applicability but its effects don't get applied throughout several areas of Windows UI, UWP apps, and Chromium.

Agreed.

That being said, it is a bonafide third party font renderer that already has built-in optional RGB subpixel support.

So it is a potentially useful incubation venue before something similar comes Microsoft-side. While MacType is usually used without subpixel rendering, it does have subpixel rendering available (for RGB LCDs at least).

So, MacType is proof that a third party subpixel-capable font render already exist, and therefore "ClearType 2" could be incubated via the PowerToy venue;

Be noted, MacType is GPL, and generally Microsoft prefers to use MIT/Apache code for open source ClearType applications. However, I have publicly posted the generic subpixel rendering knowledge, which can be written independently by them and by Microsoft.

Donation OLED Offer to Software Developer With Font Cred

Also, since I am the owner of Blur Busters -- I might be able to donate a spare OLED monitor (1440p 240Hz!) later this year to an experienced subpixel-font programmer (e.g. MacType programmer or ClearType programmer) if they want to take upon the ClearType 2 task. I will (by summer) have way too many 240Hz OLEDs cluttering up my Canadian office, and this is a very noble initiative. The value of the monitor is over $1000.

Many Announcements For Desktop OLED in Year 2023 ALONE

Let's remember the Feedback Hub complaints was almost singlehandedly the Dell Alienware AW3423DWF that shipped last year in 2022. Get your horses ready; are you sitting down? Here's the 2023 tsunami flood:

It is highly probable that the number of computer users using OLED is projected to go up an order of magnitude very rapidly from nearly-nil in 2022, by the end of 2023, all singlehandedly due to the large number of OLED product hitting the market this year.

It looks like MacType might be able to work on this: snowie2000/mactype#720
We'll push that front, too.

Based on comments at my new MacType feature request: snowie2000/mactype#932 --
I think the primary MacType author didn't seem understand (initially) nor seemed interested. However, the feature request is there, just in case in case other maintainers/volunteers takes the torch and prefers that incubation route.

So that gives an open source text-renderer programmer multiple choices of incubation venues.

  • As ClearType 2 PowerToy (this item) in honor to ClearType Tuner PowerToy ancestry; or
  • As third party font renderer (MacType-for-Windows via mactype#932); or
  • As third party renderer library for application-level use;

As ClearType was originally incubated as an application (Reader) and a PowerToy (Tuner) before it becomes an OS feature; there is a clear need to communicate clearly in all possible incubation venues, until someone comes along who concurrently understands the problem, knows hows to code the solution, and has time to do so.

QD-OLED Tester Wanted

Possible MacType Incubation Under Way

OK, I think MacType might have just incubated it -- it apparently had vestigal support for subpixel vertical positions, so some creative configuration file editing made it compatible with triangular-structure OLEDs! Need some guinea pigs for these PNG images designed for triangular-pixel-structure QD-OLED.

For users of QD-OLED displays

image

Test image for triangular-subpixel QD-OLED displays

image

Which one has the least green/blue fringing artifact?

Please specify if 1, 2, 1b, 2b, 1c, 2c, 1d, 2d looks the best on your QD-OLED display.

The test image here, and information here, will also help Microsoft evaluate improvements to ClearType (possible concurrent incubation), perhaps as a possible "ClearType 2 Tuner PowerToy"

I have played around with MacType quite a bit on WOLED. The built-in CRT profile as well as DeepGrayNoHinting / SoftGrayNoHinting did the best at eliminating fringing in Windows UI but don't improve sharpness noticeably.

I have played around with MacType quite a bit on WOLED. The built-in CRT profile as well as DeepGrayNoHinting / SoftGrayNoHinting did the best at eliminating fringing in Windows UI but don't improve sharpness noticeably.

However these seem to do grayscale rendering, which would avoid dealing with this topic completely.

I have played around with MacType quite a bit on WOLED. The built-in CRT profile as well as DeepGrayNoHinting / SoftGrayNoHinting did the best at eliminating fringing in Windows UI but don't improve sharpness noticeably.

However these seem to do grayscale rendering, which would avoid dealing with this topic completely.

Yep. Disabling ClearType, setting Better ClearType Tuner to grayscale aliasing, or using one of those aforementioned MacType profiles accomplish reducing color fringing in most areas on WOLED. There are still some areas of Windows UI that remain affected, though. And sharpness is not as good as I think it could be.

I have played around with MacType quite a bit on WOLED. The built-in CRT profile as well as DeepGrayNoHinting / SoftGrayNoHinting did the best at eliminating fringing in Windows UI but don't improve sharpness noticeably.

However these seem to do grayscale rendering, which would avoid dealing with this topic completely.

Correct. Thumbs-upped you. However...

LG OLED demo image has extremely sharp text

With the LG OLED demonstration image having nearly twice as sharp text than any of the other options ...

(viewing the LG OLED images on anything else other than LG OLED, will not work -- it is as sharp as well-optimized LCD ClearType).

There are ClearType fans that would like the sharpest possible text.

Everybody sees differently.

  • Different degrees of eyevision acuity and eyeglasses prescriptions.
  • Different degrees of colorblindness (12% of population is colorblind).
  • Different people are bothered by different things more than others.
  • Some of us don't notice the color fringing as blatantly as the text-fuzziness
  • Others like the zero-subpixel MacType look better.
  • My policy is not to visionsplain anyone for them, and let people choose their preference.

It is a matter of personal preference

There should be an adjustable Contrast/Saturation setting, so that fringing can be easily adjusted, while keeping text sharp. This is easy to do with ClearType Tuner, but very hard to do with MacType.

commented

Thank you for bringing attention to this issue.

profiles accomplish reducing color fringing in most areas on WOLED. There are still some areas of Windows UI that remain affected, though. And sharpness is not as good as I think it could be.

WOLED is more immune to fringing than Samsung QD-OLED. It's easier to fix fringing on WOLED than QD-OLED, and color fringing on QD-OLED is completely unfixable without some subpixel rendering adjustments.

I just got some reports from [H]ardForum that people like the QD-OLED image:

  • "The 2's have far less or no fringing to my eyes. 2,2b, or 2d are the best. I can't notice much difference between them. Everything on the left has obvious fringing."
  • "On the [Alienware] DWF, 2 is the best with 2b as close second. Clear fringing on all the 1's.*

EDIT: Comments from #25595

  • "I'm on an AW3423DW. All of the 2's don't have much fringing to me or others I've had try. 2 looks the best to me, while 2b and 2c looked the best to two other people."

For the LG OLED image, I have gotten some rave reviews already, but I need to convert it to a proper MacType config file.

Which one has the least green/blue fringing artifact?
Please specify if 1, 2, 1b, 2b, 1c, 2c, 1d, 2d looks the best on your QD-OLED display.

I'm on an AW3423DW. All of the 2's don't have much fringing to me or others I've had try. 2 looks the best to me, while 2b and 2c looked the best to two other people.

FYI, I've been using MacType on QD-OLED (AW3423DW) with the Pixel Layout specified in this reddit post and fringing is almost completely eliminated.
Thanks for your work on the TestUFO website and for trying to draw attention to this misunderstood issue to Microsoft's attention!!

not totally sure this is something the PowerToys team could fix but asking around

cleartype已经过时落伍了,它对于中文字体的渲染简直是噩梦级的,比macos/linux的字体渲染差太多太多

My LG WOLED panel monitor is on it's way home, but already looking for a proper solution from Microsoft.

cleartype已经过时落伍了,它对于中文字体的渲染简直是噩梦级的,比macos/linux的字体渲染差太多太多

Translation:
cleartype is outdated, its rendering of Chinese fonts is a nightmare, much worse than macos/linux's font rendering.

FYI, I've been using MacType on QD-OLED (AW3423DW) with the Pixel Layout specified in this reddit post and fringing is almost completely eliminated. Thanks for your work on the TestUFO website and for trying to draw attention to this misunderstood issue to Microsoft's attention!!

Oh wow! That one is unbeknownst to me! That's a 9-month-old independent reddit fix for the unfixable QD-OLED color fringing problem, independently came up by someone else.

It's only specific to QD-OLED and not to the other subpixel structures, though;

More reason for subpixel structure spec to be included in monitor drivers.

There are well over 220 upovotes on that Reddit post, so there's clearly demand.

FYI, I've been using MacType on QD-OLED (AW3423DW) with the Pixel Layout specified in this reddit post and fringing is almost completely eliminated. Thanks for your work on the TestUFO website and for trying to draw attention to this misunderstood issue to Microsoft's attention!!

Oh wow! That one is unbeknownst to me! That's a 9-month-old independent reddit fix for the unfixable QD-OLED color fringing problem, independently came up by someone else. It's specific to QD-OLED and not to the other subpixel structures, though;

More reason for subpixel specs to be included in computer monitor drivers.

Completely agree, it would be great if computer monitors could advertise their pixel layout, I think it's going to be more and more needed with all the new OLED panels coming out.
However, I'm not sure if the solution shown in the Reddit post would work as well on WOLED because of the white pixel (maybe specifying using PixelLayout only the RGB leds and ignoring the white led would work?), but on QD-OLED it's really been amazing.

FYI, I've been using MacType on QD-OLED (AW3423DW) with the Pixel Layout specified in this reddit post and fringing is almost completely eliminated. Thanks for your work on the TestUFO website and for trying to draw attention to this misunderstood issue to Microsoft's attention!!

Oh wow! That one is unbeknownst to me! That's a 9-month-old independent reddit fix for the unfixable QD-OLED color fringing problem, independently came up by someone else. It's specific to QD-OLED and not to the other subpixel structures, though;

More reason for subpixel specs to be included in computer monitor drivers.

Completely agree, it would be great if computer monitors could advertise their pixel layout, I think it's going to be more and more needed with all the new OLED panels coming out. However, I'm not sure if the solution shown in the Reddit post would work as well on WOLED because of the white pixel (maybe specifying using PixelLayout only the RGB leds and ignoring the white led would work?), but on QD-OLED it's really been amazing.

Does the fringing persist in areas not affected by MacType? Chrome, UWP, etc

However, I'm not sure if the solution shown in the Reddit post would work as well on WOLED because of the white pixel

No, it does not.

I've written about the need for separate custom subpixel profiles -- which is why their unique subpixel profiles should be in monitor drivers.

(maybe specifying using PixelLayout only the RGB leds and ignoring the white led would work?),

Yes, my tests above show ignoring the whitesubpixel works -- though it would have been even better to have direct control of it, too.

snowie2000/mactype#932 (comment)
snowie2000/mactype#932 (comment)

image

However, some more experimentation is needed to come up with a MacType version of this Photoshopped image.

Does the fringing persist in areas not affected by MacType? Chrome, UWP, etc

Unfortunately, yes. You will have to do the Edge/Chrome hacks documented at https://github.com/snowie2000/mactype/wiki/Google-Chrome
The gist is the following:

Being able to override the built-in front renderer and using a third party renderer requires disabling integrity (security consideration)

chrome.exe --disable-features=RendererCodeIntegrity

Or modifying RendererCodeIntegrityEnabled for registry keys:

  • HKLM\Software\Policies\Microsoft\Edge, for new Edge
  • HKLM\Software\Policies\Chromium, for Chromium
  • HKLM\Software\Policies\Google\Chrome, for Chrome
  • HKLM\Software\Policies\BraveSoftware\Brave, for Brave

Then it can use third party font renderers.

But this is not ideal from a security perspective. Long-term, a Microsoft-native solution for what MacType can do with QD-OLED, would be highly desired, to reduce the security.

Does the fringing persist in areas not affected by MacType? Chrome, UWP, etc

Unfortunately, yes. You will have to do the Edge/Chrome hacks documented at https://github.com/snowie2000/mactype/wiki/Google-Chrome The gist is the following:

Being able to override the built-in front renderer and using a third party renderer requires disabling integrity (security consideration)

chrome.exe --disable-features=RendererCodeIntegrity

Or modifying RendererCodeIntegrityEnabled for registry keys:

  • HKLM\Software\Policies\Microsoft\Edge, for new Edge
  • HKLM\Software\Policies\Chromium, for Chromium
  • HKLM\Software\Policies\Google\Chrome, for Chrome
  • HKLM\Software\Policies\BraveSoftware\Brave, for Brave

Then it can use third party font renderers.

But this is not ideal from a security perspective. Long-term, a Microsoft-native solution for what MacType can do with QD-OLED, would be highly desired, to reduce the security.

Indeed, that's what I had to do. That's why this issue needs to be resolved by Microsoft more globally and more safely.

For those unaware of the color fringing is on QD-OLED, this is what it looks like:

What QD-OLED looks like without subpixel rendering help;

  • Green fringing at top, purple fringing at bottom -- even with ClearType disabled, even MacType greyscale (no subpixel)

image

QD-OLED with subpixel rendering help

image

This is not the most optimized result though -- several results of varying sharpness/crispness and fringingness depending on the settings -- this is just an illustration for people who do not own QD-OLED, to understand the green/purple fringing effect that is permanent (at all ClearType and non-ClearType settings);

Does the fringing persist in areas not affected by MacType? Chrome, UWP, etc

Unfortunately, yes. You will have to do the Edge/Chrome hacks documented at https://github.com/snowie2000/mactype/wiki/Google-Chrome The gist is the following:
Being able to override the built-in front renderer and using a third party renderer requires disabling integrity (security consideration)
chrome.exe --disable-features=RendererCodeIntegrity
Or modifying RendererCodeIntegrityEnabled for registry keys:

  • HKLM\Software\Policies\Microsoft\Edge, for new Edge
  • HKLM\Software\Policies\Chromium, for Chromium
  • HKLM\Software\Policies\Google\Chrome, for Chrome
  • HKLM\Software\Policies\BraveSoftware\Brave, for Brave

Then it can use third party font renderers.
But this is not ideal from a security perspective. Long-term, a Microsoft-native solution for what MacType can do with QD-OLED, would be highly desired, to reduce the security.

Indeed, that's what I had to do. That's why this issue needs to be resolved by Microsoft more globally and more safely.

I believe Chromium doesn't use ClearType at all so fixing ClearType would not help that specific case. For Chrome at least --disable-lcd-text can enable grayscale rendering, but as shown by the post right above this that's probably not a solution.

More precedent

FreeType documentation is rather interesting about a possible subpixel-structure-flexible algorithm, that doesn't require a bitmask technique.
https://freetype.org/freetype2/docs/reference/ft2-lcd_rendering.html

Popular request among OLED owners

image

EDIT - Oh wow, there's quite a lot of upvotes earlier in this thread -- Appreciate the support.

More precedent

FreeType documentation is rather interesting about a possible subpixel-structure-flexible algorithm, that doesn't require a bitmask technique. https://freetype.org/freetype2/docs/reference/ft2-lcd_rendering.html

Popular request among OLED owners

image

EDIT - Oh wow, there's quite a lot of upvotes earlier in this thread -- Appreciate the support.

I posted your GitHub Issue thread on several OLED gaming forums to get some support. Feedback has been in Windows Feedhub for years and nothing has come of it.

Btw, building off your FreeType link: https://gitlab.freedesktop.org/freetype/freetype/-/issues/1182

image

@mdrejhon Do you know if the EDID for these monitors contains the subpixel layout information? From my basic understanding of ClearType, it is more of a 'workaround' for doing things the correct way; reading the subpixel information from the monitor itself and then making an automatic adjustment for the display.

image

That document is from 2006, but I doubt there has been enhancements since then in the EDID for this specific scenario. You can use this tool to inspect some of the information provided by the display.

Note: I do work at Microsoft but I'm not associated with anyone who knows how to fix this issue. However, I do desperately want this issue fixed.

@MiYanni I tried ControlMyMonitor with LG C2 but it just gave an error. I tried the Monitor Asset Manager and it gave me some EDID info. I don't think it's reporting what you need, though, as it's not a monitor but a TV. It reported the following: EDID

I tried ControlMyMonitor with LG C2 but it just gave an error. I tried the Monitor Asset Manager and it gave me some EDID info. I don't think it's reporting what you need, though, as it's not a monitor but a TV. It reported the following info.

@Jason-GitH The Google doc you linked is not publicly shared (meaning, no one can access it). Any chance you could put the info into a public Gist instead?

@mdrejhon Do you know if the EDID for these monitors contains the subpixel layout information? From my basic understanding of ClearType, it is more of a 'workaround' for doing things the correct way; reading the subpixel information from the monitor itself and then making an automatic adjustment for the display.

It's useful hinting when combined with other info. But unfortunately, this is unreliable -- many don't report the information accurately enough to calculate the subpixel structure. I wish it was a much better situation, sadly. Even some BGR TVs incorrectly report themselves as RGB-stripe TVs.

The probable best way to do it is either
(A) Via manufacturers updating their monitor .INF (add subpixel-structure info to .INF files). For ones without subpixel structure in .INF file a custom "Cleartype 2 Tuner" utility should have some predefined profiles ("QD-OLED", "WOLED", etc).
(B) Via a (potentially crowdsourced) DeviceID database of known subpixel structure associated. You know, those 7-character Plug and Play IDs reportable by APIs. e.g. "BNQ74F8" or "VSC37C4".
(C) Via combination of both of above;

Existing Windows APIs such as QueryDisplayConfig() can get these unique Device IDs, to allow you to determine which model computer monitor the computer is connected to. (That's how the display name is often populated in Control Panel too)

For example Device ID prefixes are manufacturer. "BNQ" is for BenQ Zowie and "VSC" is for ViewSonic. These are port specific, and for some manufacturers, are unique representations of one port of a monitor. So you could have BNQ74F8, BNQ74F9, BNQ74FA, and BNQ74FB for consecutive ports on the same model monitor. And a different model would get BNQ74FC, BNQ74FD, BNQ74FE, BNQ74FF for their respective ports. And so on. Annoyingly some manufacturers recycle their codes for different model TVs despite having their manufacturer-specific EDID code. So may have to collaborate with other EDID information (e.g. native resolution reported, and other supported features) to create a unique ID for crowdsourced database.

Crowdsourced Device ID databases are very common with streaming devices for their remote controls. The streaming boxes and devices attempt to recognize the TV model via Device ID, and automatically load universal remote codes. New undiscovered TVs will force you to go through the laborious manual scan, and after a few weeks, the crowdsourced database at Amazon's end (for FireTV) or Apple's end (for AppleTV) is automatically updated to associate a new Device ID with a new TV, if many users keep using the same set of infrared codes for a specific TV. This common crowdsourced practice, can be applied to subpixel-structure preferences selected by a tuner-utility, if the respective Privacy Policy allows this collection of crowdsourcing data;

Even TVs are finally adding Device IDs now to make universal remotes plug and play! Universal remotes on my FireTV auotmatically recognized the 7-character DeviceID returned by really new HiSense TV and a really new LG TV, and correctly loaded the infrared codes for the televisions' volume buttons, mute and power button -- correct code on the first try -- without the usual glitchy remote-scan step of TVs just a few years ago.

This sort of data is also crowdsourceable (if privacy agreement allows), e.g. multiple users submitting that they've got a specific subpixel configuration for a specific DeviceID, could automatically update a master subpixel-structure database, much like updating a master universal-remote-codes database.

@mdrejhon This project is getting noticed! https://www.flatpanelshd.com/news.php?subaction=showfull&id=1682676702

@MiYanni I updated the C2 EDID as a Gist.

LG 27GR95QE EDID Gist

commented

Dell Alienware AW3423DW EDID Gist

Asus PG27AQDM EDID gist

commented

Samsung Odyssey G8 QD-OLED EDID gist

Edit: ControlMyMonitor gives "Error 0xc0262582" with both DP and HDMI so for now can't get the info.
Edit2: Added EDID requested by @mrehkopf

Dell Alienware AW3423DWF ControlMyMonitor gist

Unless Microsoft says otherwise -- I do not think sending gists for common RGB LCDs is productive at this juncture (I already have access to a better crowdsourced EDID database at the moment, but mainly on older LCD models -- not on OLED).

But sending gists for OLEDs are productive. That AW3423DWF gist is useful. Thanks.

@LamTop @mrnicedonovan @Ncl8 Apparently those manufacturers put the serial number in the EDID. You may want to delete those from your public gist.

There is an upcoming OLED monitor from Dough called Spectrum OLED. They sent this cryptic email today implying they are "experimenting" apparently by putting a subpixel filter on (?). Assuming they are doing this for text rendering, this would obviously be an ineloquent solution to a ubiquitous problem.

image

@Jason-GitH I have communications with several manufacturers.

No, the filter is unrelated to subpixel structure correction -- this has nothing to do with the discussion in this thread. Spectrum's monitors are glossy (without film) as far as I know, and it is a comparison to the other manufacturers that use an antiglare film on their monitors.


On a related topic, there can be some panel-side mitigations possible where the RWBG pixel structure [RWBG][RWBG][RWBG] is processed as BGRW as RW][BGRW][BGRW][BG instead, to improve compatibility with BGR ClearType.

However, in the long-term, Windows support for nonstandard pixel structures needs to be implemented, as there are many structure that can't be mitigated hardware-side to improve compatibility with ClearType. Design decision to improve OLED pixel longevity, and fabrication, creates the necessary aberration away from RGB-stripe structure for some screen technologies.

commented

Isn't this not just a text rendering issue? In some of the correction images posted here this seems fixed for text but not for other elements. I know of many RGB layout monitors also having issues with colored fringing on objects (but not all). This should be able to be improved by sharpness calibration of the monitor itself. More so for QD-OLED than WOLED. Maybe a system wide calibration of Windows could be an option in the future.

Isn't this not just a text rendering issue? In some of the correction images posted here this seems fixed for text but not for other elements. I know of many RGB layout monitors also having issues with colored fringing on objects (but not all). This should be able to be improved by sharpness calibration of the monitor itself. More so for QD-OLED than WOLED. Maybe a system wide calibration of Windows could be an option in the future.

This is correct.

Alas, a lot of the other rendering issues aren't always easy to fix in software.

For example, the red/green fringing of yellow objects on white background on LG WOLEDs is an intrinsic hardware behavior that can't be fixed directly.

However, red/green fringing of yellow objects on black backgrounds is indeed fixable on LG WOLEDs by shifting the red channel to the right (by 1 pixel), or the green channel to the left (by 1 pixel). However, this creates other artifacts. It's theoretically possible that a custom shader or AI-based de-fringing filter is possible, e.g. SweetFX / Reshade style. This will probably require, however, a Windows Indirect Display driver, configured to run a custom shader.

Very likely out-of-scope for this PowerToy; but it is one possible route of de-fringing an OLED via a software filter on top of everything, perhaps as a superscale-downsampler (e.g. running at 2x-3x resolution at 200%-300% DPI, and running it through a shader-based downscaler).

Kind of a complex method to overcome some hardware issues. It's much easier to focus on one item (e.g. text defringing via subpixel-aware filters).

Hi, sorry for barging in like this. I just ordered a QD-OLED monitor (Odyssey OLED G8) so this issue has become relevant to my interests :)

I checked the E-EDID dumps and noticed they are incomplete; apparently the Entech utility only ever dumps the first 256 bytes of the E-EDID even though 2-3 extension blocks are specified.
Expected size is 128 bytes for the base EDID 1.3/1.4 block plus 128 bytes for each extension block.
In case of the LG 27GR95QE it seems to specify an extension block map additionally, adding 128 more bytes.
Comparing the Entech output with the entries in my Windows registry I can confirm that; registry gives me 384 bytes of E-EDID for my current monitor (34WK95U), at least in two of the "...&UID" sub-entries under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY.

@nicck @Ncl8 @LamTop @mrnicedonovan
It would be super neat if you could export your respective registry keys so we can get full raw EDID dumps including all extension blocks. (copy&paste from the binary viewer inside regedit doesn't seem to work, and the export feature outputs a bit of a clunky 20-bytes-per-line format but at least it's complete). If your monitors have multiple sub-entries like in my screenshot, pick the EDID key that is longest; there's a chance that some of them are truncated.

image
image
^ make sure the numbers on the left go higher than 000000F0

Here's a sample of the export from my 34WK95U:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\GSM7720\5&3b7692c&1&UID49411\Device Parameters]
"EDID"=hex:00,ff,ff,ff,ff,ff,ff,00,1e,6d,20,77,**,**,**,**,09,1c,01,04,b5,50,\
  21,78,9e,09,c1,ae,50,44,af,26,0e,50,54,21,08,00,71,40,81,80,81,c0,a9,c0,d1,\
  c0,81,00,01,01,01,01,e7,7c,70,a0,d0,a0,29,50,30,20,3a,00,20,4a,31,00,00,1a,\
  9d,67,70,a0,d0,a0,22,50,30,20,3a,00,20,4a,31,00,00,1a,00,00,00,fd,00,30,3d,\
  1e,87,4c,00,0a,20,20,20,20,20,20,00,00,00,fc,00,4c,47,20,48,44,52,20,35,4b,\
  0a,20,20,20,02,b2,02,03,19,71,44,90,04,03,01,23,09,07,07,83,01,00,00,e3,05,\
  c0,00,e3,06,05,01,4d,d0,00,a0,f0,70,3e,80,30,20,65,0c,20,4a,31,00,00,1a,28,\
  68,00,a0,f0,70,3e,80,08,90,65,0c,20,4a,31,00,00,1a,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,00,00,e3,70,12,79,03,00,03,00,28,70,1d,01,86,ff,13,68,01,\
  18,80,60,00,6f,08,3d,00,2f,00,08,00,b8,8e,00,86,ff,13,68,01,18,80,60,00,6f,\
  08,3d,00,2f,00,08,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,00,00,00,00,ab,90

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY\GSM7720\5&3b7692c&1&UID49411\Device Parameters\WDF]

Note if you want to hide your serial numbers overwrite the 13th-16th entry in the first line of the EDID entry as I did using asterisks in my example (but not in my screenshot 🤔)

That said, my current LG's (albeit LCD) extension blocks do not contain any EDID DDDB blocks at all and I don't have high hopes for the OLED monitors having them, but can't hurt to check...

Monitors Unboxed makes the point that fixing ClearType probably won't make much of a difference due to how limited the applicability of ClearType is in Windows environment: https://youtu.be/vSpo6rmfP0Q?t=210

He also suggests perhaps it would be better to render Windows desktop at super resolution and then have GPU/monitor scale back to native resolution: https://youtu.be/vSpo6rmfP0Q?t=328

**Jason-GitH ** commented May 11, 2023

Yes, that's another option as an alternative.

I mention this already at #25595 (comment)

A USD $2000.00 bounty already offered for this open source driver project

Blur Busters currently already offers a $2K bounty for this -- a subpixel-aware downscaler would allow everything to be "ClearType'd" including graphics, and not just text. This can even be done as a third-party Windows Indirect Display Driver, which I already offer a USD$2000.00 source code bounty for something under MIT or Apache. Contact me at mark[at]blurbusters.com

Basically, a Windows IDD that virtualizes a simulated monitor at a simulated resolution at a simulated refresh rate (can be higher or lower Hz than real display) -- we have some important uses cases for this), and runs all the frames through plug-in GPU shaders, to display on an existing physical monitor.

In addition to solving this problem -- plug-in GPU shaders can enables shockingly creative stuff such as:

  • subpixel-aware downscaling, etc.
  • custom developer refresh rate testing on monitors not owned (e.g. test refresh rates that your monitor does not support)
  • easier software developer testing with displays that aren't in the QA lab, by simulating a display
  • easier hardware prototyping and engineering of future displays, by simulating a display
  • simulated interpolated VRR (www.testufo.com/vrr algorithm) on displays that don't have VRR
  • software based BFI OLED motion blur eduction (www.testufo.com/blackframes#count=3)
  • streaming / headless use cases (without needing to be in a game nor open Remote Desktop)
  • software based overdrive algorithms
  • custom spatial filters (e.g. HLSL CRT filters for retro simulation / preservation).
  • custom temporal filters (e.g. simulate a CRT electron beam, complete with rolling scan and phosphor fade simulation, by using 8 digital refresh cycles per CRT Hz, on 480Hz display that windows thinks it "sees" as a 60Hz CRT tube), for even further improved retro simulation / preservation / education / history education.
  • add frame generation (e.g. reprojection https://www.youtube.com/watch?v=IvqrlgKuowE for 500fps UE5)
  • Other plug-in GPU shaders (that can modify, adjust, scale, process, merge, blend, etc history of buffered "refresh cycle" frames)

The $2K bounty doesn't have to include these custom shaders, but needs to include a plug-in shader system, and end users need the ability to share shaders/profiles with each other (e.g. a sharable modular file-based format, possibly JSON or XML) that loads settings such as shader module (compiled or uncompiled), input Hz, output Hz, constraints if any (outputHz = Formula(inputHz)). It could be a single-file format or a composite (.zip) that includes shaders and settings for a custom filter/processing. Such as shaders that require actual display output Hz to be integer multiples of the virtualized display Hz. The bounty requirements are negotiable (contact mark [at] blurbusters.com), but it needs to meet the needs of the open source community, the retro community, the blur busters fan community, and the commercial community (e.g. display prototyping), as I do work with display manufacturers. As you know, I am the inventor of free display tests used both by indies and manufacturers...

Other options include integration of SweetFX/Reshade/etc into the virtual display driver, including possibly open source or third party lagless frame generation algorithms (e.g. https://www.blurbusters.com/framegen ...) or whole-desktop SmoothVideoProject, etc. So this ideally should be supported too, although it cannot support the entire scope needed. However, the capability for output refresh rates higher AND/OR lower AND/OR variable than the refresh rate visible in Control Panel for the said virtualized display. In other words, the real Hz displayed on real display, is a processed version of the virtualized Hz visible to Windows,. e.g. 60Hz in Windows, but is outputting 240Hz+BFI with persistence adjustability (similar to https://www.testufo.com/blackframes#count=4&bonusufo=1 as one example). Or variable frametimes (I can help you understand how to control VRR).

I really would like to see a driver package capable of running custom shaders at refresh cycle granularity. And enough example dummy shaders to demonstrate successful virtualization of resolution AND refresh rate (both higher and lower than actual physical display(s) connected to computer). INCLUDING of course, variable refresh rate capability which is simply asynchronous timing of Present() that may not be related to timing interval of the refresh cycles. I am OK with the constraint of a fixed-Hz virtualization (just VRR output virtualization).

Although not needed for subpixel processing filters and input=output Hz filters (shader-process-only filters)..... for certain temporal refresh rate filtering tasks I'll need extremely accurate timing of output-frame Present()'s, which MAY require a separate CPU thread that busyloops right before Present() of the composited frame to the actual output display. So an ultra-high-precision presentation timing thread will be mandatory here, I can help assist you -- I have lots of experience via [url=https://forums.blurbusters.com/viewtopic.php?t=4213]Tearline Jedi[/url] raster-interrupt-style beam racing of VSYNC OFF tearlines).

Keep in mind that this is a refresh-cycle-granularity processor, not a frame-granularity processor. For many reasons, it has to process every refresh cycle independently of underlying framerates of the application running within the desktop on the virtualized display). Be noted, frame presenting timestamps do need to be made available to the shader run once every refresh-cycle (for certain shaders like VRR simulating shaders, which requires refresh cycle granularity processing while also separately knowing the frame presentation timestamps of the underlying application).

Except that it would work on everything in Windows, not just in a test. Reshade/SweetFX/SpecialK/etc does something similar in some ways, but not for many use cases. The other drivers have the problem of being frame-granularity (as frame Present() hooks) which means they are not refresh cycle granularity. Many algorithms need to process at Hz-granularity independently of the underlying frame rate, for successful operation. And being a Windows IDD, means desktop applications are included, not just games.

Note: MIT/Apache projects can be contributed to Microsoft in future PowerToys; so it's not mutually exclusive with becoming a PowerToy, with a limited sets of mainstream shaders (e.g. "ClearImage" as a method of ClearType 2). There is a large number of specialized and non-specialized use cases for such a flexible open source shader-plugin-capable Windows virtual display driver

IMPORTANT developer tip: One thing for Hz simulation/virtualization is that it only works well when in full screen exclusive mode. This prevents one display refresh rate from throttling the other display's refresh rate due to DWM compositor vsync. But full exclusive mode is fine for a display simulation driver which is displaying everyting full screen anyway.

commented

Alas, a lot of the other rendering issues aren't always easy to fix in software.

For example, the red/green fringing of yellow objects on white background on LG WOLEDs is an intrinsic hardware behavior that can't be fixed directly.

Very likely out-of-scope for this PowerToy; but it is one possible route of de-fringing an OLED via a software filter on top of everything, perhaps as a superscale-downsampler (e.g. running at 2x-3x resolution at 200%-300% DPI, and running it through a shader-based downscaler).

There may be an underlying issue with LG WOLED displays, since the added white subpixel messes with rendering, though on QD-OLED which is basically just RGB differently aligned this should not be an issue. Since there are RGB-Layout displays that don't have colored fringing on all objects (some do though), probably fixed by some hardware calibration for RGB already, the same should be possible with QD-OLED at least.

a subpixel-aware downscaler would allow everything to be "ClearType'd" including graphics, and not just text. This can even be done as a third-party Windows Indirect Display Driver, which I already offer a USD$2000.00 source code bounty for something under MIT or Apache.

This seems like a good idea for WOLED displays, but not really needed for QD-OLED perhaps. A downscale algorithm will always have a hit on performance which is why this does not seem like the best solution. Maybe an advanced algorithm can fix this in native, That would be a better solution if it could improve it a bit on WOLED, as well as fix it for QD-OLED. A display calibration in Windows like suggested would surely be a great feature that could possibly fix colored fringing even on some RGB displays.

I'm sorry for going off topic on this. I just want to throw this out there. I did some more thorough testing with nVidia DSR with WOLED (LG C2 with native resolution 2160p120). DSR actually does help improve the text asymmetry but may be doing too much smoothing. It certainly doesn't give what I would consider to be sharp text. Note that I have ClearType disabled for all of this and started with Windows UI scaling at 100%.

With Legacy DSR, the Smoothness function makes a significant difference. 100% is unusably blurry and 0% makes text look very "ugly". The default 33% seems generally good. I tested all the Legacy DSR scaling factors, and the 2.00X option at 33% produced the best effect to me.

With DLDSR, the Smoothness function has a very subtle effect if any, so I left it at default 33%. I tested all the DLDSR scaling factors, and the 2.25X option at 33% produced the best effect to me.

As far as DLDSR 2.25X vs Legacy DSR 2.00X at 33% smoothness, the DLDSR 2.25X text is slightly bolder/smoother.

The main benefit of this over ClearType and MacType is that it affects appearance of text everywhere, but I'm sure there are some pitfalls to using it.

There may be an underlying issue with LG WOLED displays, since the added white subpixel messes with rendering, though on QD-OLED which is basically just RGB differently aligned this should not be an issue.

There's a thread on HardForum about this.

I know why the color fringing is happening with yellows... I need to point out that the problem with red/green fringing is because it's an R-W-B-G system, where B and G is swapped when W pixel is added <-- THIS.

The R color is far away from G, which creates the fringing.

image

image

image

There are potential solutions that are being looked into, by half-pixel shifting the processing, where [RWBG][RWBG][RWBG][RWBG][RWBG] becomes RW][BGRW][BGRW][BGRW][BGRW][BG .... In this case, it becomes largely BGR ClearType compatible while eliminating the color-fringing involved with yellows (because the brightest primary colors R and G stays together).

The pixel structure was designed in the television era, and there's even a peer reviewed paper explaining why they chose the structure. However, it's not ideal for computer graphics use.

Some day, some time, I wonder if some big shot from Microsoft will look back at this issue and think: "How did this happen?"

I urge any Microsoft employee that is reading this to take this issue seriously, don't wait for LG CTO to have to call Microsoft CTO to complain that this issue is preventing them from selling monitors and advance the technology for millions of consumers. Don't wait for that call, be proactive, or else they will look back and ask, "How did this happen?", and will want to point fingers. If you don't have the necessary expertise, escalate this issue. If the person you escalate this issue to ignores it, escalate to his superior. Do the right thing, make a noise. This is unnaceptable and the whole industry is watching.

The mere fact that someone as technical as @mdrejhon has to beg to be heard is shameful, honestly.

I purchased the LG 45GR95QE-B and spent about 8 hours total traveling down a rabbit hole before finding this issue. I can rest now. It can be fixed in software.

I can see text is noticeably better when plugging my monitor in to my MacBook Pro versus Windows. What does MacOS do that Windows doesn't?

Either way, have a thumbs up. Thank you so much for raising this issue in such detail.

I purchased the LG 45GR95QE-B and spent about 8 hours total traveling down a rabbit hole before finding this issue. I can rest now. It can be fixed in software.

I can see text is noticeably better when plugging my monitor in to my MacBook Pro versus Windows. What does MacOS do that Windows doesn't?

Either way, have a thumbs up. Thank you so much for raising this issue in such detail.

MacOS uses grayscale rendering and it doesn't do sub pixel rendering at all. Some newer Windows apps like Windows Terminal do this too.

commented

upvote this!!!

Hopefully Microsoft will address and resolve this issue in Windows 11. This problem has persisted for years, as evidenced by this example from 2021 https://www.youtube.com/watch?v=ntwiDrQcUv4

thanks everyone for providing such a great detail in this thread.

Would love to see this properly addressed/fixed.

Would also love to see this addressed. WRGB OLED panels are everywhere now and the text looks terrible. Looks nice on my Mac, but I primarily use Windows. Let's get this fixed in Windows 11!

Asus PG42UQ gist

With WRGB panels, this is probably unsolvable on software level due to white subpixel unpredictably/uncontrollably coming into effect at higher brightness. A potential option for WRGB displays would be a hardware True-RGB mode with white subpixels turned off.

Suggested this for Dough QHD OLED monitor.

A fix is needed

With WRGB panels, this is probably unsolvable on software level due to white subpixel unpredictably/uncontrollably coming into effect at higher brightness.

There were some internal tests done, and there were still improvements with software algorithms (read some of the posts I made above).

So it's partially/mostly solvable at the software level, in that the artifacts by tolerating the white subpixel autonomous behavior, was confirmed to not cancel out the artifact-redutions of doing some software mitigations.

Such as the RBG ClearType simulation -- see successful PhotoShop image above.

If this was an unsolvable problem in software, text clarity would** be an issue in video games or other software that doesn't use ClearType. In my experience on the LG45" Ultrawide OLED with a white sub pixel, there are 0 issues rendering text in game and outside of windows / chrome, for whatever that's worth.

I think fundamentally a problem caused by software surely must be solvable in software.

This has to be a solvable problem - text on my PG42UQ looks great on my M1 Mac Mini, but not-so-great on my Windows 11 PC.

Please fix this! Just got the Samsung Odyssey OLED G9 and this is destroying the experience.

Maybe a little off-topic, but I've got an LG 27GR95QE-B monitor which has RWBG layout and can confirm that texts are fine on Macs. However, I am still getting that green and red fringe on left and right side of yellow shapes.

Seems like this is not 100% ClearType or Microsoft's fault although a ClearType fix would be useful still.

@eisenb11 @ionizer
Afaik, macOS does not use subpixel text antialiasing for years and uses simple grayscale antialiasing instead.

@Marat-Tanalin Yeah, you may be correct on that - but all I know is that my Mac looks better on my OLED than Windows does! :)

please fix it. it's hilarious this is looking so bad on windows 11

Started a return on my new g9 OLED because of this. Makes it unusable for anything other than gaming.

Yeah, definitely a problem.

As an interim quick fix before a long-term subpixel-aware option (e.g. ClearType 2 incubated as a PowerToy) -- maybe the Microsoft display engineering team might want to investigate:

(A) An improved greyscale mode or an adjustable greyscale mode (adjustable gamma-correction in the antialiasing, adjustable antialiasing-vs-nonAA intensity, etc); and

(B) Improved monitor driver format (INF files) that inform whether the display is RGB, is BGR, or is a nonstandard pixel structure.

That way, Windows automatically can turn off ClearType whenever it is detected to degrade (rather than improve) text clarity.

I have the OLED G9 now... it sad how bad the text is. But the issue is the same on images for mee that contain texts. tried many screen shoots from friends on my OLED G9 and also tested it on my old one and there was big differences :(

So will clear type 2 fix it when images also get bad text?

@jnormen image rendering isn’t the same as text rendering, cleartype would have no effect on that.

@jnormen image rendering isn’t the same as text rendering, cleartype would have no effect on that.

I know, but still I got the same problem with text in images as with text in apps.

For me text in mails, webpages, pdf files etc. are all messy some lines are thicker then others etc...
Exactly the same happens with text images for me. So if I take a screen shoot of my mail and save it as an image it looks the same as when read the raw text... If I take a look at the image on another screens it looks good.

So nerveless it's image or not the text looks bad.

Sadly I cant take a photo of it because my camera blur the image.

in a screenshot (especially png without compression) if you look at it 1:1 scale the clear type rendering is included as shown with the example in the second post

@Julianus43 It would only work if someone took a screenshot on a WRGB display with clear type 2 and then displayed it on another WRGB display. If they were to take a screenshot on a RGB display, it won’t be fixed by clear type 2 when viewed on a WRGB display because the sub pixel rendering isn’t going to change on an image from device to device.

I wonder if I have the same issue as others with my OLED G9.
I do not notice any blurry text, not green or red lines around the text. What happens for me is that some lines on the text are thicker than others. Also more pixelized text. So for me the text looks more "formatted" wrong.

For example number 00771 make the 1 look fat but 0077 looks almost normal but kind of thinner then normal.

The first line in many "M" chars can be thin but the two other are thicker etc... so the chars differ in line shapes.

I do not notice any blurry text, not green or red lines around the text. What happens for me is that some lines on the text are thicker than others. Also more pixelized text. So for me the text looks more "formatted" wrong.

Yep, that's the issue.

commented

Still dead silence from Microsoft

@jnormen Line-width variability may be a result of an OS-level zoom between 100% and 200%, like 150%. This usually doesn’t happen at 100%, and is usually not noticeable at 200%, regardless of ClearType.

Still dead silence from Microsoft

I ended up chatting with one of the two developers who own the actual sub-pixel rendering experience that is utilized by ClearType. This article explains the high-level details of the technology. At this point, it is quite old. The reasons I stopped digging further than this was:

  • I'm just a dev on a completely unrelated team (though I'm an OLED user myself and would love to determine a fix)
  • The current ClearType implementation doesn't seem suitable to fix this issue
    • The low-level APIs don't support anything that would be necessary here (like a W sub-pixel or custom arrangements that aren't horizontal)
  • I no longer think of this issue has being related to PowerToys/ClearType
    • This is something more fundamental and I have no idea what direction to go
    • ClearType was created to solve a certain problem (CRT -> LCD), and it is not a wholistic solution that applies to this problem
  • No longer sure who or what team would even be interested in solving this

In my opinion, the problem seems more than just 'text rendering'. Given that, I don't think it is necessarily the OS's responsibility to add this kind of "sub-pixel anti-aliasing" (I know it isn't exactly that, but it is conceptually how I think about it). Additionally, the ClearType dev also let me know that the technology they have doesn't work if the monitor is in portrait mode, which makes sense since it isn't aware of the monitor's physicality from a text rendering standpoint. At this point, the likely best implementor would be something at the driver-level for video cards. Something where they're aware of:

  • Monitor type (at least basic information)
    • Still would need to solve who/where the sub-pixel information comes from
  • Monitor orientation
  • Access to the entire render-state (independent of text or not)

GPU manufacturers do use some techniques like this already. I've personally used AMD's VSR before. It had it's own issues but worked for my use-case.

Anyway, this is just my 2-cents. I still enjoy seeing the conversation take place here, but I don't foresee the problem being solved via PowerToys/ClearType, unfortunately. I think there would need to be, you know, some panel manufacturer to throw their weight around to try to get some company to make a change. But trying to do this from the bottom-up does not seem to be the way. 😢

commented

In my opinion, the problem seems more than just 'text rendering'. Given that, I don't think it is necessarily the OS's responsibility to add this kind of "sub-pixel anti-aliasing"

Yeah thats kind of what i said in my post. Its definitely affecting more than just text. In this image from the first article mentioning this issue on the Alienware QD-OLED, you can clearly see this affects window edges as well. I saw similar behaviour on many LCD displays too! I feel like people never mention that this issue exists on LCD (RGB Layout) at all which I dont understand.
Bunte_Kanten-38453fbcebf9e4d9

Its clear that the monitor manufacturers need to fix this issue as far as possible first, via some sharpness calibration settings. When its possible to fix it on LCD, it must be possible to fix on OLED as well (on QD-OLED at least as mentioned in my other post). For W-OLED though there should definitely be a better grayscale text option in windows, to fix rendering at least in that scenario. I kind of think a general removal of colored text rendering could be a good step for the future. There are quiet a lot of applications that don't use colored text rendering anyway and this would just give more consistency.

If this is fundamentally unfixable in ClearType so be it, but I do not understand what's preventing windows from allowing grayscale rendering so, even if there are issues and artifacts in other areas, we can at least live in peace having parity with MacOS text clarity.

If this is fundamentally unfixable in ClearType so be it, but I do not understand what's preventing windows from allowing grayscale rendering so, even if there are issues and artifacts in other areas, we can at least live in peace having parity with MacOS text clarity.

There is a already a greyscale rendering mode in Windows (turn off ClearType) but it's not as high quality as MacType for Windows or connecting an Apple MacOS-based computer to the same monitor.

Yeah thats kind of what i said in my post. Its definitely affecting more than just text. In this image from the first article mentioning this issue on the Alienware QD-OLED, you can clearly see this affects window edges as well. I saw similar behaviour on many LCD displays too! I feel like people never mention that this issue exists on LCD (RGB Layout) at all which I dont understand.

image

Its clear that the monitor manufacturers need to fix this issue as far as possible first, via some sharpness calibration settings. When its possible to fix it on LCD, it must be possible to fix on OLED as well (on QD-OLED at least as mentioned in my other post). For W-OLED though there should definitely be a better grayscale text option in windows, to fix rendering at least in that scenario. I kind of think a general removal of colored text rendering could be a good step for the future. There are quiet a lot of applications that don't use colored text rendering anyway and this would just give more consistency.

As an alternative to ClearType-only rendering (ala ClearType 2 experiment or PowerToy etc)...

There could be an everything-filter that applies to the entire Windows desktop to make everything subpixel-clear regardless of graphics/text. This can be done by supersampling the resolution and downscaling the composited framebuffer in a subpixel-structure aware manner. Some phones already (sort) of do this, on a PenTile display, etc.

As a related initiative that should be done in parallel to deciding mitigations on this -- I think the monitor INF format should at least be upgraded in some form -- to automatically turn off the original ClearType (Which does look great for LCDs) whenever the monitor is not a standard RGB-subpixel or BGR-pixel format.

commented

As an alternative to ClearType-only rendering (ala ClearType 2 experiment or PowerToy etc)...

There could be an everything-filter that applies to the entire Windows desktop to make everything subpixel-clear regardless of graphics/text. This can be done by supersampling the resolution and downscaling the composited framebuffer in a subpixel-structure aware manner. Some phones already (sort) of do this, on a PenTile display, etc.

Since I know this behaviour happens on RGB-Layout displays as well (although maybe not as severe), I do think there should be a windows wide calibration that can be optimized on a per monitor basis. I don't think that a downscale alrgorithm is the correct solution though, but maybe I don't 100% understand what you mean by this. I think I mentioned this in my second post (which I can't find anymore) where I said that this would lead to performance reduction. Is that so or would I be wrong?

I feel like some form of monitor sharpness calibration would be able to dealw ith this as well. When I had my other LCD monitors I noticed that all had different out of the box sharpness and color fringing. Some looked good out of the box (sharp and no fringing) and some don't. Messing with the inbuilt sharpness calibration sort of dealt with the color fringing on many monitors but would made them look more blurry. I am sure either Microsoft or Nvidia could built something like this which has a subpixel aware rendering to fix this.

It's definitely clear that this has to be fixed by someone at least, seen by the amount of users this affects and it's a fact that ClearType is out of date and either needs a refresh or be removed. I definitely think though that colored text rendering on its own should to be removed. Grayscale text (that isn't as bad as the current Windows option) with a monitor wide calibration would be the ideal solution.

Since I know this behaviour happens on RGB-Layout displays as well (although maybe not as severe), I do think there should be a windows wide calibration that can be optimized on a per monitor basis. I don't think that a downscale alrgorithm is the correct solution though, but maybe I don't 100% understand what you mean by this. I think I mentioned this in my second post (which I can't find anymore) where I said that this would lead to performance reduction. Is that so or would I be wrong?

Remember the subpixel resolution of the display is much higher than the pixel resolution of the display, either by a factor of 2 (PenTile), factor of 3 (RGB, BGR, QD-OLED), or factor of 4 (LG WOLED).

Alternative to "ClearType 2": Subpixel-Process the Whole Screen

To take advantage of the spatial positions of the subpixels, in a content-independent way (text, images, lines, borders, graphics) there needs to be a higher spatial resolution to have something that clicks to the subpixel grid. Otherwise it doesn't scale in a sharper-than-native way. There could also be a Sharpness adjustment that blends between full subpixel and full non-subpixel -- to accomodate user preference.

The OS, of course, would have to do a proportional DPI zoom behavior (e.g. like 200% DPI zoom when supersampling by 2x horizontal and vertical resolution) to keep relative text sizes and window sizes unchanged.

In theory this can be done as a third party filter. Like an F.Lux / Night Light or other.

There are many workflows, with lots of pros/cons and limitations apiece -- including just coasting with the current status quo (which is worse).

BTW, about 20 years ago for Microsoft PocketPC, I did the subpixel-aware supersampling algorithm on images taken from a then-highend Sony 5 megapixel digital camera, and created some sample images. It was done by downscaling in a subpixel-spatials aware manner;

Reconfigure your Windows to 100% DPI and reconfigure your browser to 100% zoom, and view this on an RGB LCD:

These image demos are currently 20 years old as I created them when Microsoft first came out about ClearType, and I decided to test if they worked in sharpening images on my Compaq iPaq PocketPC hand helds in year 2001.

image

Published here for the first time, I never published these images publicly, but I privately ran a scaling algorithm on it (thanks to my video/image processing knowledge) back then.

1. Normal Downscaling

Normal scaling scaling for images:
Epcot_Normal Skyscrapers_Normal BrooklynBridge_Normal

2. ClearType-Style Image Downscaling for RGB-Stripe LCDs

View at 1:1, by setting Windows temporarily to 100% DPI and browser to 100% zoom.
ClearType-style scaling for images, meant to be viewed on RGB-stripe LCD:
Epcot_ClearTyped_Smart Skyscrapers_ClearTyped BrooklynBridge_ClearTyped

IMPORTANT: Do not view above images on a smartphone/tablet. For viewing these demonstration images, view on a common sub-100dpi display such as a common 1080p office LCD in landscape mode, and set OS DPI to 100% and browser zoom to 100%. So it looks sharper (to 20/20 vision) than Normal Sampling on RGB-stripe LCDs such as common 1080p office computer monitors. Once DPI and zooms are configured correctly, (2) suddenly looks sharper than (1)

Once 1:1 pixel mapped correctly, then on low-resolution PocketPCs such as Compaq iPaq, it noticeably sharpened the images, especially those with lots of fine lines in them.

If you open these images in a photo app, you will see the ClearType-style pixel blending I applied to the images during a downsampling filter.

Also, I experimented with an alphablend between the (1) Normal and a fully color-fringy (2) ClearType-Image (ClearImage?), as an experimental sharpness adjustment, and chose a preference, so what you see in item (2) item is already a very slight blend between full-on color-fringy ClearType and zero-subpixel-aware. It might make difference between (1) and (2) a bit more subtle, but it was a good compromise for showing off slightly sharper images on my PocketPC PDAs in the early 2000s which had 320x240 screens in RGB-stripe format. Some people may not like the blending setting I used, but it certainly improved the fine detail of fine vertical/horizontal lines in photographs (when viewed 1:1 exact on a low-DPI RGB-stripe LCD);

However, this would have to be done at the display-resolution-aware and display-structure-aware manner (Monitor INF file extension) -- with the system screenshotting system toggleable between display-independent vs display-specific scaling.

This is another approach (already done in the display scaler of some PenTile smartphones), that most certainly can be applied to the Windows OS level, as a filter. But ideally, discovery of the displays' own pixel structure (such as via upgraded Monitor INF files for computer monitors), would be an important "missing piece" of the puzzle.

I'm just mentioning this as an alternate approach that affects all graphics (not just text). When using a global-image algorithm, ClearType should be disabled at the text level, so that the global screen scaling takes over ClearType duties instead.

Now if monitor INF files could be extended to make subpixel structure discoverable by OS or apps...

This might be a good first step. At the minimum, to automatically disable ClearType for non RGB/BGR displays -- solving most complaints (even if not all). Many users will complain if ClearType is unceremoniously turned off on them globally via a Windows Update or Windows reinstall, because of the giant number of RGB LCDs on the market. But with the boom of RGB/BGR displays, better discovery should be provided to improve plug and play user experience.

Then later on -- any "ClearType" style approach can be done by Microsoft or done by third party
-- Whether a PowerToy (text renderer or desktop filter)
-- Or third party

A generic third party (PowerToy style app) full-screen downscaler filter for all desktop content (text + images) can be produced to accomodate practically any subpixel structure, if the OS could discover the subpixel structure of the display itself. For 1920x1080 displays at 100% DPI zoom, the desktop would be internally rendered as 3840x2160 at 200% DPI zoom or 5760x3240 and piped through the subpixel-aware downscaler. In fact, even 4K videos would become sharper on a 1920x1080 display too, when piped through a subpixel-structure-aware downscaler.

Today's fast GPU shaders can scale every DWM composited refresh cycle in less than a millisecond, so while this increases processing overhead, it's extremely fast in a GPU shader.

The global method is a bit brute overkill but reduces/solves fringing for all graphics, and not altogether that efficient, but would be a universal approach optionally activated by users who want the extra screen clarity.

It's definitely clear that this has to be fixed by someone at least, seen by the amount of users this affects and it's a fact that ClearType is out of date and either needs a refresh or be removed. I definitely think though that colored text rendering on its own should to be removed. Grayscale text (that isn't as bad as the current Windows option) with a monitor wide calibration would be the "logically ideal" default generic solution, even if not the ultimate clearest/sharpest for all.

Fixed that for you.

For user friendliness (in the abscence of monitor INF files), it could become default from now on for new OS installs. But, better yet is to improve the monitor INF file to improve discovery for non-RGB/non-BGR displays -- as long as greyscale rendering is improved to match the Mac quality crispness.

The current Windows greyscale text mode is worse than the Mac native version or the MacType-for-Windows implementation (even with its subpixel render mode disabled). Also, ClearType RGB is enabled by default when you install and run Windows, and that conflicts with the boom of non-RGB displays. At the minimum, the Monitor .INF file should be extended to include subpixel--structure information -- at least for no other reason than to automatically disable ClearType on displays that aren't RGB/BGR stripe -- and to make it easier for third party coders to do subpixel-aware scaling/text/filters.

It's a user preference matter. A lot of us was picky in year 2003, and a lot of us still are.

@mdrejhon I understand it's not just text but also borders and other straight and thin lines. That the real cause is the way the pixels are positioned in the display and that there are actually OLED displays that do use the "normal" RGB positoning.

Why are display(panel) manufactures changing the positioning?

@mdrejhon I understand it's not just text but also borders and other straight and thin lines. That the real cause is the way the pixels are positioned in the display and that there are actually OLED displays that do use the "normal" RGB positoning.

Why are display(panel) manufactures changing the positioning?

This is a separate problem, really. Similar things happen with RGB although perhaps to a lesser degree because there's no white sub pixel. For example: http://www.lagom.nl/lcd-test/subpixel.php

The problem here is that ClearType actively makes text much worse than well rendered grayscale (e.g. UWP apps).