<p>The anti-aliasing rendering is correct.</p>
<p>The reference gray ramp (top and bottom) is linear in sRGB color, not in brightness.</p>
<p>The second gray ramp made with anti-aliasing is linear in brightness. The rectangle color (black in color sRGB space) is mapped to linear space (remains black), then anti-aliasing is computed, and the resulting image is converted back to sRGB. It is thus not linear in sRGB value anymore.</p>
<p>The RGB values given by a screen color picker are in  sRGB color space, and the color values of a screen capture are in the sRGB color space.</p>
<p>SVG and nearly all browser graphic library (skia and cairo) are doing it wrong. They compute anti-aliasing over sRGB instead of linear color. They thus don't convert back from linear to sRGB. The same mistreatment  is also visible on Windows, MacOs and iOS.</p>
<p>The filled rectangle gray ramp doesn't have this problem because the conversion from sRGB to linear and its inverse cancel out.</p>

CC BY-SA 4.0
2021-04-30T17:11:16.833Z
2021-04-30T17:11:16.833Z
chmike
<p>I have the impression that there is a problem with anti-aliasing in a 2D GUI framework using opengl. To demonstrate the problem I made a program that draws gray ramps. The result is shown below.</p>
<p><a href="https://i.sstatic.net/u63fw.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/u63fw.png" alt="anti-aliasing rendering test" /></a></p>
<p>The top and bottom gray ramps are identical and considered the reference ramps. It is a copy from <a href="https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/" rel="nofollow noreferrer">&quot;What every coder should know about gamma&quot;</a>. This is what I currently assume that we should see when gray colors are correctly encoded. There seam to be a rounding error in this ramp, so an exact match is not required. The right most rectangle is not perfectly white.</p>
<p>The second gray ramp counting from the top is produced by drawing each rectangle as a stack of black lines not thicker than a pixel on a white background. The thickness of the lines reduces linearly as we go from black to white. The gray color result thus purely from anti-aliasing.</p>
<p>The third gray ramp is simply a sequence of rectangles filled with linearly increasing gray values.</p>
<p>I was expecting that all gray ramps would look identical, but clearly the second gray ramp is not. It seam that a gamma correction has been applied to it while I think it should not.</p>
<p>It generates artifacts which are strongly visible in font rendering as shown below.</p>
<p><a href="https://i.sstatic.net/qi77z.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/qi77z.png" alt="This is a test comparison" /></a></p>
<p>The text <em>a</em> has been produced with the library in question, and the text <em>b</em> has been produced with another font rendering library.</p>
<p>Another test I did to put in evidence the artifacts resulting from the anti-aliasing color processing is to draw slightly slanted lines.</p>
<p><a href="https://i.sstatic.net/GeVh5.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/GeVh5.png" alt="slightly slanted lines" /></a></p>
<p>The lines above are produced by the library in question and the lines below by another library. The thickness of the lines below look more uniform. The lines above look wrong and distorted.</p>
<p>The author of the 2D graphic library claims that his color processing with anti-aliasing and filled rectangle is correct.</p>
<p>Who is right ? What argument could I use to resolve this disagreement ?</p>
<p>The more I work on this subject, the more I get confused. For instance, by using a color picker I see that the color in the center of the ramp of the reference image is close to 0x7F. Is the color picker giving the color in linear space or the <a href="https://medium.com/game-dev-daily/the-srgb-learning-curve-773b7f68cf7a" rel="nofollow noreferrer">sRGB color value</a> ? The screen color picker is Gpick (Gnome Linux).</p>
<p>I know that we should work in linear color space when performing operations on images. What is unclear is what am I looking at ? The color values I gave to rectangles where linear, not sRGB, or not gamma corrected. The color ramp I see seam linear. The values given by the color picker seam to match the linear value I gave.</p>

CC BY-SA 4.0
2021-04-28T17:08:17.380Z
Font rendering is a special case.
joojaa
CC BY-SA 4.0
2021-05-03T19:27:13.267Z
The top set of lines in the antialiasing image is correct.  The bottom set of lines is rendered naively without respect for gamma.  You can tell because in the top set, the midpoint intensity is an RGB ~189 which corresponds to sRGB 50%.  But the bottom set uses RGB ~128 which is just naively half of 255.
Wyck
CC BY-SA 4.0
2021-05-03T19:36:50.133Z
I invite you to read [an answer I wrote](https://computergraphics.stackexchange.com/a/10834/8009) recently about gamma that should help you understand what's going on.
Wyck
CC BY-SA 4.0
2021-05-03T19:45:31.253Z
@Wyck thank you for commenting. You are right. I finally understood. I had wrong assumptions
chmike
<antialiasing><gamma>
Is anti-aliasing color processing correct in this image?
chmike
# Is anti-aliasing color processing correct in this image?

(Asked by: username_0 on 2021-04-28)

I have the impression that there is a problem with anti-aliasing in a 2D GUI framework using opengl. To demonstrate the problem I made a program that draws gray ramps. The result is shown below.

[![anti-aliasing rendering test](https://i.sstatic.net/u63fw.png)](https://i.sstatic.net/u63fw.png)

The top and bottom gray ramps are identical and considered the reference ramps. It is a copy from ["What every coder should know about gamma"](https://blog.johnnovak.net/2016/09/21/what-every-coder-should-know-about-gamma/). This is what I currently assume that we should see when gray colors are correctly encoded. There seam to be a rounding error in this ramp, so an exact match is not required. The right most rectangle is not perfectly white.

The second gray ramp counting from the top is produced by drawing each rectangle as a stack of black lines not thicker than a pixel on a white background. The thickness of the lines reduces linearly as we go from black to white. The gray color result thus purely from anti-aliasing.

The third gray ramp is simply a sequence of rectangles filled with linearly increasing gray values.

I was expecting that all gray ramps would look identical, but clearly the second gray ramp is not. It seam that a gamma correction has been applied to it while I think it should not.

It generates artifacts which are strongly visible in font rendering as shown below.

[![This is a test comparison](https://i.sstatic.net/qi77z.png)](https://i.sstatic.net/qi77z.png)

The text *a* has been produced with the library in question, and the text *b* has been produced with another font rendering library.

Another test I did to put in evidence the artifacts resulting from the anti-aliasing color processing is to draw slightly slanted lines.

[![slightly slanted lines](https://i.sstatic.net/GeVh5.png)](https://i.sstatic.net/GeVh5.png)

The lines above are produced by the library in question and the lines below by another library. The thickness of the lines below look more uniform. The lines above look wrong and distorted.

The author of the 2D graphic library claims that his color processing with anti-aliasing and filled rectangle is correct.

Who is right ? What argument could I use to resolve this disagreement ?

The more I work on this subject, the more I get confused. For instance, by using a color picker I see that the color in the center of the ramp of the reference image is close to 0x7F. Is the color picker giving the color in linear space or the [sRGB color value](https://medium.com/game-dev-daily/the-srgb-learning-curve-773b7f68cf7a) ? The screen color picker is Gpick (Gnome Linux).

I know that we should work in linear color space when performing operations on images. What is unclear is what am I looking at ? The color values I gave to rectangles where linear, not sRGB, or not gamma corrected. The color ramp I see seam linear. The values given by the color picker seam to match the linear value I gave.

**Tags:** antialiasing, gamma

> **Comments:**
> **username_1**: Font rendering is a special case.  
> **username_2**: The top set of lines in the antialiasing image is correct.  The bottom set of lines is rendered naively without respect for gamma.  You can tell because in the top set, the midpoint intensity is an RGB ~189 which corresponds to sRGB 50%.  But the bottom set uses RGB ~128 which is just naively half of 255.  
> **username_2**: I invite you to read [an answer I wrote](https://computergraphics.stackexchange.com/a/10834/8009) recently about gamma that should help you understand what's going on.  
> **username_0**: @username_2 thank you for commenting. You are right. I finally understood. I had wrong assumptions  

---

## 1 answers

### Answer by username_0 on 2021-04-30. Score: 1

The anti-aliasing rendering is correct.

The reference gray ramp (top and bottom) is linear in sRGB color, not in brightness.

The second gray ramp made with anti-aliasing is linear in brightness. The rectangle color (black in color sRGB space) is mapped to linear space (remains black), then anti-aliasing is computed, and the resulting image is converted back to sRGB. It is thus not linear in sRGB value anymore.

The RGB values given by a screen color picker are in sRGB color space, and the color values of a screen capture are in the sRGB color space.

SVG and nearly all browser graphic library (skia and cairo) are doing it wrong. They compute anti-aliasing over sRGB instead of linear color. They thus don't convert back from linear to sRGB. The same mistreatment is also visible on Windows, MacOs and iOS.

The filled rectangle gray ramp doesn't have this problem because the conversion from sRGB to linear and its inverse cancel out.


---

