~eliasnaur/gio

3 2

Font rendering (macOS has same problem)

Details
Message ID
<61363c2d-bb87-eae1-25ba-882ec090547a@meessen.net>
DKIM signature
pass
Download raw message
Hello,

I tested kitchen on a mac book air 7,2 (2015 model, not retina) and it 
shows the same problem [1]. a) is a screen capture of the text as seen 
on the mac scaled by 400% without any interpolation. b) is the same text 
rendered with Nigel Tao’s font render.

Note that while doing these tests and screen captures, I noticed that 
GIMP is modifying the gray map in saved images to the point that the 
problem becomes nearly invisible when png is opened with other image 
viewers or libre office. When reopening the png with GIMP, it restores 
the initial gray map that makes the problem visible. I didn’t spend more 
time investigating that behavior. It’s probably gamma correction. I used 
another image editor (pinta) that didn’t alter the gray map of saved 
images.

I don’t have a screen capture, but I see a similar problem with GIO WASM 
in firefox on macOS. The text is not sharp.

I didn’t have the opportunity to test on Windows yet. I’ll test that ASAP.

I tested GIO WASM on an ipad air 2 (retina) and saw a similar problem, 
but only when kitchen is running (safari) which BTW is very slow. The 
image shown before clicking the run button doesn’t display the problem.

[1] https://imgur.com/314m7ep

-- 
Bien cordialement,
Ch.Meessen
Details
Message ID
<CAUXU2WFJSP4.UKSIRYWFTHRX@testmac>
In-Reply-To
<61363c2d-bb87-eae1-25ba-882ec090547a@meessen.net> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
On Thu Apr 22, 2021 at 15:48 CEST, Christophe Meessen wrote:
> Hello,
>
> I tested kitchen on a mac book air 7,2 (2015 model, not retina) and it 
> shows the same problem [1]. a) is a screen capture of the text as seen 
> on the mac scaled by 400% without any interpolation. b) is the same text 
> rendered with Nigel Tao’s font render.

Sure, the problem appears on all platform because they all perform
blending in gamma ~2.2. Unfortunately, fonts are typically authored in
gamma ~1.0 and therefore look thinner in gamma 2.2.

To be clear, the hack I posted for Linux/Android reverts blending to
gamma 1.0 which is not correct in general. A proper fix is to adjust
font rendering to compensate for the increased gamma.

Elias
Details
Message ID
<fa2b491d-6fef-faf8-8914-bc3834d6098e@meessen.net>
In-Reply-To
<CAUXU2WFJSP4.UKSIRYWFTHRX@testmac> (view parent)
DKIM signature
pass
Download raw message
Le 23/04/2021 à 09:51, Elias Naur a écrit :
> On Thu Apr 22, 2021 at 15:48 CEST, Christophe Meessen wrote:
>> Hello,
>>
>> I tested kitchen on a mac book air 7,2 (2015 model, not retina) and it
>> shows the same problem [1]. a) is a screen capture of the text as seen
>> on the mac scaled by 400% without any interpolation. b) is the same text
>> rendered with Nigel Tao’s font render.
> Sure, the problem appears on all platform because they all perform
> blending in gamma ~2.2. Unfortunately, fonts are typically authored in
> gamma ~1.0 and therefore look thinner in gamma 2.2.
>
> To be clear, the hack I posted for Linux/Android reverts blending to
> gamma 1.0 which is not correct in general. A proper fix is to adjust
> font rendering to compensate for the increased gamma.
>
> Elias

According to [1], the gamma correction is performed automatically when 
using the sRGB buffer.

I found the following calls to use the sRGB buffer. It is thus used, but 
maybe not with egl.

app/internal/wm/gl_macos.m:    glEnable(GL_FRAMEBUFFER_SRGB);
gpu/headless/headless_macos.m:    glEnable(GL_FRAMEBUFFER_SRGB);

Could gamma correction be applied twice ? I’m sorry, I don’t know opengl 
and GIO enough to check by myself.

A font is defined by a set of vectors encoding its outline. There is 
thus no gamma involved in font design. A font is basically like any 
other vector drawing. Gamma correction is performed on the rasterized 
image prior to display.

I made a comparison with text rendered by FreeType. It’s a screen 
capture from libre office using Go regular size 16pt. [2] is un-scaled  
text. Top is GIO’s, middel Tao’s and bottom is FreeType. It is obvious 
that Tao’s is closest to FreeType rendering. GIO’s is too light gray. 
[3] is the same image scaled by 400%. The sub pixel rendering of the 
FreeType text becomes apparent. It is obvious that the text rendered by 
GIO is too clear.

It seem reasonable to consider FreeType font rendering as a correct 
reference.

Note that I made a screen capture of FreeType text and GIO rendered 
text. The image processing is thus identical.

To me, the problem is not only with text rendering. It is with any 
vector rendering inn GIO. It is just strongly visible with text where 
anti-aliasing is critical. The reason is because text in GIO is rendered 
as any other vector drawing. I tested it by making GIO draw some text 
defined as a set of polylines generated by Tao’s algorithm. It displays 
the same problem as text rendered by GIO.

The most reasonable conclusion is that there is a problem with rendering 
in GIO in general, and it is very likely due to inappropriate gamma 
correction.


[1] https://learnopengl.com/Advanced-Lighting/Gamma-Correction

[2] https://imgur.com/GQBXR1c

[3] https://imgur.com/V47DArZ

-- 
Bien cordialement,
Ch.Meessen
Details
Message ID
<CAV8HDXAU4M3.3QIOI24S21IXQ@themachine>
In-Reply-To
<fa2b491d-6fef-faf8-8914-bc3834d6098e@meessen.net> (view parent)
DKIM signature
fail
Download raw message
DKIM signature: fail
On Fri Apr 23, 2021 at 12:01, Christophe Meessen wrote:
> Le 23/04/2021 à 09:51, Elias Naur a écrit :
> > On Thu Apr 22, 2021 at 15:48 CEST, Christophe Meessen wrote:
> >> Hello,
> >>
> >> I tested kitchen on a mac book air 7,2 (2015 model, not retina) and it
> >> shows the same problem [1]. a) is a screen capture of the text as seen
> >> on the mac scaled by 400% without any interpolation. b) is the same text
> >> rendered with Nigel Tao’s font render.
> > Sure, the problem appears on all platform because they all perform
> > blending in gamma ~2.2. Unfortunately, fonts are typically authored in
> > gamma ~1.0 and therefore look thinner in gamma 2.2.
> >
> > To be clear, the hack I posted for Linux/Android reverts blending to
> > gamma 1.0 which is not correct in general. A proper fix is to adjust
> > font rendering to compensate for the increased gamma.
> >
> > Elias
>
> According to [1], the gamma correction is performed automatically when 
> using the sRGB buffer.
>

Yes.

> I found the following calls to use the sRGB buffer. It is thus used, but 
> maybe not with egl.
>
> app/internal/wm/gl_macos.m:    glEnable(GL_FRAMEBUFFER_SRGB);
> gpu/headless/headless_macos.m:    glEnable(GL_FRAMEBUFFER_SRGB);
>

Indeed, "Desktop OpenGL" can enable and disable sRGB mode with
glEnable(GL_FRAMEBUFFER_SRGB). OpenGL ES set the sRGB mode at buffer
creation.

> Could gamma correction be applied twice ? I’m sorry, I don’t know opengl 
> and GIO enough to check by myself.
>

I don't think so.

> A font is defined by a set of vectors encoding its outline. There is 
> thus no gamma involved in font design. A font is basically like any 
> other vector drawing. Gamma correction is performed on the rasterized 
> image prior to display.
>

The font authoring software needs to render the font to the designer.
Because font renderers historically blending in sRGB space (assumed
gamma=1.0), authoring software did/does so as well.

So design decisions, in particular what constitutes the normal weight
for a font is decided in gamma = 1.0 space.

> I made a comparison with text rendered by FreeType. It’s a screen 
> capture from libre office using Go regular size 16pt. [2] is un-scaled  
> text. Top is GIO’s, middel Tao’s and bottom is FreeType. It is obvious 
> that Tao’s is closest to FreeType rendering. GIO’s is too light gray. 
> [3] is the same image scaled by 400%. The sub pixel rendering of the 
> FreeType text becomes apparent. It is obvious that the text rendered by 
> GIO is too clear.
>
> It seem reasonable to consider FreeType font rendering as a correct 
> reference.
>
> Note that I made a screen capture of FreeType text and GIO rendered 
> text. The image processing is thus identical.
>
> To me, the problem is not only with text rendering. It is with any 
> vector rendering inn GIO. It is just strongly visible with text where 
> anti-aliasing is critical. The reason is because text in GIO is rendered 
> as any other vector drawing. I tested it by making GIO draw some text 
> defined as a set of polylines generated by Tao’s algorithm. It displays 
> the same problem as text rendered by GIO.
>
> The most reasonable conclusion is that there is a problem with rendering 
> in GIO in general, and it is very likely due to inappropriate gamma 
> correction.

I believe Gio's rendering is correct with respect to the vector input.
However, drawn with gamma~=2.2 text indeed looks too thin, especially on
lower resolution displays.

Tao's and Freetype's renderings look better for two different reasons.
See [0] for the full explanation, but the short story is that Gio
renders like the "Gamma 1.8" variant, Tao's like the "Gamma 1.0" variant
and finally Freetype darkens glyph stems to arrive at the "Gamma 1.8,
Darkened" variant.

So what's the fix? We could do like Tao's renderer and effectively
ignore gamma when rendering. That's a few lines of change, as you can
tell from my Linux/Android hack.

However, ignoring gamma introduces other problems, as explained in [0]
but also in [1], [2]. It is also not quite right for text, as you can
tell from the difference between the "Gamma 1.0" and "Gamma 1.8,
Darkened" output.

A better fix is to adjust apply stem darkening like Freetype does. It's
a more complex change, so it is yet to be implemented. I'd be delighted
if you're interested in working on that problem.

Elias

[0] https://www.freetype.org/freetype2/docs/hinting/text-rendering-general.html#experimental-stem-darkening-for-the-auto-hinter
[1] https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/
[2] https://gamedevelopment.tutsplus.com/articles/gamma-correction-and-why-it-matters--gamedev-14466
Reply to thread Export thread (mbox)