1
$\begingroup$

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

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". 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

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

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 ? 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.

Improve this question
$\endgroup$
4
  • 2
    $\begingroup$ Font rendering is a special case. $\endgroup$
    – joojaa
    Apr 28, 2021 at 17:08
  • $\begingroup$ 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. $\endgroup$
    – Wyck
    May 3, 2021 at 19:27
  • $\begingroup$ I invite you to read an answer I wrote recently about gamma that should help you understand what's going on. $\endgroup$
    – Wyck
    May 3, 2021 at 19:36
  • $\begingroup$ @Wyck thank you for commenting. You are right. I finally understood. I had wrong assumptions $\endgroup$
    – chmike
    May 3, 2021 at 19:45

1 Answer 1

Reset to default
1
$\begingroup$

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.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.