4 ms·

Pixel boundaries on your display are imaginary, all you have are RGBRGB light sources next to each other. The pixel boundaries are determined by your left-most

Pixel boundaries on your display are imaginary, all you have are RGBRGB light sources next to each other. The pixel boundaries are determined by your left-most and right-most light sources on the display, so you have |RGB|RGB|..., but it really shouldn't affect how you render text in the middle of your screen. edit: > it is not grayscale that makes any false assumptions Grayscale assumes that those pixel boundaries are real, and they are relevant.

kevingadd 5y ago
This assumes you actually have RGB light sources in that order. There are (were?) consumer displays with RGBW or other alternative arrangements out there, not to mention panels with a different color ordering. And if you rotate or invert the display, the ordering becomes different. An ordinary consumer will never understand what's going on here, so if your code assumes RGB subpixel rendering for text is always correct, it's just going to look ugly to them for no reason.
- steerablesafe 5y ago
  I was assuming that to make a point. The actual subpixel order can either be retrieved by an appropriate API (if available) or be provided by the user (display settings). Point being, subpixels don't usually overlap on the same area, which is what's grayscale's assumption. I agree that if subpixel order is not known, then grayscale is a sane default.
  - user-the-name 5y ago
    If your stroke is 7 subpixels wide, it will be, for instance, RGBRGBR. That has three Rs, two Gs, and two Bs. That is 50% more red light than blue or green. That is tinted red, no matter how you look at it. Subpixel antialiasing does distort colours. That is just a physical fact. The only reason it works at all is that on average, it will even out to a uniform white. But in the details, it will not. Especially around straight vertical edges.
    - steerablesafe 5y ago
      That's a very naive and wrong way to do subpixel-AA. Roughly, to calculate the light intensity of a red subpixel, you must also take into account the red light intensity around a whole pixel area around that subpixel, centered on that subpixel. There are better filters to use here, this would be a box filter, which is 1-pixel wide.
      - user-the-name 5y ago
        No, it is not. It is the physically correct way to do it. 50% more red light is emitted than blue or green. That is a red tint. Your eyes aren't going to see that as anything other than a red-tinted line. That is what you will see. Sub-pixel antialiased text looks like it has colourful fringes. People see this. It is not in their imagination. It actually is there, and it is exactly because of sub-pixel antialiasing.
        Firadeoclus 5y ago
        >No, it is not. It is the physically correct way to do it. 50% more red light is emitted than blue or green. That is a red tint. That is a red tint. And that's why it's not the correct way to do it. A subpixel antialiased white line that is seven subpixels wide, on a black background, should not produce (8-bit RGB triplets): 0-0-0, 255-255-255, 255-255-255, 255-0-0.
        user-the-name 5y ago
        Then that means you can not render full white.
        BlueTemplar 5y ago
        Full brightness white is supposed to be reserved for light sources anyway, definitely not text background !
        kaba0 5y ago
nyanpasu64 5y ago
> Pixel boundaries on your display are imaginary, all you have are RGBRGB light sources next to each other. Kinda. From my testing (in my subjective perception) several years back, grayscale text looks slightly colored at the edges, but subpixel-rendered text looks more colored in the opposite direction. And in my testing, vertical lines look more fringey if they take up GBR or BRG subpixels than RGB. I suspect these are because the green subpixel is perceived as the brightest by humans, and looks better in the middle of a pixel, and RGB and BGR put it in the center so it works out.
- steerablesafe 5y ago
  There can be various causes for those symptoms: 1. Even if the rendering gets the subpixel order right, the subpixels are rarely equidistant on a display. They tend to be closer to each other within a logical pixel. 2. Some subpixel-AA algorithms are naive, and trade color accuracy to luminance accuracy, causing more color fringes. 3. Incorrect gamma handling. 4. If aiming for more luminance accuracy, incorrectly taking into account the relative luminance of the subpixels (what you observed with the brighter green subpixels). Imageworsener[1] has an option to downscale with subpixel antialiasing, it's gamma correct by default, and it has an option for adjusting the subpixel offsets within a pixel (instead of the naive default of 1/3). It might be a good way to try out correct subpixel-AA, but it only works on images. I guess you can render text on high resolution and downscale that with imageworsener, but you won't get any hinting that way, but maybe that's desired. Very few software does AA correctly, let alone subpixel-AA. [1] https://entropymine.com/imageworsener/ https://entropymine.com/imageworsener/
d_tr 5y ago
How do pixel boundaries relate to the fact that you cannot avoid color fringing with subpixel AA? You could shift your whole framebuffer (or maybe just a glyph, with possible caveats) by a subpixel or two and have GBR or BRG pixels, it doesn't matter. What matters is that you need to keep the hue constant across triplets of subpixels to avoid fringing, and this is what grayscale does, and what subpixel does not do because it is its whole point. Subpixel basically assumes all your subpixels are the same color.
- steerablesafe 5y ago
  This assumes a naive and wrong way to do subpixel-AA. See my other comment: https://news.ycombinator.com/item?id=30330936 https://news.ycombinator.com/item?id=30330936
  - d_tr 5y ago
    Is there any subpixel text rendering implementation that avoids color fringing to such a degree I cannot see it, or not? It's certainly there on both Windows and Linux.
    - steerablesafe 5y ago
      I don't know if such rendering is commonplace, but I know for sure that imageworsener handles this correctly for downscaling images. Check out the option `-offsetrb 1/3`. https://entropymine.com/imageworsener/subpixel/ https://entropymine.com/imageworsener/subpixel/
      - d_tr 5y ago
        I see there is some interesting stuff in the parent page as well, thanks :)
    - wodenokoto 5y ago
      I don't know what you can and can't see, but I could not tell the difference between gray scaling a screenshot and not, on my mac back when they still used colored subpixel AA (unless I zoomed in on the screenshot).

kevingadd 5y ago

This assumes you actually have RGB light sources in that order. There are (were?) consumer displays with RGBW or other alternative arrangements out there, not to mention panels with a different color ordering. And if you rotate or invert the display, the ordering becomes different. An ordinary consumer will never understand what's going on here, so if your code assumes RGB subpixel rendering for text is always correct, it's just going to look ugly to them for no reason.

steerablesafe 5y ago
I was assuming that to make a point. The actual subpixel order can either be retrieved by an appropriate API (if available) or be provided by the user (display settings). Point being, subpixels don't usually overlap on the same area, which is what's grayscale's assumption. I agree that if subpixel order is not known, then grayscale is a sane default.
- user-the-name 5y ago
  If your stroke is 7 subpixels wide, it will be, for instance, RGBRGBR. That has three Rs, two Gs, and two Bs. That is 50% more red light than blue or green. That is tinted red, no matter how you look at it. Subpixel antialiasing does distort colours. That is just a physical fact. The only reason it works at all is that on average, it will even out to a uniform white. But in the details, it will not. Especially around straight vertical edges.
  - steerablesafe 5y ago
    That's a very naive and wrong way to do subpixel-AA. Roughly, to calculate the light intensity of a red subpixel, you must also take into account the red light intensity around a whole pixel area around that subpixel, centered on that subpixel. There are better filters to use here, this would be a box filter, which is 1-pixel wide.
    - user-the-name 5y ago
      No, it is not. It is the physically correct way to do it. 50% more red light is emitted than blue or green. That is a red tint. Your eyes aren't going to see that as anything other than a red-tinted line. That is what you will see. Sub-pixel antialiased text looks like it has colourful fringes. People see this. It is not in their imagination. It actually is there, and it is exactly because of sub-pixel antialiasing.
      - Firadeoclus 5y ago
        >No, it is not. It is the physically correct way to do it. 50% more red light is emitted than blue or green. That is a red tint. That is a red tint. And that's why it's not the correct way to do it. A subpixel antialiased white line that is seven subpixels wide, on a black background, should not produce (8-bit RGB triplets): 0-0-0, 255-255-255, 255-255-255, 255-0-0.
        user-the-name 5y ago
        Then that means you can not render full white.
        BlueTemplar 5y ago
        Full brightness white is supposed to be reserved for light sources anyway, definitely not text background !
      - kaba0 5y ago

nyanpasu64 5y ago

> Pixel boundaries on your display are imaginary, all you have are RGBRGB light sources next to each other. Kinda. From my testing (in my subjective perception) several years back, grayscale text looks slightly colored at the edges, but subpixel-rendered text looks more colored in the opposite direction. And in my testing, vertical lines look more fringey if they take up GBR or BRG subpixels than RGB. I suspect these are because the green subpixel is perceived as the brightest by humans, and looks better in the middle of a pixel, and RGB and BGR put it in the center so it works out.

steerablesafe 5y ago
There can be various causes for those symptoms: 1. Even if the rendering gets the subpixel order right, the subpixels are rarely equidistant on a display. They tend to be closer to each other within a logical pixel. 2. Some subpixel-AA algorithms are naive, and trade color accuracy to luminance accuracy, causing more color fringes. 3. Incorrect gamma handling. 4. If aiming for more luminance accuracy, incorrectly taking into account the relative luminance of the subpixels (what you observed with the brighter green subpixels). Imageworsener[1] has an option to downscale with subpixel antialiasing, it's gamma correct by default, and it has an option for adjusting the subpixel offsets within a pixel (instead of the naive default of 1/3). It might be a good way to try out correct subpixel-AA, but it only works on images. I guess you can render text on high resolution and downscale that with imageworsener, but you won't get any hinting that way, but maybe that's desired. Very few software does AA correctly, let alone subpixel-AA. [1] https://entropymine.com/imageworsener/ https://entropymine.com/imageworsener/

d_tr 5y ago

How do pixel boundaries relate to the fact that you cannot avoid color fringing with subpixel AA? You could shift your whole framebuffer (or maybe just a glyph, with possible caveats) by a subpixel or two and have GBR or BRG pixels, it doesn't matter. What matters is that you need to keep the hue constant across triplets of subpixels to avoid fringing, and this is what grayscale does, and what subpixel does not do because it is its whole point. Subpixel basically assumes all your subpixels are the same color.

steerablesafe 5y ago
This assumes a naive and wrong way to do subpixel-AA. See my other comment: https://news.ycombinator.com/item?id=30330936 https://news.ycombinator.com/item?id=30330936
- d_tr 5y ago
  Is there any subpixel text rendering implementation that avoids color fringing to such a degree I cannot see it, or not? It's certainly there on both Windows and Linux.
  - steerablesafe 5y ago
    I don't know if such rendering is commonplace, but I know for sure that imageworsener handles this correctly for downscaling images. Check out the option `-offsetrb 1/3`. https://entropymine.com/imageworsener/subpixel/ https://entropymine.com/imageworsener/subpixel/
    - d_tr 5y ago
      I see there is some interesting stuff in the parent page as well, thanks :)
  - wodenokoto 5y ago
    I don't know what you can and can't see, but I could not tell the difference between gray scaling a screenshot and not, on my mac back when they still used colored subpixel AA (unless I zoomed in on the screenshot).