Text/Subtitle glyphs rendering AA

[DTL2020]

With addition of new resizing kernels (SinPow and UserDefined) it is now possible to perform all actions required for antialiasing and other 'conditioning' activity at text glyphs rendering process for digital moving pictures systems. It is also sort of simplest form of content creation activity from parameter-defined content of infinite resolution (like true-type fonts) into target resolution of fixed frame size in samples of current digital moving pictures system.

It is also possible in scripting form but may require to use more RAM (and complex text rendering with 10x linear (100x SSAA) may be easily limited by host RAM size with current AVS caching system. So for processing speed at current computer architecture it is more benefitical to perform render work in caches and not full pass of clip processing to resampler from host RAM. Also for some applications glyphs of font may be pre-rendered (big startup time for very large number of total glyphs Unicode fonts but fast text render).

The idea of AA processing is very simple - add new params to text output filters like

ssaa - (default=1, no additional processing), and integer ranging from 1 to something about 10 (10x linear and 100x SSAA). For 8bit systems the practical limit of SSAA may be about 200..1000x SSAA so max param value may be limited to sqrt(1000)=about 30. For HBD HDR systems it may be much higher. The test condition for 'SSAA limit' is about: for given 1bit input from non-AA glyph rasterizer of 1 non-zero (non-black, full white source pixel) the AA/conditioning filter's max response fall below 1 LSB of output level resolution (bitdepth, 1/255 for 8bit full-range). So no further increasing of SSAA supersampling can help to make output result better (for small font's elements).

aakrn - any of the AA-capable resize kernels for resampler (gauss, sinpow, userdefined2), default may be userdefined2 or sinpow with p-param about 2.7. gauss at enough 'antialiased' mode provide more 'film/cine-look' without any over/undershoots - decreasing acutance (may be important for small output glyphs sizes).

param1 and param2 - kernel control param (defining output glyphs 'makeup/look' in sharpness, acutance, and other).

And after requesting glyph from operating system (or other font rasterizer) in enlarged to 'ssaa' times size (the Windows AA may be disabled and glyph may be requested in most dense 1-bit black and white mode) - pass it to downsize scaler to requested output size. At process of downsize the bounding box of glyph become a bit larger to keep complete fading to black process so the processing buffer (in output glyph size) must have additional padding about 2..3 samples minimum (4 or 5 may be recommended for best results) around system-provided blackbox size for given glyph. This padding is not kept in text arranging from glyphs sequence (advancing to origin of next glyph, so bounding boxes of AA-processed glyphs may overlap at output glyphs placement to output buffer).

Also for more 'perfect world' it must be noted: The described AA processing creates glyph 'conditioned' in linear scene light and text placement to underlying frame (downstream keying, DSK) must be performed in linear domain also. So because currently AVS looks like not support transfer conversions so for better results recommended to convert clip to linear domain (scene light linear) and apply Text/Subtitle in linear overlay and convert back to target output transfer function (may be after resizing or other more processing). Direct applying (overlaying) to the transfer-function encoded clips will cause some more distortions (also (may) create mixed content impossible to correct linear process later because of mix of different domains conditioning) and also will cause visible 'thickness' difference of glyph's elements. Another possible (and possibly partial) solution is converting of the glyph (or block of output text as total buffer) to target system transfer (applying gamma for old systems or complete non-gamma-only or HDR-transfer for newer systems) before final blending to output. So may be when AVS will support transfer functions conversion we can add more param like 'transfer' and 'overlay_mode' of 'transfer' or 'linear'.

Also applying better AA to content for 'natural' digital moving pictures systems adds possibility to have lower granularity in size (non 1 integer) for better text placement/fitting for example. With ssaa=2 possible natural size granularity is 0.5, with ssaa=10 is 0.1. Though it (may) require to change text renderer to support subsample granularity sized glyphs. Integer sized programming overlay need to support non-integer advancing to next glyph's origin for example. Other possible solution is render full text block in integer size enlarged to 'ssaa' size and downscale before downstream overlay - may be much easier in programming and only 1 call to resampler. Though may be slower in performance in compare with pre-rendered glyphs usage - the total text block with large ssaa-value may easily fall out of L2/L3 cache size to slow host RAM.

[pinterf]

I'm a bit skeptical about its usefulness, Text has very limited capabilities, it is basically a filter for displaying debug info on screen. Subtitle is superseeded as well by more flexible and more capable filters.

[DTL2020]

Well - this can be marked as 'nice to have' feature and left to the other times when developers will have time. Today at least method of creating more conditioned texts with Text()/Subtitle() of increased size and Resize() to target size may be added to documentation.