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

[mdrejhon]

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.

[mdrejhon]

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:

...and...

BGR:

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

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.

(...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:

Actual macro photograph of a Samsung QD-OLED:

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

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:

[mdrejhon]

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)

[Jason-GitH]

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

[mdrejhon]

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

[mdrejhon]

To Microsoft Employees:

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

[Jay-o-Way]

@crutkas this guy should be working for Microsoft

[Jay-o-Way]

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

[mdrejhon]

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

[mdrejhon]

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

[mdrejhon]

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)

[mdrejhon]

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

• https://aka.ms/AAkkj6j -- "ClearType support for Alienware AW3423DW monitor" (19 upvote)
• https://aka.ms/AAkkqvy -- "ClearType subpixel Text blurry in my new QD OLED monitor" (7 upvote)
• https://aka.ms/AAkk3vt -- "qd-oled cleartype support" (3 upvote)
• https://aka.ms/AAkkyhv -- "Cleartype support for abnormal pixel layouts." (24 upvotes)
• https://aka.ms/AAkkbky -- "Update ClearType for Triangle or Diamond Subpixel Layouts" (10 upvotes)
• https://aka.ms/AAkkbky -- "ClearType text on QD OLED displays has fringing" (35 upvotes)
• https://aka.ms/AAjorgl -- "Update ClearType to include QD-OLED subpixel layouts" (31 upvotes)
• https://aka.ms/AAkl0uq -- "Pixel rendering looks terrible on OLED Monitors" (5 upvotes)
• https://aka.ms/AAkklkn -- "Add subpixel rendering support for triangular QD-OLED subpixel layout to ClearType" (6 upvotes)
• https://aka.ms/AAkl0v4 -- "Color fringing on text with QD-OLED monitor" (25 upvotes)
• https://aka.ms/AAgkmhk -- "Improve subpixel rendering for WRGB WOLED and RGB QD-OLED displays to eliminate chromatic aberration" (24 upvotes)

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.

[mdrejhon]

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

We'll push that front, too.

[Jason-GitH]

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.

[mdrejhon]

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.

[mdrejhon]

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:

• ASUS 27" desktop ROG Swift OLED PG27AWDM (shipping 2023)
• LG 27" desktop UltraGear OLED model 27GR95QE-B (now shipping)
• LG 45" ultrawide desktop UltraGear OLED model 45GR95QE (now shipping)
• Corsair 45" ultrawide desktop Xeneon Flex model 45WQHD240 (shipping 2Q 2023)
• Dough 27" desktop Eve Spectrum OLED (shipping 2023)
• Acer 27" desktop Predator X27U (shipping 2023)
• Acer 45" ultrawide desktop Predator X45 (shipping 2023)
• MSI ultrawide desktop 491C QD-OLED (shipping 2023)

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.

[mdrejhon]

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.

[mdrejhon]

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

Test image for triangular-subpixel QD-OLED displays

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"

[Jason-GitH]

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.

[vaisest]

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.

[Jason-GitH]

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.

[mdrejhon]

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.

[bizude]

Thank you for bringing attention to this issue.

[mdrejhon]

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.

[danweast]

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.

[mdrejhon]

Possible Existing Defacto Standard Configuration Format for Subpixel Layouts?

Standardizing a configuration method for custom subpixel structures is great for the industry (including possibly, of course, for Microsoft later on). It's a really interesting idea to standardize a subpixel definition system.

I would like to point out ongoing potential "custom subpixel layout standards" that are currently ongoing:

• MacType: The "PixelLayout" line in MacType INI file. (Example)
• FreeType: The FREETYPE_CUSTOM_GOMETRY in rennr's fork of FreeType (Example)

Example that looks good on QD-OLED for MacType and FreeType respectively:

PixelLayout=-21,-16,0,16,21,-16

FREETYPE_CUSTOM_GEOMETRY=-21,-16,0,16,21,-16

They are simply three X,Y coordinates of the subpixel-centers of the subpixel colors within a 64x64 grid ranged from [-32,-32] thru [32,32], in Rx,Ry, Gx,Gy, Bx,By format. And it already seems the two projects (MacType and FreeType) have kind of adopted the same simple subpixel-center method of defining custom subpixel structures. It might not be enough, given the various sizes and shapes of subpixels, but as a commonalty being used by two different font projects, it might also (theoretically) be a potential standard too.

@osor-io -- your standard seems better and more flexible, though also makes the assumption of rectangular subpixels. At that stage, might as well use the existing pixel-center approach for sheer simplicity? On the other hand, awareness of where the rectangles are in various odd structures (e.g. PenTile) still makes a further improvement.

The pros/cons will need to be thought out, in a K.I.S.S. point of view.

Theoretically -- it would be nice to just macro photograph the subpixel structure of a display and give it to the configuration to automatically create the structure (possibly with a bit of AI help). But this approach can still be done with the subpixel-center approach, too, via the creation of an intermediate utility to convert subpixel structure into a configuration line.

[osor-io]

That's interesting, I wasn't aware of those approaches, certainly seems like a good direction to go in. If a precise specification were to happen at some point it might be good to err on the side of specificity. It could give more freedom to display manufacturers and avoid unforeseen issues with future panels (very irregular subpixel elements, non-RGB subpixels, etc.)

That said, I totally agree on keeping this as simple as it can be. Ideally manufacturers would chime in and give input towards a standard that can represent their current and future technologes effectively while still being relatively simple.

The subpixel center approach used by FreeType (MacType looks like it uses FreeType under the hood?) is interesting, I imagine it would model them internally as a circle, or perhaps some sort of standard gaussian function. One worry I'd have with only having pixel centers would be that it would either not work great with very elongated subpixel elements, or if it became standard, discourage manufacturers from pursuing arrangements that wouldn't be well represented with it.

An example can be the Apple Watch layout (image from Jonesblog)

Although if it's more useful to represent pixel centers, we could have a format similar to the previous example but that gives you the 2D coordinate of the subpixel center, then followed by its extents (e.g. width and height for rectangular shapes). Both approaches represent the same data really.

If I had to guess, an approach with rectangles/quads as the primitives might be enough instead of having to support extra shapes, given that the pixel-center-only approach is working to some people's satisfaction. The quad approach is essentially only expanding the center-only approach to account for non-uniform shapes like the one on the picture. But I'm not familiar enough with the ins and outs of subpixel light emission to claim this to be the case.

As a separate note, I also agree with @MattBDev that this should live in the OS/monitor-driver realm. But this is the only place I saw with well informed and interesting discussion about the topic. If you think this should also be posted/discussed elsewhere let me know.

Thanks @mdrejhon! 😄

[sava41]

I made a small demo app specifically to fix qd oled triangle subpixel fringe here https://github.com/sava41/qdoled-defringe.

This can be generalized to other subpixel layouts but would have to be tuned on a per-layout basis.

This app uses the screenwide shader/filter approach suggested by @mdrejhon so it works an all ui elements, not just text .

[Avamander]

I've tested the filter and it does reduce fringe really nicely, but it does make text look blurry. Definitely promising.

[albertvaka]

I don't think this is bug for PowerToys to fix, it should be fixed in Windows itself.

[mdrejhon]

I don't think this is bug for PowerToys to fix, it should be fixed in Windows itself.

Ideally.

That being said, two decades ago for Windows XP, Microsoft ClearType Tuner PowerToy (WayBack Machine, Internet Archive, 2004) was originally incubated as a Windows PowerToy.

So this is exactly why this github entry was created, right here, on PowerToy github.

An enhanced OLED-specific ClearType Tuner can be incubated, in theory, as a PowerToy, before being released to the masses.

After I poste this github item, the community continued tweaking (and pointed out) the previously posted open source projects (FreeType-engine-based) that is apparently now successfully ClearTyping both LG WOLED and Samsung QD-OLED.

But a lot of software stubbornly continues to use the ClearType engine instead of globally. So a lot of tweaking is needed to force as much of Windows as possible, to use the open source subpixel-renderers.

And we need improved subpixel structure discoverability in monitor drivers (e.g. enhancement/extension to monitor INF files). That part, indeed, may need to be incubated directly in the Windows OS, but that is not mutually exclusive to having a tweaking utility being incubated PowerToys-side.

[kocho1984]

Does problem with OLED displays occur also in macOS?

[rajkosto]

I feel like this issue is focusing too much on QD-OLED and defining complex arbitrary subpixel layouts
when to fix WOLED all that would be needed, is other than having a RGB and BGR mode, also have a RBG (for woled) mode, the rendering method can then stay exactly the same (render 3 grayscale pixels), only the code for combining the 3 grayscale pixels into 1 RGB pixel would need a few lines added to it (everywhere it supports RGB->BGR swap, it can also support RGB->RBG partial swap).

[pbaykalov]

when to fix WOLED all that would be needed

Fixing one case is useless. OLEDs are gaining popularity and most popular PC OS in the world must support all kinds of displays in one of the most important usage scenarios - displaying text. It's not hard at all.

[joelspadin]

Why not both? Assuming it is much easier to make ClearType support different orders of subpixels in the layout it already supports than to support arbitrary subpixel layouts, then why not make the easier change now and start working on the harder one afterwards?

Fixing one case is useless.

Not for everyone who has a monitor that matches that case.

It's not hard at all.

I have no idea what the ClearType codebase looks like, but as someone who regularly has to deal with ancient code at work, I think that's a pretty bold claim. 😄

[Marat-Tanalin]

Covering one case is better than covering no cases at all. Implementing support for different subpixel order is potentially much simpler than inventing a new algorithm for arbitrary subpixel layouts.

[romen-h]

IIRC ClearType doesn't account for portrait orientation either so the solution proposed above for defining any subpixel geometry also allows vertical monitor users to use a rotated RGB layout too. I believe that would be a pretty large userbase to consider implementing the support for that alone, and QD-OLED users will get their fix with it too.

[mdrejhon]

IIRC ClearType doesn't account for portrait orientation either so the solution [proposed above]

IIRC, ClearType worked in portrait orientation on some mobile screens. It was implemented for certain mobile LCDs, way back in the Windows Mobile days. So, while I am not sure of desktop support, there's prior arts of ClearType supporting portrait-mode.

Covering one case is better than covering no cases at all. Implementing support for different subpixel order is potentially much simpler than inventing a new algorithm for arbitrary subpixel layouts.

While this is tempting; I recommend to stakeholders: Do not weaksauce it

A very simple/forked modification to MacType/FreeType already supports arbitrary subpixel layouts, as seen in earlier suggestions. Github links in earlier comments.

There's already prior arts. And there's too many odd subpixel layouts, for various engineering reasons (e.g. wearlevelling of different color components, etc) that has created OLED subpixel modifications for longevity / brightness sake. It's a real interesting set of interacting engineering compromises that will likely continue.

[CxLynx]

Does problem with OLED displays occur also in macOS?

AFAIK the last macOS version to have subpixel antialiasing support was High Sierra (released 2017). It was completely removed in Mojave and it's all greyscale since then, not sure about iOS/iPadOS/watchOS etc.
Reason I saw usually cited being that all Macs (and Apple products in general) on the market have very high PPI displays and maintaining subpixel antialiasing was more trouble than it's worth.

[mikkorantalainen]

• 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
• Cache the resulting downsampled bitmap (for faster run at step 1)
• 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).

Unfortunately, the algorithm cannot be this simple. Things that this algorithm would miss:

• High quality text rendering requires subpixel positioning of letters. For example, FreeType on Linux/Android can start the letter on any subpixel for higher quality kerning so you would need three variants of each letter per pixel size and choose the correct image depending on the subpixel you want to start with. In addition, modern text rendering supports fractinal font sizes so your font size can be any value between 15px and 16px. As a result, you would need to cache 15.35px size font, too. Again, in 3 different sizes.
• High quality antialising requires that you do not simply multiply the pixel values when you overlay the pre-rendered glymphs but convert the pixels to linear colorspace, multiply the pixels and then convert back to correct gamma ramp. If you do all this with integer values, resulting image quality will suffer because of rounding errors in each step. On the other hand, converting between integers and floating point numbers for every pixel requires a lot of computation. Definitely doable on GPU, might be too slow to run on CPU.
• You need different prerendered glymphs on dark backgrounds vs light backgrounds. And you have to use additive rendering instead of multiplying values together on dark backgrounds. And sometimes the background colors are not yet known by the time you would need to render the glymphs. For example, Google Chrome and Firefox solve this issue by switching to greyscale antialiasing unless the background color is definitely known.

As a result, writing high quality implementation is a huge task and there's much easier solution that seems more pleasing for the manufacturers: just sell higher resolution displays and use greyscale antialiasing for everything forget about subpixels. This is the solution that Apple uses with their high resolution monitors and all Android software is going this way, too.

The reason you would want 8K monitor is not that movies would look better. You want 8K so that you can use simple greyscale antialias and still end up with sharp looking text. And for smaller screen sizes (anything smaller than 32" at 8K) you probably want to disable any kind of antialiasing to get even sharper looking results and can avoid all the gamma ramp errors when you blend antialiased letters without using linear colorspace in between.

Selling higher resolution monitors seems like the best solution for all the vendors: you can sell more expensive monitors and the software is easier to develop. It's not that nice for the consumers that now have to purchase the more expensive high resolution monitor + beefy enough GPU to run with without latency but consumers are there to pay for the stuff, not to get a pleasing cheap solution.

[kocho1984]

Why doesn't the problem occur on AMOLED displays? Fonts on Android and Apple devices (iPhones and iPads) with AMOLED displays look perfectly.

[Marat-Tanalin]

@kocho1984 High pixel density.

[pbaykalov]

• High quality antialising requires that you do not simply multiply the pixel values when you overlay the pre-rendered glymphs but convert the pixels to linear colorspace, multiply the pixels and then convert back to correct gamma ramp

1. Why is such a conversion used? Would it not be better to multiply and then correct the result once? I know there's sRGB linear ramp but that can be dealt with easily too.
2. Is it really as significant as subpixel structure awareness?

[mdrejhon]

Why doesn't the problem occur on AMOLED displays? Fonts on Android and Apple devices (iPhones and iPads) with AMOLED displays look perfectly.

@kocho1984 High pixel density.

Not only that,

AMOLED Android phones use subpixel rendering on their structures (Pentile).

That's part of why OpenType gained a bunch of subpixel rendering modes; and is why Linux FreeType/OpenType currently has a subpixel structure text-file configuration line, which is otherwise not well documented.

Sometimes this is at compile time, but other times as a editable configuration line -- called "AntiAliasMode=" and "PixelLayout=" in the MacType-for-Windows fork of FreeType at www.mactype.net

The other technique is supersampling, where you render at a higher resolution than the screen resolution, and do a subpixel-aware downscale to the AMOLED screen.

While not all AMOLED screens are PenTile structure based, most PenTile scaler/tcons (the chip driving the LCD directly) use this technique. This technique is compatible with greyscale antialiasing (done on the original excess-resolution framebuffer) before the subpixel-aware scale-to-pixel-structure.

[Zetsubou-Sensei]

To anyone that is still struggling with text clarity and hasn't seen @dxzdxz1's comment above on ExplorerMicaBlur version 1.07, check it out.

Dxzdxz1 found that that using the older version of the ExplorerBlurMica tool allows text to be rendered perfectly on OLED machines! I reformatted my computer last week and installed the ExplorerMicaBlur modification (v1.07) and have not had to change anything else on my CO49DQ for text clarity.

No fiddling with ClearType, no MacType. Just ExplorerBlurMica. I don't know why this works, so hopefully you all smarter than me can help work with the team at ExplorerBlurMica to get a solution for us all :)

P.S. I am new to GitHub so I apologize for not understanding how to properly tag people and also if posting like this is not allowed on this comment thread. Please delete this message if it breaks the rules here.

[Scope666]

To anyone that is still struggling with text clarity and hasn't seen @dxzdxz1's comment above on ExplorerMicaBlur version 1.07, check it out.

Dxzdxz1 found that that using the older version of the ExplorerBlurMica tool allows text to be rendered perfectly on OLED machines! I reformatted my computer last week and installed the ExplorerMicaBlur modification (v1.07) and have not had to change anything else on my CO49DQ for text clarity.

No fiddling with ClearType, no MacType. Just ExplorerBlurMica. I don't know why this works, so hopefully you all smarter than me can help work with the team at ExplorerBlurMica to get a solution for us all :)

P.S. I am new to GitHub so I apologize for not understanding how to properly tag people and also if posting like this is not allowed on this comment thread. Please delete this message if it breaks the rules here.

Definitely going to check that out, but what about something like a web browser ... Chrome for example ... does it help there?

[stanio]

font_rendering.cleartype_params.cleartype_level = 0 with Firefox is working for me.

[stanio]

The following Registry tweak appears to trigger grayscale anti-aliasing in most of the rest of Windows:

• Enable grayscale font anti-aliasing in Windows 10+ (r/windows)

One needs to log off and log in for the changes to take effect. I'm still seeing ClearType anti-aliasing in native tooltips, though.

[rajkosto]

The following Registry tweak appears to trigger grayscale anti-aliasing in most of the rest of Windows:

• Enable grayscale font anti-aliasing in Windows 10+ (r/windows)

One needs to log off and log in for the changes to take effect. I'm still seeing ClearType anti-aliasing in native tooltips, though.

this is exactly the same as opening Cleartype Tuner and picking the "grayscale antialiasing" option, which changes the font rendering mode and is NOT the same as just having all the subpixels be grayscale... it makes a lot of glyphs either too lanky or too thick, their width is inconsistent, so i would not recommend it
also some applications that render text on their own (like Firefox) will read this registry setting meaning you wanted grayscale antialiasing, and will just disable font smoothing on some fonts entirely
it's better to just tweak Firefox to use grayscale antialiasing manually : gfx.font_rendering.cleartype_params.cleartype_level in Firefox about:config, --disable-lcd-text cmdline option for Chrome

[Jason-GitH]

To anyone that is still struggling with text clarity and hasn't seen @dxzdxz1's comment above on ExplorerMicaBlur version 1.07, check it out.

Dxzdxz1 found that that using the older version of the ExplorerBlurMica tool allows text to be rendered perfectly on OLED machines! I reformatted my computer last week and installed the ExplorerMicaBlur modification (v1.07) and have not had to change anything else on my CO49DQ for text clarity.

No fiddling with ClearType, no MacType. Just ExplorerBlurMica. I don't know why this works, so hopefully you all smarter than me can help work with the team at ExplorerBlurMica to get a solution for us all :)

P.S. I am new to GitHub so I apologize for not understanding how to properly tag people and also if posting like this is not allowed on this comment thread. Please delete this message if it breaks the rules here.

I tried this out. It's okay but the text is uneven appearing similar to having font smoothing disabled, although not as drastic. A good solution in my opinion would be to have similar font rendering as is used in some programs such as NVIDIA Control Panel. I heard this was called bitmap fonts? The text appears perfectly sharp with no fringing on my LG C2 (ClearType disabled). Although it doesn't have the modern bold smooth font appearance people like, it is something to consider.

[dxzdxz1]

To anyone that is still struggling with text clarity and hasn't seen @dxzdxz1's comment above on ExplorerMicaBlur version 1.07, check it out.

Dxzdxz1 found that that using the older version of the ExplorerBlurMica tool allows text to be rendered perfectly on OLED machines! I reformatted my computer last week and installed the ExplorerMicaBlur modification (v1.07) and have not had to change anything else on my CO49DQ for text clarity.

No fiddling with ClearType, no MacType. Just ExplorerBlurMica. I don't know why this works, so hopefully you all smarter than me can help work with the team at ExplorerBlurMica to get a solution for us all :)

P.S. I am new to GitHub so I apologize for not understanding how to properly tag people and also if posting like this is not allowed on this comment thread. Please delete this message if it breaks the rules here.

Thanks for mentioning my findings @Zetsubou-Sensei, I hope one day we get something like this system-wide through Windows itself

For anyone wondering: This only changes the font rendering on explorer, nothing else. ExplorerBlurMica doesn't touch anything outside explorer.exe

Again, ExplorerBlurMica doesn't affect any other program except Explorer.exe. If anyone is trying and seeing difference in other apps, this is something related to other things you guys are changing, since ExplorerBlurMica only loads it's dll on explorer.exe

It's better than nothing, but isn't a solution

[Jason-GitH]

Going off what I said previously, there is a way to get sharp text in Windows Explorer by forcing Windows to use Tahoma font by following the steps described here: https://www.howtogeek.com/716407/how-to-change-the-default-system-font-on-windows-10/#how-to-change-the-default-system-font-using-registry-editor. Tahoma was the default Windows font prior to Windows 8. I will summarize the steps below. I think the ability to change the Windows OS font may be a more feasible/simpler project for PowerToys than changing the subpixel rendering. At least for WOLED, some fonts can appear very crisp. I do not have a QD-OLED to test.

Here is my Windows Explorer with Tahoma font forced via registry with ClearType disabled. You can see the text areas in main windows are very sharp but there is still some boldening applied to title bar.

To force Windows OS to use any font you like:
-Step 1: Backup registry.

-Step 2: Install and/or choose a font you like. Identify the font name by going to Settings > Personalization > Fonts. Tahoma is available at default.

-Step 3: Paste the following into Notepad and change "NEW-FONT" to your "FONTNAME" (e.g., Tahoma):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts]
"Segoe UI (TrueType)"=""
"Segoe UI Bold (TrueType)"=""
"Segoe UI Bold Italic (TrueType)"=""
"Segoe UI Italic (TrueType)"=""
"Segoe UI Light (TrueType)"=""
"Segoe UI Semibold (TrueType)"=""
"Segoe UI Symbol (TrueType)"=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]
"Segoe UI"="NEW-FONT"

-Step 4: Save file as *.reg.
-Step 5: Right click and select Merge. Restart PC.

To revert back to default OS font (Segoe UI):
-Step 1: Create a new Notepad file using the following:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts]
"Segoe UI (TrueType)"="segoeui.ttf"
"Segoe UI Black (TrueType)"="seguibl.ttf"
"Segoe UI Black Italic (TrueType)"="seguibli.ttf"
"Segoe UI Bold (TrueType)"="segoeuib.ttf"
"Segoe UI Bold Italic (TrueType)"="segoeuiz.ttf"
"Segoe UI Emoji (TrueType)"="seguiemj.ttf"
"Segoe UI Historic (TrueType)"="seguihis.ttf"
"Segoe UI Italic (TrueType)"="segoeuii.ttf""Segoe UI Light (TrueType)"="segoeuil.ttf"
"Segoe UI Light Italic (TrueType)"="seguili.ttf"
"Segoe UI Semibold (TrueType)"="seguisb.ttf"
"Segoe UI Semibold Italic (TrueType)"="seguisbi.ttf"
"Segoe UI Semilight (TrueType)"="segoeuisl.ttf"
"Segoe UI Semilight Italic (TrueType)"="seguisli.ttf"
"Segoe UI Symbol (TrueType)"="seguisym.ttf"
"Segoe MDL2 Assets (TrueType)"="segmdl2.ttf"
"Segoe Print (TrueType)"="segoepr.ttf"
"Segoe Print Bold (TrueType)"="segoeprb.ttf"
"Segoe Script (TrueType)"="segoesc.ttf"
"Segoe Script Bold (TrueType)"="segoescb.ttf"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes]

"Segoe UI"=-

-Step 2: Save as *.reg & right click Merge. Restart PC.

Btw, I came across this utility to change Windows fonts on the fly but it just crashes anytime I use it. I wouldn't recommend using it, but PowerToys could implement something similar: https://www.wintools.info/index.php/advanced-system-font-changer#:~:text=The%20Advanced%20System%20Font%20Changer,of%20how%20text%20is%20displayed.