OLED four subpixel rendering issue

[gettinwet]

I've bought a OLED monitor, which has four subpixels I believe arranged as RWBG, looks like this: Interestingly you may notice these 4 subpixels never all lit up simultaneously, which is very logical. Mactype have no corresponding subpixel rendering option for this layout, neither RGB nor GBR look good, so I switched to grayscale rendering. It looks ok with this option in most places, but the troublesome Chrome's rendering can't be altered, here's what it looks like:

My doubt is: if Chrome's rendering can't be altered by Mactype's config file, that means it's not rendered by Mactype, then why it stuck in subpixel rendering? who does that? I've tried adjust Windows' cleartype settings, no effect at all, and the cleartype preview is also not subpixel rendered. So who does that? Is there any way I can have it switches to grayscale rendering?

[wmjordan]

It also took me quite a few time to figure this out.

Please try to modify the command parameters to launch Chrome:

chrome.exe --disable-lcd-text --disable-features=RendererCodeIntegrity --disable-font-subpixel-positioning

And I have not yet found a perfect workaround for this issue. Some part of the interface is still rendered "colorfully", like #683. But it is much better at least web pages are now rendered in gray scale.

[wmjordan]

I also have two presets which use Gray scale rendering. You can give them a try.

DeepGrayNoHinting.zip SoftGrayNoHinting.zip

[gettinwet]

It also took me quite a few time to figure this out.

Please try to modify the command parameters to launch Chrome:

chrome.exe --disable-lcd-text --disable-features=RendererCodeIntegrity --disable-font-subpixel-positioning

And I have not yet found a perfect workaround for this issue. Some part of the interface is still rendered "colorfully", like #683. But it is much better at least web pages are now rendered in gray scale.

dude, u'r awesome! according to my test, --disable-font-subpixel-positioning doesn't work, --disable-features=RendererCodeIntegrity doesn't work either as we already know from #597, only --disable-lcd-text works, but it does work, great!

So is it safe to say Chrome uses it's own rendering engine, so that we can't affect it by adjust windows cleartype settings?

[wmjordan]

Thank you for your test and verification. It seems that --disable-font-subpixel-positioning and --disable-features=RendererCodeIntegrity have no effect in recent Chromium builds.

The --disable-lcd-text parameter can also be used to Electron-based applications, such as XMind Zen, Visual Studio Code, draw.io Desktop, Postman, etc.

I don't know the underlying logic of Chromium's text rendering. What I know is that DirectWrite is used instead of ClearType. Chromium's default LCD text sub-pixel rendering does get my eyes feel painful. However, MacType can affect the rendition effects no matter --disable-lcd-text parameter is provided or not. But somehow the sub-pixel rendition persists without that parameter.

[gettinwet]

--disable-lcd-text does work for VSCode too! That's nice, thanks for your remind!

But I don't understand how Mactype can partially affect the rendering result of Chrome. I'm not coder, as far as I can understand, Mactype either CAN or CANNOT inject into Chrome, once has it injected, it should completely take over the rendering. According to my test, mactype has no effect on Chrome at all, I'm using Mactype + Mactype patch, and no hinting modified font.

[wmjordan]

I am sure that MacType somewhat helps provide better text on web pages. My fonts are not modified and my MacType settings preferred no hinting.

With MacType on, Chinese characters look much more beautiful than with MacType off, on a Chromium-based web browser--Vivaldi--on my screen. At least MacType has control on the font hinting.

However, MacType can not control sub-pixel rendering on those Chromium-based applications. Thus we can see that the menus are still rendered with sub-pixel colorful anti-aliasing when the web pages are rendered gray-scaled.

[gettinwet]

I am sure that MacType somewhat helps provide better text on web pages. My fonts are not modified and my MacType settings preferred no hinting.

With MacType on, Chinese characters look much more beautiful than with MacType off, on a Chromium-based web browser--Vivaldi--on my screen. At least MacType has control on the font hinting.

However, MacType can not control sub-pixel rendering on those Chromium-based applications. Thus we can see that the menus are still rendered with sub-pixel colorful anti-aliasing when the web pages are rendered gray-scaled.

Oh, I'm using Chrome, maybe that's the difference.

UI and contents are rendered differently, you can see from my above pic of the notepad, although the content rendered grayscale, the title bar is still in subpixel rendering.

[wmjordan]

The title bar... It never worked on my computer after upgrading to Windows 10. You may try methods mentioned in this issue #708 anyway.

[gettinwet]

The title bar... It never worked on my computer after upgrading to Windows 10. You may try methods mentioned in this issue #708 anyway.

yep, I've tried to comment out the dwm.exe, it works! you're so sweet! I can't recall anywhere in my system rendering wrong now, basically I regard the rendering of my pc is perfect now. If Mactype can be updated with support for more subpixel layout will be better of course.

Considering #708, I think maybe because the OP has the title bar font with pixelated subfont below certain font size, which I've removed from my modified font, or maybe the Mactype patch has stepped in here, you may give it a shot in these two ways.

BTW the #708 OP's subpixel rendering is terrible IMO.

[xnetjack]

I also have two presets which use Gray scale rendering. You can give them a try.

DeepGrayNoHinting.zip SoftGrayNoHinting.zip

DeepGrayNoHinting it's very helpful!

[wmjordan]

I just updated to the MacType 2021 rc1.

It seemed --disable-font-subpixel-positioning and (or?) --disable-features=RendererCodeIntegrity are required for MacType to work on Chromium-based browsers.

[snowie2000]

I just updated to the MacType 2021 rc1.

It seemed --disable-font-subpixel-positioning and (or?) --disable-features=RendererCodeIntegrity are required for MacType to work on Chromium-based browsers.

Oh, I forgot the new option.

[wmjordan]

Hi Snowie, what's the new option?

[snowie2000]

I've added a description to the release page. And here it is ArmBreaker

[wmjordan]

Thanks for mentioning that. I just helped you to update the contents of the Wiki to include the link under the experimental section.

[snowie2000]

Thanks for mentioning that. I just helped you to update the contents of the Wiki to include the link under the experimental section.

You are sweet. Does the option work for you?

[wmjordan]

It does not seem to work for me.

I removed the --disable-features=RendererCodeIntegrity from the shortcut of vivaldi.exe and added the following part into the MacType.ini between the [MacType] and [UnloadDll] sections.

[[email protected]]
ArmBreaker=1

I closed the Vivaldi then restarted the MacType service, then the Vivaldi.

From the Chinese characters on the top-right side of the interface, I felt that MacType was not in effect. The correct effect with --disable-features=RendererCodeIntegrity in the shortcut when launching vivaldi was like the following:

However, I saw _MacType*.dll_s in the DLL list from Process Explorer.

[snowie2000]

You need to check the dll status of all the child processes.

Try to use armbreaker as a global option to see if it works.

[wmjordan]

I checked the dll status of the child processes: some of them were hooked, some were not.

I removed @vivaldi.exe from the MacType.ini file, so it was like the following:

[experimental]
ArmBreaker=1

It did not work either.

[bp2008]

I noticed the latest MacType preview builds (almost a year old already!) have support for custom subpixel layouts.

The MacType preview release notes reference https://freetype.org/freetype2/docs/reference/ft2-lcd_rendering.html which notes:

Subpixel geometry examples:

{{-21, 0}, {0, 0}, {21, 0}} is the default, corresponding to 3 color stripes shifted by a third of a pixel. This could be an RGB panel.

{{21, 0}, {0, 0}, {-21, 0}} looks the same as the default but can specify a BGR panel instead, while keeping the bitmap in the same RGB888 format.

{{0, 21}, {0, 0}, {0, -21}} is the vertical RGB, but the bitmap stays RGB888 as a result.

{{-11, 16}, {-11, -16}, {22, 0}} is a certain PenTile arrangement.

Armed with this information, I set out to create a MacType profile that provides proper subpixel antialiasing on LG's current OLED panels which use an RWBG subpixel layout (red-white-blue-green). I made copies of Default.ini that is included with MacType, and added a PixelLayout parameter. I have produced two sample profiles, explained and shared below. Neither of these is optimal. I detect a little color fringing, and haven't taken the time yet to do further experimentation.

RBG.ini (add PixelLayout=-21,0,21,0,0,0)

This is a naive modification of the "RGB" geometry from FreeType documentation, where I simply swapped the G and B coordinates.

RWBG.ini (add PixelLayout=-24,0,24,0,8,0)

For this one, I did a little math. I'm not sure I am doing this correctly but I am assuming the coordinates we provide are offsets of the center of the subpixel relative to the center of the whole pixel, and the pixel is 64 units wide and tall. This goes against what was noted in MacType's release notes a little bit where it suggests the pixel is 128 units wide and tall, but I think the MacType release notes are simply wrong.

A pixel on an LG WOLED panel is made up of 4 subpixels, so each should be 16 units wide:

This is also probably a bit naive. The physical pixels do not all have the same shape or area, but for this early test I'm treating them as if they are all the same size. By this logic the red subpixel is 24 units to the left. Green is 24 units to the right. Blue is 8 units to the right. White is 8 units to the left, but the software doesn't know anything about white subpixels, so I must omit that value.

Here are the ini files I came up with, along with extensive inline documentation of how I believe the PixelLayout parameter works: RBG-RWBG-Prototypes.zip

Currently it is necessary to use the latest preview build of MacType. If you use release 2021.1-RC1, the PixelLayout parameter will be ignored and you'll only get classic RGB subpixel antialiasing.

[mdrejhon]

Yes, @bp2008 -- it works well on my LG WOLED!

(Founder of Blur Busters / TestUFO here)

Unfixable even via best MacType settings, there is permanent color fringing on certain brands of OLEDs (especially QD-OLED).

WOLEDs are using RWBG pixel structures:

So I did some PhotoShop tests, and it looks fantastic: (cc: @gettinwet)

Note: Due to graphics paint software limitations, I couldn't adjust "Contrast", so there's some extreme contrast and excess sharpness artifact. However, if Contrast is made adjustable in software (e.g. an alphablend between subpixel-rendered and not subpixel-rendered), then that solves the problem

Also, I have a possible algorithm for using a bitmask (16x16 to 64x64) defining the subpixel structure for one software pixel of an OLED display (Pentile, or WOLED, or QD-OLED).

For WOLED, you can't control the white subpixel directly, so in MacType, the best way to render subpixel on LG WOLED is R-(ignore)-B-G quads, or R-B-G thirds. I created a large photo-filled report at https://github.com/microsoft/PowerToys/issues/25595 where @bp2008 got the inspiration from.

Over there, I posted more images and diagrams, I linked to over 100 upvotes in various duplicates in Microsoft Feedback Hub.

[mdrejhon]

I opened a new github for an OPTIONAL custom subpixel algorithm to be added to MacType, useful for the new OLED computer monitors hitting the market: The same MacType antialiasing can still be kept, except it is "pushed" through a subpixel filter.

Starter Generic Subpixel-Aware Supersampling Algorithm

[mdrejhon]

Checking... I see MacType doesn't have a for-sale venue. Since I submitted a "New PowerToy request" to Microsoft on their github, and PowerToy is an open source incubation venue -- have you considered submitting MacType source code as a PowerToy? Maybe MacType could be the "ClearType 2" for https://github.com/microsoft/PowerToys/issues/25595

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

[VEWION]

I noticed the latest MacType preview builds (almost a year old already!) have support for custom subpixel layouts.

The MacType preview release notes reference https://freetype.org/freetype2/docs/reference/ft2-lcd_rendering.html which notes:

Subpixel geometry examples: {{-21, 0}, {0, 0}, {21, 0}} is the default, corresponding to 3 color stripes shifted by a third of a pixel. This could be an RGB panel. {{21, 0}, {0, 0}, {-21, 0}} looks the same as the default but can specify a BGR panel instead, while keeping the bitmap in the same RGB888 format. {{0, 21}, {0, 0}, {0, -21}} is the vertical RGB, but the bitmap stays RGB888 as a result. {{-11, 16}, {-11, -16}, {22, 0}} is a certain PenTile arrangement.

Armed with this information, I set out to create a MacType profile that provides proper subpixel antialiasing on LG's current OLED panels which use an RWBG subpixel layout (red-white-blue-green). I made copies of Default.ini that is included with MacType, and added a PixelLayout parameter. I have produced two sample profiles, explained and shared below. Neither of these is optimal. I detect a little color fringing, and haven't taken the time yet to do further experimentation.

RBG.ini (add PixelLayout=-21,0,21,0,0,0)

This is a naive modification of the "RGB" geometry from FreeType documentation, where I simply swapped the G and B coordinates.

RWBG.ini (add PixelLayout=-24,0,24,0,8,0)

For this one, I did a little math. I'm not sure I am doing this correctly but I am assuming the coordinates we provide are offsets of the center of the subpixel relative to the center of the whole pixel, and the pixel is 64 units wide and tall. This goes against what was noted in MacType's release notes a little bit where it suggests the pixel is 128 units wide and tall, but I think the MacType release notes are simply wrong.

A pixel on an LG WOLED panel is made up of 4 subpixels, so each should be 16 units wide:

This is also probably a bit naive. The physical pixels do not all have the same shape or area, but for this early test I'm treating them as if they are all the same size. By this logic the red subpixel is 24 units to the left. Green is 24 units to the right. Blue is 8 units to the right. White is 8 units to the left, but the software doesn't know anything about white subpixels, so I must omit that value.

Here are the ini files I came up with, along with extensive inline documentation of how I believe the PixelLayout parameter works: RBG-RWBG-Prototypes.zip

Currently it is necessary to use the latest preview build of MacType. If you use release 2021.1-RC1, the PixelLayout parameter will be ignored and you'll only get classic RGB subpixel antialiasing.

I have tried this and it works great on light theme in win11 but worse on dark theme, especially on Chinese/Japanese. Texts becomes reddish. Needed to change AntiAliasingMode to 0 or 1 but this makes it not as good as 4(your default) on light theme. Also something not exactly related to this problem, enable DirectWrite support(your default) makes texts blurrier on dark theme too(such as win11 settings app). Not that obvious on light theme though.

[mdrejhon]

RBG.ini (add PixelLayout=-21,0,21,0,0,0) RWBG.ini (add PixelLayout=-24,0,24,0,8,0)

@bp2008 -- I notice that intentionally fudging things around by moving the subpixels closer together, seems to remove a fair bit of the sharpness-mask filter effect, as well as improve dark mode significantly. If you get a reddish tint, you can try to intentionally shrink the red number (shift the red subpixel slightly closer to center), and it will math-out the red subpixel less intensively.

More experimentation is needed.

I have tried this and it works great on light theme in win11 but worse on dark theme, especially on Chinese/Japanese. Texts becomes reddish. Needed to change AntiAliasingMode to 0 or 1 but this makes it not as good as 4(your default) on light theme. Also something not exactly related to this problem, enable DirectWrite support(your default) makes texts blurrier on dark theme too(such as win11 settings app). Not that obvious on light theme though.

See above;

1. Experiment with shrinking all numbers proportionally to reduce color fringing equally
2. Experiment with shrinking the red number more than the other numbers, to get rid of the red tinting during dark mode.

To get it to work in Microsoft Edge browser requires disabling its third party security checks, in the command line options -- wish this was a Microsoft ClearType native feature instead;

[ScarletVillain]

@mdrejhon Is this RWBG.ini for mactype the best way to improve text readability still or any improvements?

[mdrejhon]

Slight Further Improvements Due to W Subpixel Being Fatter

Fix for Pink Color Tinting To White Text On Black Backgrounds

@mdrejhon Is this RWBG.ini for mactype the best way to improve text readability still or any improvements?

There are minor variants that improve certain modes better (e.g. Dark Mode) than others (e.g. Light Mode) compensating for the fact that some WOLED subpixels are very slightly bigger than others, but this is generally the most generically accurate:

Centre of R subpixel = 37.50% offset to left of pixelgroup center (-24) Centre of W subpixel = 12.50% offset to left of pixelgroup center (ignore) Centre of B subpixel = 12.50% offset to right of pixelgroup center (+8) Centre of G subpixel = 37.50% offset to right of pixelgroup center (-24)

It is my understanding that PixelLayout defines pixel centers for Rx,Ry,Gx,Gy,Bx,By to represent subpixel centres within a cartesian 64x64 grid from [-32,-32] thru [+32,+32], so you scale accordingly.

This is precisely why the best historical LG WOLED configuration line has been traditionally this:

PixelLayout=-24,0,24,0,8,0

However, the subpixels vary slightly in width on some WOLEDs, and so, optimal pixelcenters may vary slightly, if you want to manually tweak the pixel centers a bit. For the fuller context, I would like to crosspost this tip, for people who want to manually tweak some improvements, to see if it helps.

The fact that the W unfiltered subpixel is larger, pushes the R slightly to the left, and B, G slightly to the right, so you may want to experiment with numbers such as:

PixelLayout=-26,0,26,0,10,0

By understanding this science, try to fudge your "24" about 1,2,3,4 units bigger away the zero origin, while fudging the "8" similar units bigger (or a bit less). See if it eliminates the "pink-color" tinting, when you do this. You may need to experiment with asymmetries like [-27,0,26,0,10,0] or [-27,0,28,0,11,0] to properly align with the asymmetric-widths of all those subpixels. Very fiddly, but you could ultra-macro-zoom the photograph, crop out one pixel, scale to 640x640 in a paint app such as PaintNET or similar, and mousearrow-center those subpixels, and math out those ideal subpixel-center coorinates. Or design an AI and/or logic algorithm to do this automatically, just supply a macro photo and you get automatic PixelLayout. Voila?

The further improvement is very subtle (not noticed by all), but is there for at least some content, if you compensate for the fact that some WOLED subpixels are slightly asymmetric (<10%) to accomodate the differing special efficiencies of different primaries. This was a tweak to brighten OLED for a given wear-and-tear, by milking the spectral efficiencies better.

This will vary from WOLED to WOLED and some of them have much fatter W subpixel than others, so you may have to vary more to kill the pinkish-color tinting for white text on black backgrounds. The pinkish color (a combo of unbalanced R+B tinting to white edges) is partially caused by the the R+B subpixels (adjacent to a very fat W subpixel) not having perfectly centered coordinates

With the virtual display, I'd be concerned about a few things, most importantly how well the thing would perform, in particular outside of the desktop environment (e.g., in a game).

It depends on your GPU performance. The RTX 3000-4000 series can shader-process a 1440p framebuffer in less than 1ms, so the overhead should be manageable for those games where it's more critical (e.g. cartoon style games with lots of yellows). But I'd just have a toggle to enable/disable the filtering, or let all OpenGL software bypass the driver (configurable option).

I realized after posting the above that the subpixel layout is RWBG not RWGB (even though I wrote it correctly above, I didn't really consider it), so my -24,0,0,0,0,0 doesn't quite do what it should. However, it's still significantly sharper than the default. I changed the layout to -24,0,24,0,-24,0 to swap the G and the B as well and the results are below.

Yes, it's RWBG.

You might want to make it spatial compensated, where center of R pixel is (25%+25%/2) = 37.50% offset to left, B pixel (25%/2) = 12.5% offset to right, and G pixel (25%+25%/2) = 37.50% offset to right. Basically accomodate that bigger gap between R subpixel and B subpixel. However, there are some side effects of the various decisionmaking on this.

Centre of R subpixel = 1.5 subpixel-width offset to left of pixelgroup center Centre of W subpixel = 0.5 subpixel-width offset to left of pixelgroup center Centre of B subpixel = 0.5 subpixel-width offset to right of pixelgroup center Centre of G subpixel = 1.5 subpixel-width offset to right of pixelgroup center

Which translates to percentages relative to entire pixelgroup width:

Centre of R subpixel = 37.50% offset to left of pixelgroup center Centre of W subpixel = 12.50% offset to left of pixelgroup center Centre of B subpixel = 12.50% offset to right of pixelgroup center Centre of G subpixel = 37.50% offset to right of pixelgroup center

Even treating RWBG as RBG is better than nothing, though I noticed slight improvement when treating it as R_BG being aware that R-B coupling is wider than B-G coupling, and just letting the panel decide on how to illuminate the W subpixel. Some minor side effects from that, but some experimentation needed software-side.

Try a new line that factors in a gap caused by not being able to control the W subpixel directly;