Re: [Discussion] Subpixel rendering issues with compressed video output formats

[VÍTOR RAMOS]

Behdad has interpreted it best:

> What Vitor is referring to is when the graphics cards sample down the 
> resolution of certain channels, typically in the YUV color space, but 
> sometimes maybe in RGB, eg. encoding every 4x4 block of blue channel only, 
> 2x2 of red, and 1x1 of green.

> It's as if you JPEG compress the subpixel-rendered image and decode it...

The analogy with JPEG is most apt because the encoder does perform
chroma subsampling. (But most notably it performs quantization of DCT
coefficients, so typically the more prominent artifacts associated
with it are because of the quantization and not because of the
subsampling.)

This is not a theoretical issue, and is not limited to the
display/output pipeline of a graphics processor not supporting it, as
processing or bandwidth can be limited by any component between source
and sink.

So in practical terms, if we generally plug a budget (high-resolution
or high-refresh rate) display to a budget device, it is likely that
the negotiated format has chroma subsampling.

The relation to subpixel antialiased font rendering is that even if
the subpixel geometry is correct, the fact that chroma was subsampled
results in terrible fringing.

On Mon, Jun 9, 2025 at 3:45 PM Hin-Tak Leung
<htl10@users.sourceforge.net> wrote:
>
> I think I get the idea of what Vitor is suggesting, *in the theoretical 
> sense*, but I am not convinced that it matters. Anyway, here is how I 
> understand it, with 2 issues about HD displays:
>
> - HD displays require high-bandwidth data transport
> - HD displays can present itself as X x Y to the computer/application, when 
> physically it is really 2X x 2Y, etc.
>
> The first issue is that vendor drivers on the host send RGB data through a 
> compression filter with RGB -> HUV transformation plus down-sampling in the 
> chroma channels, through the wire and decompress on the device with the 
> reverse HUV -> RGB.
>
> So you can get fringing (and colour fringing) from the first - it is the same 
> sort of compression artifacts as the default jpeg 422 / 420 down-sampling, 
> where you throw away the lower bits in the H and U channels.
>
> The 2nd other issue about HD, is that the reported pixel geometry of the 
> display to the computer, is not the same as how the physical pixels are 
> actually on the screen.
>
> I haven't read the original post carefully enough, so some of this is 
> probably made up by me.
>
> The bottom line is, if you have a HD display, you probably should switch off 
> subpixel rendering. There is no need to have subpixel rendering in that 
> situation anyway..
>
> On Monday 9 June 2025 at 19:11:29 BST, Alexei Podtelezhnikov 
> <apodtele@gmail.com> wrote:
>
>
>
> If you are referring to color fringing when the text is moving and RGB are 
> firing up with some delay. I have no idea how to synchronize it. This is 
> likely out of scope of FreeType.
>
> > On Jun 9, 2025, at 14:01, Alexei Podtelezhnikov <apodtele@gmail.com> wrote:
> >
> > Vitor,
> >
> > Frankly, I can hardly relate your problem description to font rendering. 
> > Can you possibly rephrase it? In FreeType speak LCD rendering is just 
> > triplicated for 3 arbitrary color channels with slight differences 
> > depending how these channels are spatially shifted. Regular antialiasing is 
> > just a special case assuming that three channels are not shifted at all. 
> > Note that FreeType does not assign color to the channels.
> >
> > Alexei
> >>
> >>
>