Re: [Discussion] Subpixel rendering issues with compressed video output formats
Hin-Tak Leung <[email protected]> Mon, 9 Jun 2025 18:43:56 +0000 (UTC)
| Newsgroups | gmane.comp.fonts.freetype.devel |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_2583306_1519295590.1749494636896
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I think I get the idea of what Vitor is suggesting, *in the theoretical se=
nse*, but I am not convinced that it matters. Anyway, here is how I underst=
and it, with 2 issues about HD displays:
- HD displays require high-bandwidth data transport- HD displays can presen=
t 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 re=
verse HUV -> RGB.
So you can get fringing (and colour fringing) from the first - it is the sa=
me sort of compression artifacts as the default jpeg 422 / 420 down-samplin=
g, 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 di=
splay to the computer, is not the same as how the physical pixels are actua=
lly on the screen.
I haven't read the original post carefully enough, so some of this is proba=
bly made up by me.
The bottom line is, if you have a HD display, you probably should switch of=
f subpixel rendering. There is no need to have subpixel rendering in that s=
ituation anyway..=C2=A0
On Monday 9 June 2025 at 19:11:29 BST, Alexei Podtelezhnikov <apodtele@=
gmail.com> wrote: =20
=20
=20
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 li=
kely out of scope of FreeType.
> On Jun 9, 2025, at 14:01, Alexei Podtelezhnikov <[email protected]> wrot=
e:
>=20
> =EF=BB=BFVitor,
>=20
> Frankly, I can hardly relate your problem description to font rendering. =
Can you possibly rephrase it? In FreeType speak LCD rendering is just tripl=
icated for 3 arbitrary color channels with slight differences depending how=
these channels are spatially shifted. Regular antialiasing is just a speci=
al case assuming that three channels are not shifted at all. Note that Free=
Type does not assign color to the channels.
>=20
> Alexei
>>=20
>>=20
=20
------=_Part_2583306_1519295590.1749494636896
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html><head></head><body><div class=3D"ydp70b0e3cfyahoo-style-wrap" style=
=3D"font-family:Helvetica Neue, Helvetica, Arial, sans-serif;font-size:16px=
;"><div></div>
<div>I think I get the idea of what Vitor is suggesting, *in the th=
eoretical sense*, but I am not convinced that it matters. Anyway, here is h=
ow I understand it, with 2 issues about HD displays:</div><div><br></div><d=
iv>- HD displays require high-bandwidth data transport</div><div>- HD displ=
ays can present itself as X x Y to the computer/application, when physicall=
y it is really 2X x 2Y, etc.</div><div><br></div><div>The first issue is th=
at vendor drivers on the host send RGB data through a compression filter wi=
th RGB -> HUV transformation plus down-sampling in the chroma channels, =
through the wire and decompress on the device with the reverse HUV -> RG=
B.</div><div><br></div><div>So you can get fringing (and colour fringing) f=
rom 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.</div><div><br></div><div>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.</div><div><br>=
</div><div>I haven't read the original post carefully enough, so some of th=
is is probably made up by me.</div><div><br></div><div>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..&nb=
sp;</div><div><br></div>
=20
<div id=3D"ydp70b0e3cfyahoo_quoted_9756571064" class=3D"ydp70b0e3cf=
yahoo_quoted">
<div style=3D"font-family:'Helvetica Neue', Helvetica, Arial, s=
ans-serif;font-size:13px;color:#26282a;">
=20
<div>
On Monday 9 June 2025 at 19:11:29 BST, Alexei Podte=
lezhnikov <[email protected]> wrote:
</div>
<div><br></div>
<div><br></div>
=20
=20
<div><div dir=3D"ltr"><br clear=3D"none">If you are referri=
ng to color fringing when the text is moving and RGB are firing up with som=
e delay. I have no idea how to synchronize it. This is likely out of scope =
of FreeType.<br clear=3D"none"><div class=3D"ydp70b0e3cfyqt8980505149" id=
=3D"ydp70b0e3cfyqtfd62058"><br clear=3D"none">> On Jun 9, 2025, at 14:01=
, Alexei Podtelezhnikov <<a shape=3D"rect" href=3D"mailto:apodtele@gmail=
.com" rel=3D"nofollow" target=3D"_blank">[email protected]</a>> wrote:<=
br clear=3D"none">> <br clear=3D"none">> =EF=BB=BFVitor,<br clear=3D"=
none">> <br clear=3D"none">> Frankly, I can hardly relate your proble=
m 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. Reg=
ular antialiasing is just a special case assuming that three channels are n=
ot shifted at all. Note that FreeType does not assign color to the channels=
.<br clear=3D"none">> <br clear=3D"none">> Alexei<br clear=3D"none">&=
gt;> <br clear=3D"none">>> <br clear=3D"none"><br clear=3D"none"><=
/div></div></div>
</div>
</div></div></body></html>
------=_Part_2583306_1519295590.1749494636896--