-
Notifications
You must be signed in to change notification settings - Fork 444
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generic Subpixel Algorithm for Triangular-Structure QD-OLEDs / Pentile / WOLED / Others #932
Comments
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 (eventually) submitting MacType source code as a PowerToy? Maybe MacType could be the eventual "ClearType 2" for microsoft/PowerToys#25595 Donation OLED Offer to Software Developer With Font CredAlso, 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. |
I don't know what is the W pixel for. Is it simply for brightness purposes? Since logically, only the RGB subpixel is accessible from a hardware-independent perspective, and I don't think there will be any way to light/dim this pixel. It should be operated conditionally by the driver circuit. So far, the powertoy for Windows is a collection of tools that basically built on top of the existing Windows mechanisms, like unlocking files, finding the cursor, on-screen OCR, color picking, and fancy zone, and that's the most interesting one, I'm not sure if the implementation of FancyZones is deeply coupled with Windows internals or if there are exposed APIs to customize the Aero Snap feature. However, it's not like MacType, which completely takes over font rendering because Windows doesn't allow for that level of customization. If Windows were to expose APIs that allow for intercepting kernel font rendering, perhaps through a driver or other means, I believe that more capable people would develop more versatile ways to improve display. Monitor manufacturers would likely be the first group of people to do so, as they have the most motivation, and good font rendering is a significant selling point for enthusiasts." |
<Temporary-Sidetrack>
I observe you chose to comment on this as your first sentence; so it must've caught your attention so unexpectedly. (I will post a good explanation here, as education for people unfamiliar with this OLED concept; e.g. a future coder that might take upon this coding responsibility) Although I was hoping to keep subpixel politics away from this thread -- the W pixel is a brightener and an OLED lifetime-extender by offloading wear and tear away from R,G,B. There are papers at Society for Information Display (sid.org), and also demonstrated at DiplayaWeek. How OLEDs now last much longer (now safe for Windows/computer use), thanks to various techniques done by OLED manufacturers of unifying the emissive spectrum to a long-lasting color (white for all subpixels for LG, blue for all subpixels for Samsung). LG uses color filters for R,G,B and a white subpixel, and Samsung use quantum dots for R,G. The end result is that OLEDs became brighter and longer lasting, and more ready for computer graphics; thus a large number of OLED computer monitors. In addition, it is also a fairly broad-spectrum W pixel, which also reduces eyestrain quite a bit on black and white text too, given that pure blackbody white light is usually more comfortable to stare at for long periods than whites generated by R,G,B. However, the primary reason was the lifetime extender (prevent burn-in). Many of us have now been using WOLED's for long durations with PhotoShop and Visual Studio. LG currently has no plans to expose the W pixel to APIs, it's automatically turns on at the display firmware level as a computation between R,G,B. However, I found that ignoring the W pixel successfully works. Proof of Concept
*** TEXT IS TWICE AS SHARP ON LG WOLED = SUCCESS ***Even ignoring the white subpixel.Please be assured I already spent hundreds of hours communicating to many parties, as well as internally on many subpixel related initiatives. Simply ignoring the white subpixel works successful in a ClearType style renderer, as seen in the above proof.Blur Busters is a hobby-turned-business, and I am hugely passionate in these fronts; you can see it in my writings. I am simply providing information for a potential pull-request submitter, any future coder who reads this that might take this subpixel-feature baton. I've submitted a few algorithms to open source (including a 3:2 pulldown deinterlacer way back in year 2001 for dScaler app), so I'm very passionate about display stuff. </Temporary-Sidetrack> |
Many Announcements For Desktop OLED in Year 2023 ALONELet'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. Remember, ClearType was originally incubated as an application (Reader) and a PowerToy (Tuner). Before it becomes an OS feature, this could be incubated by many routes
For you, I understand you might not want to take upon this complexity. It is okay to decline this feature request, but some programmers might take upon this responsibility, and submit a pull request; so I am providing as much useful information as possible -- happy to answer questions! |
I agree. However, it needs to be incubated. I believe in multiple incubation routes, including via the MacType route. Some OS features were originally incubated as a PowerToy, after all. ClearType Tuner was originally a PowerToy before it became a native OS feature. ClearType was also originally done at the application-level, as Microsoft Reader in year 1998, and its Tuner was a PowerToy, so that's why there's a feature request in the PowerToy github too, to logically cover all bases in possible open source incubation routes;
Unfortunately, as a passionate hobby-turned-business, I work with monitor manufacturers for the last ten years. To dispel the assumption that manufacturers can easily do this. Everyone specializes in their respective silos -- very few monitor manufacturers understand subpixel rendering. I have flown overseas to manufacturers too, and have helped with a few (strobe tuning) -- the Blur Busters Approved logo is on the ViewSonic XG2431 as an example. It was a lot of work to help them with a superior motion blur reduction feature. If you noticed, even Microsoft closed the original subpixel rendering item, and Microsoft ignored the large numbers of OLED complaints in their Feedback Hub. Therefore, I am hitting third party options such as font renderer library or MacType or PowerToy pull requests, remember ClearType Tuner was originally a PowerToy. The way the monitor hardware development life cycle works nowadays -- is most of them now outsource firmware development to an asian vendor (e.g. Suzhou Lehui, TPK, MSTAR, etc) that specializes on the really common basics (row-column addressors, scanout, DisplayPort protocol, scaler/TCON). The panel manufacturers provide the prototype panels to them. The vendors works on it. Thanks to industry standard (e.g. VESA DisplayPort spec, HDMI port spec, generic row-column addressor chips, off-the-shelf FPGA), the display supply chain is very siloized. And a lot of them don't even understand subpixel font renderers; So this is a weak link in the display supply chain; the lack of ability to get this successfully fixed; I can assure you that I've hit my head so many times on brick walls, I've lost count! Back when high end multisync or flatpanel displays cost $5000+ (inflation adjusted), many vendors did everything internally, but that's not the case with a $499 gaming monitor or even a $999-$1499 OLED, not to speak of those generic $99-$199 junk. Even premium models like Corsair Xeneon Flex 45" OLED sing off the same HDLC (Hardware Development Life Cycle) songsheet. This is still done (e.g. OLED iPhones, Quest 2 VR headset) but computer monitors sell only by the multi-thousand units, not tens of millions like video game consoles. Small profit margins at small unit counts, Profit margins are very tight with displays nowadays in the race-to-pricing-bottom, so often they no longer pay attention to these things. They are using odd pixel structures for various technological reasons (e.g. longevity, burnin resistance, etc), target gaming, and just tolerate the text issues. However, with the big boom of WOLED in office usage (e.g. 4K 48" TVs instead of four 24" LCDs), with many thousands using a TV as a desktop monitor now, and just using greyscale mode (e.g. MacType, etc). However, as the above demonstration image proves (if you view it on a WOLED), there's a very significant text clarity improvement by being aware of the spatial locations of R, G, B, even when ignoring the white subpixel. Hopefully this GitHub item helps any willing contributors in the future; since it actually successfully works in PhotoShopping tests. If someone require pay for this open source programming task, I am open to negotiation -- contact me mark [at] blurbusters.com for a bounty pot contract. Paid project, as an open source bounty contract, would be conditional on a permissive license initially MIT/Apache as an application subpixel library, and in a way that is donateable to GPL 3 projects (like MacType in future) (Apache is undirectionally compatible with GPLv3). Open to proven font-renderer-experienced people, if reached out by end of summer 2023. I am in more than 25 peer reviewed papers (Google Scholar) as well as www.blurbusters.com/area51 |
There is some support for vertical offsets when defining subpixel geometry already. I don't have a Samsung QD-OLED display, but I made some prototype profiles that someone else could test in the latest MacType preview. QD-OLED-Prototypes.zip Here are their render samples next to grayscale and standard RGB antialiased samples: I based these on this image which suggests that all offsets are about 1/4 of the pixel's width, which makes it nice and simple: QD-OLED-1 is I wasn't sure which direction the vertical offsets go so I made both. I think |
Oh, fantastic -- I will get these profiles tested. Since the LG WOLED is the more common announcement than the Samsung QD-OLED, may you create additional profiles for LG WOLED in the R-G-B layout, either as thirds system or quarters system? Are you able to create prototype profiles for R in the leftmost quarter, B in the 2nd rightmost quarter, and G in the rightmost quarter? (Keeping blank for the 2nd leftmost, which is left to the LG's scaler/TCON to automatically use, as necessary). Mathematically; treat it like a square, where the leftmost quarter is the red subpixel, the rightmost quarter is the green subpixel, and the next-to-rightmost quarter is the blue subpixel. Pretend that the next-to-leftmost quarter is the white subpixel. Or even better, provide two profiles. For testing purposes. This will be so much easier than using PhotoShop tests (it takes me a lot of time creating simulations, even if I was successful at it)
Also, is there a Contrast setting of some kind? (like a Saturation setting, or an alphablend between the color-fringy and not-fringy) |
OK, promising results, but the "Contrast" (color saturation) is too strong, it overshot the fringing. I Photoshopped the color saturation up/down and showed some people. The 50% seems to work best on QD-OLED, but some people seem to like the 25%, 33% or 75% better and some asked for in-between settings. Many are fans of more faint ClearType behavior. I think we need tunability in 5% increments based on personal preference. Is there a Contrast/Saturation setting that is adjustable on a per-user preference? Still getting more beta test feedback but people seem to like it! Hang on. Meanwhile, can you do me a favour and:
|
@mdrejhon I posted RBG and RWBG files the previous day over here and you already commented on them. These are really trivial to create and edit, as you've already noticed I think. Please don't mistake me for a MacType dev :) |
I didn't comment directly on that one directly yet, I will need to give those a test. But I don't think that one is very ideal -- need some Contrast tweaking (adjusting saturation down); it will need to be adjusted for optimal rendering, methinks. |
Update, unbeknownst to me; There's another 9-month-old fix on Reddit at u/UnadvisedApollo at
Just wanted to include this data here; |
New pixel structure on 2023 QD-OLEDs https://i.imgur.com/wvPN0Mrl.png |
Hello! Recently bought a Samsung G8 QD-OLED monitor and found the font rendering to be a pretty big problem initially. I have used MacType since then and tweaked settings until I finally settled with a profile and configuration that feels good in almost all instances. I use a lot of applications and this profile I think looks great and quite natural for Windows. Settings I use:
Please try it out. I exclude Also, thanks @snowie2000 for the work you put into this project 🙂 |
Wow, this is definitely the most pleasant-looking solution so far. Much appreciated. |
Inspired by community, I made a small project to be able to use grayscale font anti aliasing for Firefox, Obsidian, and Visual Studio Code electron based apps. |
I have the OLED G9 and went down this rabbit hole because it looks like the G9 has a substantially (to my noob eyes) different pixel structure than the G8. I tried creating a grid with a G8 vs. G9 comparison picture, and also took pictures of my G9 with my phone and tried to calculate values for mactype's
PixelLayouts 1 & 2 were calculated using the G8 vs G9 image and overlaying a 32 x 32 grid. 3 was calculated using a macro picture from my Pixel 8 Pro. I've attached the new profiles for people to play with. The If anyone has a G9 or another second gen QD-OLED, I would love your thoughts on the revised profile for MacType! Settings used for testing:
|
|
New Developments
Not surprising. I talk about Slight Further Improvements Due to Subpixel Asymmetries. I advocated a slight deviation away from the exact pixelcenter calculations, since the subpixel grid is slightly offset from a perfect symmetry (shifting the centres of subpixels). So these very subtle further tweaks are fantastic on both QDOLED and WOLED. I think we need a realtime preview utility for PixelLayout edits for faster user-friendly tweaking (without needing to reboot/restart). Much like the ClearType Tuner except, with sliders for all six numbers. So we have sliders for all 6 numbers while watching the result of the text in realtime (e.g. something like . That is later expanded to have a "Attach JPG/PNG Attachment" to accept a camera photograph and automatically calculates the pixelcenter offsets automatically.
|
I think outside the box:
Calculating PixelLayout from a smartphone photograph is in theory algorithmically possible, plus power-user further tuning (6 slider approach). The utility would display a test pattern (showing lines and pixels), and ask you to photograph by phone and attach the file. Then it would determine the bounding box for the repeating pattern that aligns with the attempted pixel displaying (from test pattern), and from that, compute average subpixel centers in those bounding boxes. Maybe with a slight amount of NN AI to speed things up, but the algorithm is simple enough to do it by pure logic. Metaphorically like a "Remote controls database for an online universal remote control" or a "Automatic game-profiles database for Steam Deck" Even this will work without the auto-photograph method, just by virtue of 1 power user successfully creating a working PixelLayout for a specific display model (specific 7-character DisplayID plug and play code). For example, BenQ XL2411P reports "BNQ7F63" when you scan its DisplayPort, and reports "BNQ7F64" when you scan its HDMI port. So, you can link PixelLayout to specific DisplayIDs, in theory, to help database all of this automatically. Also, this will also be beneficial for other use cases such as virtual reality headsets, where the screendoor is massively worse due to a small screen enlarged to a large percentage of your vision. You could just brute it out by just adding more DPI, but we will always sometimes be using lower resolution displays for one reason or another, somewhere, and we shouldn't omit subpixel structure awareness from modern operating systems! |
Are there any out of the box profiles for pentile/s-type subpixel layouts? |
Hey all, to anyone that is still struggling with text clarity dxzdxz1 had posted a comment in another thread where he found that ExplorerMicaBlur version 1.07 seemed to resolve his OLED text clarity issues! 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. |
Fantastic improvement for OLEDs! This is NOT subpixel rendering, but might very well be one of the best greyscale-antialiasing renderers. We still need improved subpixel rendering for lower-DPI 240Hz OLEDs like large 1440p desktop OLEDs, but this route is probably fine and easier when you have enough pixels (4K 240Hz OLEDs) |
Found for me exceptional decision https://github.com/sava41/qdoled-defringe. I have Samsung Odyssey OLED G9 G93SC, so fringe is a little bit annoying for longreads and several fonts. |
Hello everyone. I recently got the LG OLED 27GS95QE monitor and I'm curious about the best solution to eliminate color fringing. I've tried ExplorerBlurMica version 1.7, but it only works for explorer.exe and not other programs. I also tried MacType, but it doesn't work in Chromium/Electron programs, so I'm wondering what the best temporary fix is. The "--disable-lcd-text" launch argument works for Chromium/Electron programs, but it makes text blurrier and to me, the fringing is preferable to blurry text. I also find that the MacType (DeepGrayNoHinting profile) makes the text slightly blurry, so if there's a clearer profile without fringing, please let me know. |
And by the way, it's easy to check for any color fringing around text using the Magnifier system app. |
NOTE: Not the same as #720 -- because this is a generic system that applies to all odd-pixel displays including triangle-pixel displays that are sometimes found on MiniLED Jumbotrons, Samsung QD-OLED, etc.
As founder of TestUFO/Blur Busters, I have a suggestion 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.There is Unfixable Color Fringing even with MacType
MacType is unable to fix the OLED color fringing on Samsung QD-OLED displays. ClearType Tuner can't fix it either. We're looking for a solution because there a
giant boom of OLED monitor announcements for year 2023
.There is Lot of Demand
A way to recruit donations for MacType? Lots of duplicates in Feedback Hub with over 100 upvotes on the brand new Samsung QD-OLED computer monitors.
Starter Generic Subpixel-Aware Supersampling Algorithm
A small mask bitmap is created for the subpixel structure (what the subpixel structure looks like for one real software-based pixel), which the user can specify. Or the bitmap could be represented as rows of base-4 numbers (0=transparent, 1=red, 2=green, 3=blue) so that it makes visual sense. Or it could be a transparent PNG with alpha channels (adjustable transparent edges), with transparent, red, green, blue. Etc.
Optional: For rare odd screens, such as ASUS Vivabook, you have weird structures for 2x2 groups of pixels. Therefore, you might need to use one bitmap for a 2x2 group of onscreen pixels, for slight further improvements to subpixel rendering. So mask can be configurable dimensions 1x1, 2x1, 1x2, and 2x2 for oddball displays -- one can photograph an OLED screen macro lens, then crop, then downconvert to just red/green/blue, and save the bitmap as a mask bitmap for subpixel rendering.
For every time one font glyph is rendered onscreen:
If yes, skip to step 5.
Example: If it's a 16point character of Arial, draw it at 256point size within GPU memory
Example: Use a GPU shader to push the large font letter through the subpixel-structure bitmask during downsample
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.
There should be a "Contrast" setting adjustment like ClearType APIs, which is metaphorically an alphablend between subpixel rendered and not subpixel-rendered.
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)
LG WOLED Pixel Structure
Note: The subpixel mask will have to omit the white pixel, showing only R-(blank)-G-B
Samsung QD-OLED Pixel Structure
ASUS Vivabook Pro 15 OLED Screen
Contrast Setting (Subpixel Blending)
The Contrast (a sort of alphablend) setting is very important.
The Contrast setting will blend between pure MacType (no subpixel rendering) versus full subpixel-rendered MacType.
This can be made adjustable to user preference; from absolutely no subpixel rendering (normal MacType) to full blatant color-fringy subpixel rendering. Also, this will need to be rotation-compensated (e.g. detect current screen rotation and automatically rotate the bitmask accordingly), linked to the rotation of the primary monitor.
In my experience, in turning on/off subpixel rendering, a default blend of very roughly 25%:75% alphablend between the full-contrast subpixel rendering and the non-subpixel (original MacType antialiasing) rendering, will likely look like a fantastic "ClearType 2" upgrade for OLEDs.
Don't forget to gamma-compensate subpixel rendering
Remember not to forget gamma-correction during your alphablending, as correct subpixel tinting is based on the real-lumens ratio, not the R,G,B numbers of whatever colorspace you use.
Remember! Due to gamma curve, pure RGB(200,100,100) or #804040 or #402020 is more than twice as many red photons as green photons and blue photons. Despite the red programming representation being numerically double the number of green and blue in such formatting -- it follows a gamma curve (2.2 by default for most monitors). So you need to gamma-correct your subpixel rendering for best results, with the standard gamma formula. Or use existing APIs that already does the alphablending correctly, e.g. many alphablend algorithms (mathing two bitmaps together) already has built-in gamma correction, but you should verify.
More Photos And Images at microsoft/PowerToys#25595
The text was updated successfully, but these errors were encountered: