ClearType-style subpixel scaling algorithm to enhance 1080p on 720p/768p LCD display

[Mark Rejhon]

Hello,

Been a while since I've posted here, but I'm doing research...

Has any developer (ffdshow, virtualdub, components of CCCP codec kit, etc) written a filter that does subpixel scaling for video? It would enhance 1080p display on a 720p LCD using RGB-striped LCD displays (which is triple horizontal resolution if counting the subpixels)

The reason I'm posting this is that I recently have the possession of a high performance netbook-sized computer Acer Aspire Timeline 1810T, with a 11.6" 1366x768 display and with a Core2 Duo and a GPU (GMA4500HD) -- which means I now can play 1080p with only 15% CPU. It even works with an external Blu-Ray drive, and PowerDVD. So this made me think about how those spare processor cycles could be used...

There's a 2003 article about using subpixel scaling on video:
http://new.ics.ele.tue.nl/~dehaan/pdf/90_jsid2003.pdf
(Much like Microsoft's ClearType).

I've promoted algorithms that can be written in high speed assembly on PocketPC in 2001, that was successfully used one Nintendo emulaton on the PocketPC back then:
http://forum.brighthand.com/showthread.php?p=602343
(old article)

(NOTE! The subpixel algorithm I posted there is only useful for a 33%-stretch scale, such as scaling a 240 pixel wide image to a 320 pixel wide image. However, the proof of concept shows that it's possible to write an optimized realtime ClearType-style scaling algorithm, that even runs on a lowly ARM CPU -- I'm sure this is proof enough even an Intel Core2 Duo can handle realtime high-def ClearType-style subpixel scaling algorithm. The main challenge, probably, would be the different colorspace (YUV versus RGB), but that is not an insurmountable challenge, and possibly the video could be rendered to an RGB framebuffer, THEN the subpixel scale filter could run. (Or the two steps could be combined -- run the subpixel scale filter when copying final RGB pixels into an RGB framebuffer. Some SSE/assembly wizard could probably easily come up with an algorithm.)

Even a 1366x768 display is over 4000 subpixels wide (1366 times 3 equals 4098). Some of that can be used to sharpen high-def playback, such as improving 1080p downconversion to a 1366x768 display. Before you say 1080p is wasted on a portable display, remember, most people view a 11.6" netbook display from about about 16" away -- that's "closer" than most people's viewing a 40" HDTV from 10 feet (120") away. 11.6" from 16" away is ratio 1.4:1. 40" from 120" distance is ratio 3:1. That's what I mean by "closer" as in bigger angular view (meaning more coverage of vision == more human eye resolution available to absorb 1080p beauty). Everyone who's seen Blu-Ray play on the netbook, say yes: even the difference between 480p and 720p is very clearly visible in PowerDVD on these netbooks, and there is room for further improvement, at the 1.5 ratio of view distance to screen width, frequently typical for laptop screens. (Airplane-tray 1080p that's actually of more benefit than normal 40" HDTV 10 feet away :) )

The horsepower and hardware is already there, the subpixel enhancement algorithms work for images, someone just needs to write some DirectShow filter if one is not written... Nudge, nudge!

This would also benefit low-res (720p or 768p) plasma-display home theaters that are used at close view distances where 1080p benefits, as most HTPC's already have the horsepower to run a ClearType-style subpixel video scaling algorithm...

Obviously, the subpixel scale filter should be the last filter to run -- all other filters (unsharp, denoise, etc) can run to enhance the original 1080p image, then the subpixel scale filter would convert to native resolution.

(Please post if anyone decides to take upon the challenge of writing an open source ClearScale algorithm to enhance 1080p quality on modern high-performance dual-core netbooks with GPU's such as Ion...using either GPU code or optimized SSE assembly programming.)

[wonkey_monkey]

the subpixel enhancement algorithms work for images

Pics or it didn't happen! ;)

David

[Mark Rejhon]

It's not mutually exclusive of other sharpening filters which can still run; just run the other filters at a higher resolution before using the subpixel scale filter to scale it to the actual display. Or, even, to make the subpixel scale filter simple, one could upscale to 3 times the horizontal width, THEN do a horizontal-only downscale using a subpixel scale algorithm. It could even be done by using only ADD's, AND's and OR's. For a 1366x768 display, scale the 1920x1080 image to 4098x768 (upconvert horizontally and downconvert vertically), run post-scale video filters on that, then downscale to 1/3rd horizontal resolution by combining red value from every third pixel, then green value from every third pixel offset by 1, then blue value from every third pixel offset by 2. And create the output image from that. Now, those who are familiar with ClearType know that this will cause color-fringing artifacts. So to soften that, make a second 1366x768 framebuffer containing a traditionally-scaled image. Now, using alpha blending, combine the two framebuffers (1366x768 traditional-scaled image and the 1366x768 subpixel-scaled algorithm -- suggested config option -- create a slider to select balance between sharpness and color fringe removal). Presto, I've given you instructions on how to implement a ClearScale algorithm, essentially:

This algorithm would, in theory, work with ANY resolution source video, being subpixel-scaled to ANY resolution destination display:

For each frame of the video; the algorithm is as follows:
1. Objective is to scale a 1920x1080p image to a 1366x768p display.
...Current Resoluton=1920x1080p
2. (optional) On the original resolution, apply all pre-scale filters that are useful (i.e. denoise, picture adjust, unsharp mask, etc), using existing filters that are already developed.
3. Next, scale using favourite scale filter to 3 x screen width and same as screen height. Even bicubic scaling would work just fine, although best to use a good filter. Note, that you're upconverting horizontally and downconverting vertically.
...New Resolution=4098x768p
4. (optional) Execute any the post-scale filters that usually useful at native resolution of the display (i.e. dejaggie filters, display-resolution sharpeners, etc.)
...Resolution Still=4098x768p
5. Convert to RGB colorspace
...Resolution Still=4098x768p
6. (Destination FrameBuffer #1) (semi-optional) Use a favourite scaling algorithm to traditionaly scale the image
...Final Resolution=1366x768p
7. (Destination FrameBuffer #2) Execute the subpixel scale algorithm: For each 3 pixels horizontally in the image (currently 4098x768), take the red channel value from pixel, then the green channel value from the next pixel, then the blue channel value from the next pixel after, combine these red/green/blue values into one pixel, output pixel to destination frame buffer.
...Final Resolution=1366x768p
8. You now have the subpixel-scaled framebuffer.
...Final Resolution=1366x768p
9. (semi-optional, but STRONGLY recommended) To soften the color-fringing artifacts often found in subpixel scaling, alpha-blend FrameBuffer #1 and #2 together (basically, combine the subpixel-scaled framebuffer with the non-subpixel scaled framebuffer.) Provide a configuration value to allow adjustment of this alphablend step.
...Final Resolution=1366x768p

Optimization suggestions:
- Combine various steps, such as combining steps 5 & 7, or figure out a way to render steps 5 through 9 in one pass using a more complicated mathematic algorithm. (Math wizards here can probably figure this one out)
- For step 3, not all filters might do a good job on such a strange scale job (upconvert horizontally and downconvert vertically); alternatively one could do 4098x1080p and just let the display do the vertical downconversion which won't interfere with subpixel scaling which would work only horizontally on the vast majority of LCD's. (to be tested; but that might be a waste of CPU cycles).
- (Optional) Essentially, one could skip vertical scaling, keep vertical resolution same as original image (1080p for all steps instead of 768p) and only focus on horizontal scaling assuming full-screen viewing -- and let the display do the downscaling to 768p, depending on whether the display does a better job of vertical downscaling than the ffdshow filter; horizontal scaling algorithm can be made completely independent (and totally different) from the vertical scaling algorithm. (Example: People who scale the image horizontally with one algorithm keeping original vertical resolutoin, THEN use a different algorithm to scale the image vertically)

[Mark Rejhon]

David, your wish is my command...
Crude demonstration images of algorithm above on a small image (excludes steps 6 and 9)

- Point sampled subpixel scaling; no alphablend or traditional antialiasing to soften the color fringing
- Needed to save as PNG; as JPG does not keep subpixel information.
- Must be viewed on an LCD display, doesn't show on CRT.

Easiest is to save both images to disk, then flip between the two back and fourth, to see the difference.

[wonkey_monkey]

7. (Destination FrameBuffer #2) Execute the subpixel scale algorithm: For each 3 pixels horizontally in the image (currently 4098x768), take the red channel value from pixel, then the green channel value from the next pixel, then the blue channel value from the next pixel after, combine these red/green/blue values into one pixel, output pixel to destination frame buffer.

I could be wrong, but doesn't this (at least when using bicubic as the upscaling filter, as you suggest) just result in the red, green and blue channels all being offset from each other by 1/3 of a pixel?

If you're lucky, exactly one of your channels will remain unaltered by the upscale/downscale. The other two will be offset - I don't see how this can be called an enhancement, but maybe I'm missing something.

Attachment approval can take time - could you upload to image hosting service?

David

[Mark Rejhon]

More samples of my algorithm.... Observe that the top of the building is sharper, and the faint vertical grey lines in the artdeco concrete is sharper. Assuming you're using a normal desktop LCD display -- save both images to disk and then flip back-and-fourth between the two images. (Turn off slideshow transitions, for instant flip back-and-fourth). The difference is subtle, but definitely noticeable when flipping back and fourth. One can see the vertical lines are slightly smoother.

The difference is also much more noticeable on low-DPI displays, or when you sit close to a low-resolution display (i.e. netbook or portable DVD player displays), than when viewing on, say, on a high resolution 2560x1600 30" display. The algorithm is beneficial when we're downconverting high-res images for resolutions found on portable devices.

Now somebody please write this in SSE assembly language as a filter for ffdshow...!

[Mark Rejhon]

I could be wrong, but doesn't this (at least when using bicubic as the upscaling filter, as you suggest) just result in the red, green and blue channels all being offset from each other by 1/3 of a pixel?That's exactly what we want.
If you put a magnifying glass to one pixel on an LCD display,
You'll see the red subpixel in the leftmost 1/3 of one pixel
You'll see the green subpixel in the middle 1/3 of one pixel
You'll see the blue subpixel in the rightmost 1/3 of one pixel
This is true for the vast majority of LCD dispays.
We're simply preserving positional information, and this is _precisely_ the nature of ClearType-style subpixel scaling.

Note1: I don't recommend bicubic, but as an example intermediary. I recommend the best ordinary scaling filter (non-subpixel) you can use. A smarter scaling filter is recommended - there are plenty of preexisting ones in ffdshow already. We do not need to worry about subpixel information in scaling step #3, and the step #7 subpixel scale algorithm is independent of the non-subpixel scale algorithm used in step #7, and the final quality will still improve (subtly) with better non-subpixel scaling algorithm used in step #3. Bicubic, Bilinear, Smart, whatever -- they will all work in step #3 -- better filters preferred for step #3 obviously as they will subtly improve the quality of the final image.

Note2: Obviously, smart programmers will recognize that complex optimizations could be done to avoid having to use a wasteful processor-intensive triple-resolution intermediary buffer (i.e. to avoid having to use 4098x768 just to produce a 1366x768 image). But, it does make the programming of a resolution-independent ClearType-style subpixel scaling algorithm /massively/ simpler. I'd say, given the current healthy processor capabilities of today, let's begin by the K.I.S.S. approach for now and use my common-sense algorithm or variation thereof.

Note3: For more demo images, one can essentially follow my algorithm, to create subpixel scaled images in Adobe Photoshop, GIMP, Paint Shop Pro, or other favourite layer-capable raster-image-capable paint program by scaling a larger image down to an image that's 3 times as wide as final destination resolution, then RGB channel-separate, individually shift each image by 0/1/2 pixels respectively for R/G/B, then use point-sample to downscale each image horizontally to final output resolution (this deletes 2 out of 3 pixels for each channel), then RGB channel-combine these 3 images, you got the final subpixel-scaled image, which you can then save as PNG. This essentially does my algorithm. The alphablend step to balance traditional anti-aliased image and subpixel image can be done by using layer translucency to blend the combined subpixel and nonsubpixel images perfectly aligned ontop of each other.

Note4: ClearType-style scaling doesn't noticeably benefit images that are already soft; So if using digital photo images, use a large downconversion factor, such as scaling 10 megapixel images downwards to 720p or low resolutions such as 1024x768; large amount of downconversion benefit the most from ClearType-style scaling, especially fine detail in vertical lines, and slightly-slanted vertical edges. (For exactly the same reason why the letter "W" and character "/" benefits a lot in Microsoft's ClearType) Many high-end Blu-Ray movie releases are often downconverted by movie studios from 4k or 8k masters to 1080p when creating the Blu-Ray disc and are already darn near maxed-out in theoretical 1080p sharpness, and those will potentially be benefited the most by ClearType-style scaling during further downconversion to 768p and 720p or even 600p displays. Netbook playback of 1080p is thus, a good application of where ClearType-style scaling will benefit.

[wonkey_monkey]

Ah, okay, I didn't get it before - now I do, and I shall ponder...

David

[IanB]

# Y8 is a 2.6 pixel format, use YV12 for 2.5 avisynth

W=1366 # Output Width
H=768 # Output Height
...
...Resize(3*W, Height()) # Maybe some NNEDI, etc

ConvertToRGB32(...)

R=ShowRed("Y8").PointResize(W, Height(), 0,0, Width(),0) # Match offset to display subpixel order
G=ShowGreen("Y8").PointResize(W, Height(), 1,0, Width(),0)
B=ShowBlue("Y8").PointResize(W, Height(), 2,0, Width(),0)

MergeRGB(R, G, B) # Combine spatially disparit colour channels

Spline16Resize(W, H) # Set final height
However this is probably better done in the output graphics coprocessor.

[Mark Rejhon]

Well, that is damn neat -- it can be done in a simple Avisynth script!
Your script appears to be the correct algorithm.
(It does exclude the final alphablend step that balances traditional scale versus subpixel scale to reduce color fringing. Microsoft's ClearType, does this as a compromise too -- it combines a balance of traditional antialiasing and subpixel antialiasing to reduce visibility of ugly color-fringing artifacts. But that's probably a simple two or three line addition to your script, too.)

Still good for testing proof-of-concept.
Obviously, the output would have to be saved as lossless video (uncompressed 4:4:4 video) to preserve the subpixel information, which is impratical except to test as a proof-of-concept.

The trick is to select the proper ultra-high-rez video with lots of contrast. I suggest H.264 1080p of 25Mbps bitrate ala Blu-Ray video, not the 5Mbps YouTube stuff, because the fine detail in those are usually softened too much or filtered-out to benefit from subpixel scaling unless scaled to abnormally low reoslutions such as 1080p scaled to tiny 640x480 windows.. Obviously, most benefit occurs when running this to a low-dpi laptop style display such as 1366x768, 1024x768, or 1024x600. While all the small netbook displays all benefit, the big 14 inch laptops with 1366x768 with the big pixels seem to benefit more massively on my demo images. (And even more so on cheaper 32 and 40 inch 768p displays that are viewed up fairly close.)

Yes, a realtime output directshow filter (ala ffdshow) is better as it can be used with regular player software, preferably automatically detect the source size and the output image size and automatically adapt the subpixel scaling to adapt. It's true that we really do not want to save the subpixel information permanently into a new videostream onto disk (because that would make it optimal to be displayed at only one resolution, and it's very hard to compress subpixel information except in uncompressed 4:4:4 video -- I had to use PNG instead of JPG for the photograph samples to preserve the subpixel enhancement.)

I'll post a link in the ffdshow forum to here, but some of you avisynth developers are also filter programmers, so step up to the homeplate and write a filter! If it can be done in such a simple Avisynth script like the above, it shouldn't be too hard to write in a filter -- much easier to write than most filters! (Pity I don't know SSE well enough)

[scharfis_brain]

I did this years ago, but noone was interested:
http://forum.doom9.org/showthread.php?t=64369&highlight=clearscale

[IanB]

Always just a little ahead of the game :D

[roozhou]

(Pity I don't know SSE well enough)
You should first implement your algorithm in high-level langurage (e.g. C/C++), then consider about SIMD optimization.

[wonkey_monkey]

While I can't fault the principle of squeezing every last bit of resolution out of an image - and those examples do exhibit some slight improvement in certain areas - I'm not really sure the benefits are going to outweigh the deficits. Cleartype itself works so beautifully because the text renderer holds a "perfect" representation of the character to be drawn, and because (in most cases) it's trying to present a crisp black shape over a white background - neither of these are likely to hold true when you're dealing with video. I wonder if, in most cases, there simply won't be that kind of detail to preserve when displaying video, unless you're doing quite a high factor downscale, or you're dealing with graphics rather than video.

David

[Mark Rejhon]

I did this years ago, but noone was interested:
http://forum.doom9.org/showthread.php?t=64369&highlight=clearscaleIt was just ahead of its time, as 1080p was not widespread then.
Subpixel scaling of video is pretty useless for DVD because most DVD material are upconverted.
Subpixel scaling is really downconversion-improvement only...

But now we got HD video. And many screens that can't handle the full HD. Which is what we're essentially doing for 1920x1080 onto 1024x768, 800x600, 1024x600. Even would benefit 480p and 720p playback on iPhone-sized displays that are lower resolution than the source. The dpi is low enough on the iPhone to benefit too (load my sample PNG's into an iPhone PNG-viewer app, display at original pixel size, and the improvements are still noticeable even on the small screen.)

Your algorithm is better than mine in many respects because it does both the ClearScale and traditional antialiasing, rather than having to do the same result via alphablend. My algorithm is mathematically easier to understand but more expensive in performance, while yours is much more optimized than mine. The matrix you used should be easily handled by SSE assembly language, methinks...

To advertise this properly in Plain English to perk people's interest, it could be explained as
"a high-quality downconversion scaling filter for LCD displays",
"a high-quality method of displaying full HD 1080p on 720p displays",
"an improved quality method of watching full HD on low resolution laptop displays".

To explain why people have not expressed much interest in subpixel scaling, is:
- Difficult to understand
- Difficult to explain benefits of
- Difficult to determine which situations benefit from it

But the chicken and egg has arrived: Blu-Ray quality high-def being downconverted.

That said, ideally this should be done in the GPU if we want to benefit netbooks (i.e. those with the Ion.) If using my algorthm, it could even be done on the GPU itself using just blit and mask operations (no complex GPU programming language needed) using an equivalent of one of the above AviSynth operations. Though a ffdshow filter on the CPU would be more universal.

The time might be ripe to write an ffdshow filter. The performace is there even for HD, but a good SSE programmer can do the core routines in just a few hours of work probably -- then a few hours of fiddling in tests -- it really is just a simple algorithm, definitely much easier than writing a TrueType renderer for ClearType. The more complex part will be experimenting with the order of the filters and compatibility, etc... But one can grab somebody else's output filter, and replace the code.

davidhorman, I agree, but I think the improvements are subtle, the effort is low too (less than a 1 day project, once you understand how subpixel works). Some Blu-Ray material actually looks jaggied )(pixel level jaggies) at native resolution because they are made so sharp. Blu-Ray menus. Blu-Ray subtitle text edges. Overlaid graphics on top of video. High-contrast city scenes stills. Long lady hair draping vertically in sunlight. Stationary scenes where your eye linger, are the ones that will benefit the most from the improvement in sharpness. But most especially text embedded in video (i.e. Blu-Ray subtitles), those would benefit from this algorithm - on some discs the subtitles are in itallics and I see pixel-jaggies in them even at 1080p when viewing at 1.5:1 distance:screen width ratio. So will be sharp enough to benefit sufficiently from a half-factor or third-factor downconversion. The difference between many scaling algorithms is also subtle. Many videophiles want to tweak out the maximum quality given their situation.

My examples are kind of crude as it does not filter-out the color fringing, see the 01110 sample in scharfis_brain's link -- that's even better since there's no noticeable color fringing, and the scaling works. I feel a good subpixel scaling algorithm should also have an algorthm included to erase the color fringing while taking advantage of wherever subpixel scaling benefits. That's why I included the alphablend step, but I like schrfis_brain's method better (though it's more complex to program).

[pandy]

Remember that proper subpixel position vary and is dependent from construction of display - seems that most optimal place to made subpixel resizing/placement is display controller - fine tuning shall be made at hardware level and manufacturer is responsible for that (few vendors advertising such solution - AFAIR Panasonic mention something about subpixel display)

[Mark Rejhon]

Remember that proper subpixel position vary and is dependent from construction of display - seems that most optimal place to made subpixel resizing/placement is display controller - fine tuning shall be made at hardware level and manufacturer is responsible for that (few vendors advertising such solution - AFAIR Panasonic mention something about subpixel display)I agree that it's best to do it in the display controller. Many displays that use the 'delta' style pixel pattern (similiar to shadowmask pttern), tend to operate at the subpixel level. It's much more rarely (or never) used with striped LCD subpixels, used in the vast majority of LCD computer monitors and LCD displays because it's convenient to just operate at the pixel level, and requires de-fringing (remove color artifacts)

Virtuall all (Over 99%+) of all standard computer LCD's, and most (I'd say 90%+) of LCD and plasma HDTV's, use the standard RGB stripe pattern, so would universally benefit. Portrait mode (rotatable) is the main gotcha.

So, an ffdshow filter can be useful as this is missing from the vast majority of LCD displays.

[IanB]

Portrait mode (rotatable) is the main gotcha.
Why, as long as you know the display pixel layout you can craft the algorithm appropriately....
...Resize(Width(), 3*H) # Maybe some NNEDI, etc

ConvertToRGB32(...)

R=ShowRed("Y8").PointResize(Width(), H, 0,2, 0,Height()) # Match offset to display subpixel order (anticlockwise rotation)
G=ShowGreen("Y8").PointResize(Width(), H, 0,1, 0,Height())
B=ShowBlue("Y8").PointResize(Width(), H, 0,0, 0,Height())
...Just now you are preserving vertical resolution.

Also I used PointResize to nail home the intention of the algorithm and explicitly select the pixel to match the display subpixel, however one could use any other resizer (probably a very sharp gauss) to tailor some antialiasing or other mitigation.

[Mark Rejhon]

You're right, the algorithm can be adapted easily for RGB landscape / RGB portrit / BGR landscape / BGR portrait. Should be easy enough to script in avisynth. But as a ffdshow filter, it may be a little more complex to be flexible when written in assembly language. We can for now just assume the most common R-G-B subpixel support, to cover 99%+ of LCD laptop/monitor screens...

[knutinh]

I think that you will not get optimal results doing a plain per-channel rgb offset. What we want is trading luminance sharpness (3x horizontal resolution maximally) vs chrominance aliasing (if you point-sample a color image by r, g and b individually and offset you will get bad aliasing).)

Some of the papers suggest to split the video into luminance and chrominance (not luma and chroma), then do a perceptually motivated lowpassfilter. I think that the microsoft cleartype paper did just that back in 1998?

Note that this is similar to the processing done in camera bayer sensors (only the other way around and not quite the same).

I am interested in the connection between subpixel scaling and dithering. Could the color error be "propagated" spatially like some dithering algorithms do? What is the optimal perceptually motivated trade-off between luminance and chrominance level precision and position precision given the rgb-striped displays that most of us use?(dithering trades positional noise for better perceived level precision, some scaling/sharpening algorithms trade positional error for better local edge sharpness).

Could slight "messing" with the local color give us more than 256 luma levels? Think greyscale ramp of stepsize 10. Perhaps it can be done better than:
[r1=0,g1=0,b1=0][r2=10,g2=10,b2=10][r3=20,g3=20,b3=20]......

http://upload.wikimedia.org/wikipedia/commons/0/0d/Subpixel_demonstration_%28Quartz%29.png
http://en.wikipedia.org/wiki/Subpixel_rendering

-k

[Mark Rejhon]

I'm aware of what you're describing. I already mentioned this, but you described this much better than I did.

A tradeoff is needed to trade-off the "color fringing" (which you call chrominance aliasing) with the luminance sharpness. I believe that a better chrominance anti-aliasing algorithm can be used than the one I describe in step 9, since the alpha blend step is not a subpixel-level antialiasing algorithm.

I think the algorithm described in this thread, does exactly what you describe:
http://forum.doom9.org/showthread.php?t=64369&highlight=clearscale
(scharfis_brain's Avisynth script to do subpixel-level antialiasing)

____________

Side note, but on related topic:
I know Microsoft ClearType handles this case too (colored font on colored background, including ClearType text printed on top of graphics/picture) -- with color images subpixel operations don't always enhance the image. For example, sharp borders between red and blue, do not benefit from subpixel level operations. The lower the color saturation the border is, the more benefit subpixel level algorithms will do to the border. No enhancement occurs in borders between pure primary colors (red, green, blue), while limited enhancement occurs in borders between pure secondary colors (yellow, magenta, cyan) since only two out of three subpixels can get anti-aliased. More enhancement occurs with colors that have more balanced values of red, green, blue -- i.e. light pinks and light blues benefit more from subpixel than dark pinks and dark blues. Then again, we don't really need to worry too much as most HD material aren't sampled at 4:4:4 -- the chroma in source material is encoded often half (or sometimes quarter) the resolution of luma.

In theory, the subpixel chrominance anti-antialiasing algorithm (or, rather "color-defringing algorithm") could be made adaptive based on human perception of color fringing. Subpixel-level chrominance anti-antialiasing could be disabled for low-contrast borders, and maximized for high-contrast borders. Even subpixel-level sharpening algorithms for high-contrast borders, but this could be done upstream anyway on the original 1080p before doing the subpixel sampling, for the same effect, and still benefit from the subpixel chrominance anti-aliasing. Perhaps adjustable using a slider or two. Basically, use a geometric relationship rather than linear relationship of amount of subpixel-level chrominance anti-aliasing versus contrast between pixels. But for the purposes of SIMD assembly, let's KISS for now. Either using my crude color-defringe algorithm by alphablend -- or using the subpixel level color-defringe algorithm (found in the link to scharfis_brains' old thread), which is simple enough to implement in an ffdshow filter using SIMD programming techniques...

[moviefan]

I just tried the short avs-script on a CG scene and wanted to test frame to frame comparison between the original and the processed frame. I could not notice any difference at all (probably because of CG) but I noticed a drop by about 22% in PNG file size. How is that possible?